CompactFlash 5.0 biedt tot 144PB opslagruimte

De CompactFlash Association heeft versie 5.0 van de compactflash-specificatie vrijgegeven. Ten opzichte van de huidige 4.1-standaard biedt de nieuwe specificatie voor geheugenkaarten een hogere doorvoersnelheid en meer opslagcapaciteit.

Compactflash-kaarten worden vooral toegepast in digitale camera's en draagbare apparatuur als pda's. Omdat de prestaties van deze apparatuur in de loop der jaren fors zijn verbeterd, werd de tijd rijp geacht voor een nieuwe, snellere standaard. De CompactFlash Association heeft een cf- en spm-logo geïntroduceerd om de nieuwe kaarten eenvoudig herkenbaar te maken.

De huidige cf-standaard gebruikt 28bit-adressering, waarmee de capaciteit tot 137GB is begrensd en per instructie 128kB data kan worden doorgevoerd. De 5.0-specificatie schrijft het gebruik van 48bits adressen voor, waarmee maar liefst 144.000TB kan worden geadresseerd. Bovendien levert de nieuwe standaard minder overhead en dus snelheidswinst op: er kan per transactie 32MB worden overgezet.

Door toepassing van de ata-6- en ata-8-standaarden in plaats van het nu gangbare ata-4-protocol, kan udma 5 in plaats van udma 2 worden gebruikt, waardoor de transfersnelheid naar 100MBps kan worden verhoogd. Daarnaast bevat de 5.0-specificatie ondersteuning voor het trim-commando. Toepassing van dit commando zorgt ervoor dat de schrijfprestaties van de kaart niet na verloop van tijd achteruitgaan. Door wijzigingen in de interface-elektronica moeten de kaarten voortaan beter voldoen aan de ata-eisen, wat tot een betere compatibiliteit zou moeten leiden.

Verder worden verschillende methoden gespecificeerd om met een hostapparaat over de snelheid te communiceren. Dat is vooral van belang wanneer er in korte tijd veel informatie moet worden weggeschreven, bijvoorbeeld bij het opslaan van video in een hd-camera. Zo meldt de kaart aan de host welk prestatieniveau wordt gegarandeerd, zodat de host de datastroom kan limiteren om dataverlies te voorkomen. Met Streaming Performance Management kent de nieuwe cf-specificatie ook een optionele, meer geavanceerde variant. Hierbij worden specifiekere gegevens naar de host gestuurd zodat de prestaties gemaximaliseerd kunnen worden.

Reacties (81)

[freeco]

ah, ik wist niet dat CF kaarten, net zoals SSD's, onderhevig waren aan prestatieverlies na verloop van tijd.
Zijn er tooltjes of simpele methoden om manueel een trim te doen? Een simpele format is niet voldoende geloof ik, als ik de uitleg van SSD's me nog goed herinner.

[Verwijderd]

Ik wist ook niet wat TRIM was.

Ik het opgezocht.

Voor de gene willen weten wat TRIM is.

[Verwijderd]

Hhahahah ik moet lachen, wat is dit voor een nutteloze 'standaard' ( ).
Ruim 100PB aan opslag, krijg dat maar eens vol als consument. Tevens is t slechts een specificatie van iets dat nog ontwikkeld moet worden en wat ik de komende jaren nog niet zie gebeuren.

Nutteloos nieuwsbericht, laat ze maar komen met de praktijk.

[Reactie gewijzigd door Verwijderd op 3 augustus 2024 17:44]

[Nelissuh]

Het belangrijkste is dat de grens van 137 GB nu verlegd is, deze zou op korte termijn een belangrijk limiet kunnen zijn. Ik vind het goed dat ze in één keer een serieuze stap maken, waardoor apparaten lange tijd compatibel blijven.

De stappen van SD (4GB) -> SDHC (32 GB) -> SDXC (2TB) lijken groot, maar doordat de vraag naar grotere opslagmediums aanwezig blijft (verdubbeling in elke 18 maanden volgens Moore) is bijvoorbeeld de SDHC norm al binnen een paar jaar niet meer toereikend.

Edit: niemand schrijft dat er nu ook 100 PB mediums gemaakt moeten worden, maar een 256 GB kaartje binnen een jaar lijkt me geen probleem, en met de huidige 4.1 standaard is dat blijkbaar niet mogelijk, waardoor de nieuwe norm wel degelijk nodig is.

[Reactie gewijzigd door Nelissuh op 3 augustus 2024 17:44]

[Clavius]

De komende jaren niet gebeuren?! Ik zou er niet van staan te kijken als er over twee jaar 128GB CF'jes zijn, wat al akelig dicht bij de max van de huidige standaard zit. Het gaat dus niet lang duren voor deze standaard ingevoerd moet gaan worden. Het is natuurlijk alleen maar mooi dat ze hem zo ruim gesteld hebben, een standaardwissel is nm ongewenst.
Dus wel degelijk relevant en nuttig.

Edit: wow, zijn ze al zo ver! heb hier nog een CF van 128Mb liggen

[Reactie gewijzigd door Clavius op 3 augustus 2024 17:44]

[Nelissuh]

Clavius, helemaal mee eens, al denk ik dat dit nog sneller gaat dan je denkt. Silicon Power heeft vorige maand al een 128 GB CF kaartje aangekondigd: DpReview / hun eigen site. Dan zal het niet lang duren tot de grote namen als Sandisk en Transcend volgen met een introductie.

[arjankoole]

Ruim 100PB aan opslag, krijg dat maar eens vol als consument.

Dat zeiden ze een flink aantal jaren geleden, toen ik maar liefst een 20MB hardeschijf in m'n PC had ook. Enige jaren later hoorde je hetzelfde over de 1GB schijf in m'n pentium 1 - 75Mhz. Nu jassen genoeg mensen een 1TB schijf vol, en denken dan dat 't misschien maar tijd wordt om er eentje van 2TB te kopen.

Hoeveel opslagruimte de fabrikanten ook zullen creeeren, het zal altijd vol komen. Ook bij de normale consument.

[Omemanti]

Dat is zeker zo,

Maar ik heb nog de tijd gehad dat ik spellen moest wissen van mn hd om een nieuwe te installeren of mp3tjes moest weggooien..

Ik heb dat met een schijf van 1 tb niet tot nouwelijks meer..

Spellen en MP3's zijn naar mijn idee niet zo hard in formaat gestegen als de ruimte op de schijven. (of een mp3 speler,, eerst max 50 mp3tjes,, en nu kan alles erop wat ik bij elkaar zou kunnen halen..)


natuurlijk er zijn uitschieters, en films worden steeds groter en hersenloos usenet leegtrekken met 5 mb/s kan zorgen dat je aan 144 pb nog niet genoeg hebt, maar moet je dit dan gelijk ook als werkbaar aanvaarden?
Maar ik zie de verschillen tussen de gebruikte groottes van bestanden en de betaalbare ruimte wordt steeds groter..

[Reactie gewijzigd door Omemanti op 3 augustus 2024 17:44]

[Luqq]

144.000GB is toch 144 TB

[PD2JK]

Maar in de bron staat dit:

Capacity points beyond current limitation of 137GB (up to 144PB) & more efficient data transfer (32MB per transfer versus 128K per transfer)

[Kees]

144 PB, met 1000 als base. met 1024 als base kom je uit op 48 bits adressen * 128kb blocks = 128PB

[invoil]

Ik ga eigenlijk ook uit van 128PB is namelijk ook dezelfde hoeveelheid die UDMA 5 ondersteund

[Sfynx]

128 PiB, de fabrikanten hanteren gewoon de voorvoegsels zoals ze ook bij andere eenheden gebruikt worden.

[OddesE]

Het gebruikelijk HDD fabrikanten 'oplichterij' rekensommetje.

[Mike-RaWare]

Als je met 'oplichterij' 'met de standaarden overeenkomend' bedoelt heb je helemaal gelijk.

[Verwijderd]

Leuk dat ze na 10 jaar oplichterij er een "standaard" van hebben weten te maken.

feitelijk blijft het oplichting van het eerste uur.

Een velletje papier veranderd daar niks aan.

[kippetje01]

Dat is correct, maar itt tot wat er in het artikel staat lijkt me dat 20 bits extra resulteert in 1.048.576 * 137 GB dit resulteert dus grofweg in 144.000.000GB wat dus ook in het artikel staat nu

[Reactie gewijzigd door kippetje01 op 3 augustus 2024 17:44]

[BlueLed]

Volgens mij heb je gelijk. 144PB is ook wel een beetje heel heel erg veel.

[OddesE]

Toch is het waarschijnlijk wel degelijk 144PB... 48 bits om te adresseren levert gewoon heel veel ruimte op, namelijk 2^48 bits.

[mad_max234]

48bit is instaat om 144 PB aan te spreken.

Neem aan dat er eerst in de tekst 144.000GB stond en het is verbeterd naar 144.000TB? Wellicht was het handig om even te vermelden dat een artikel is geüpdate.

[Thomas M]

2^48=281474976710656 bits= 35184372088832 bytes= 34359738368 KB= 33554432 MB= 32768 GB = 32 TB = 0,03125 PB, of heb ik een fout gemaakt?

EDIT:
Stel het is 144PB, dan:
144PB = 144.000 TB = 144.000.000 GB = 144000 harde schijven van 1 TB, dat is best veel, kunnen ze nog jaren mee vooruit.

[Reactie gewijzigd door Thomas M op 3 augustus 2024 17:44]

[Verwijderd]

Je hebt gelijkt wat betreft dat 2^48bit = 32TB.
Met rekenmachine en met zoeken op "2^48 bits" op Google geeft 32TB als resultaat. Dit betekent ook dat 2^28 bits, 32MB is en niet 137GB.

Toen ik las over 144PB had ik zoiets dat Google dan al zijn datacenters zou kunnen vervangen door enkele Compactflash-kaarten. Dus niet!

[Reactie gewijzigd door Verwijderd op 3 augustus 2024 17:44]

[Milt]

Het is wel degelijk 144 PetaBytes! (nou ja, soort van)

2 ^ 48 bits kan 281.474.976.710.656 sectoren adresseren. Iedere sector is 512 bytes (2 ^ 9) wat een geheugenruimte oplevert van 128 PetaBytes (2 ^ 57). De marketingafdelingen van de opslagindustrie noemen dit dan 144 PetaBytes.

[Verwijderd]

@Milt, bedankt voor het aanvullen van een ontbrekend stukje informatie.
Dan had er beter voor de duidelijkheid, 2^48bits adressering van 512 bytes sectoren, kunnen staan. Niet iedereen weet dat er sectoren van 512 bytes aangesproken worden. Zie ik ook niet direct terug in de documentatie. 128PB leek mij daarom in eerste instantie wel wat veel voor zo'n klein kaartje.
Het einde van de HDD met zijn enkel TB's. En dat qua grote vergeleken met een Compactflash-kaartje.

[flamingworm]

maar de sectorgrootte licht toch niet echt "vast", ze kunnen toch makkelijk sectoren van bv 4kB gebruiken toch?

nuja, eigelijk een beetje een nonsense artikel, hoera, ze kunnen miljoen miljard petabyte adresseren, maar niemand die dat in de eerste 100 jaar in een CF kaartje krijgt.

[FireDrunk]

32Bit = 4GB, 48Bit is gewoon 1 stapje hoger.. Dat het dan logaritmisch omhoog gaat is gewoon een bijkomstigheid... Dat wil niet zeggen dat het overbodig is...

[_eXistenZ_]

Niet de marketingsector hoor Jij rekent in Pebibytes, oftewel PiB. Zo laat Windows ook zijn diskruimte zien, hoewel daar ineens GB / TB / PB bijgeplakt staat in plaats van het correcte GiB / TiB / PiB.

De "marketing"-afdeling zoals jij dat noemt gebruikt gewoon het SI en komt inderdaad op 144 Petabytes uit.

http://nl.wikipedia.org/wiki/Terabyte

[Milt]

Jaja, ik weet het. Maar voor mij blijft een gigabyte gewoon 1024 megabyte. Ben misschien wel old-school maar ik vind het de juiste manier van rekenen bij alles op en rondom computers. En ik geloof er niks van dat de harddisk fabrikanten de andere manier van rekenen zijn gaan gebruiken omdat ze zo graag aan de SI standaarden willen voldoen. Het kwam ze gewoon goed uit.

[Qualian]

Oh, da's jammer... ik zocht juist een geschikt kaartje voor mijn 12 Gigapixel camera

[Powergrim]

Ik ben geneigd om te zeggen dat je gelijk heb. Ergens zit er een spelfoutje in denk ik..

[HotFix]

Daar hebben we een speciale feedback knop voor Het is trouwens al aangegeven in het spelfouten topic

[Verwijderd]

Zou wel leuk zijn

[Reactie gewijzigd door Verwijderd op 3 augustus 2024 17:44]

[Thasquealer]

PB zou inderdaad iets teveel zijn geweest.
Dacht al, dat gaat heel snel!!
Maare bij compactflash, moet ik dan aan sd kaartjes denken?

[OddesE]

PB zou inderdaad iets teveel zijn geweest.

En toch klopt het. Adres ruimte is niet hetzelfde als daadwerkelijke opslagruimte!

EDIT: Uitleg

Stel je hebt een straatnummer systeem met 5 cijfers voor het huisnummer. Dan kun je dus maximaal 100.000 huizen in die straat een nummer geven (adresruimte). Dit wil nog niet zeggen dat je ook echt zoveel huizen bouwt in die straat. Maar als je maar 2 cijfers per huisnummer zou gebruiken zou je nooit meer dan 100 huizen een nummer kunnen geven (00 - 99). Dus *potentieel* kan men kaartjes tot die grootte maken.

[Reactie gewijzigd door OddesE op 3 augustus 2024 17:44]

[cPT.cAPSLOCK]

Duidelijke uitleg, misschien zien mensen nu in dat het wél PB is.
Dat voorbeeld had ik zelf nooit kunnen bedenken!

[bigbadbull]

Nee, maar ik dacht net dat CF kaartje er uit gingen omdat SD steeds meer gebruikt wordt.

CompactFlash kaartjes zijn stukken groter, en werden tot voor kort in de meeste high end camera's nog steeds gebruikt;
ook daar zag ik net SD binnen komen.
op de plaats van een Cf kan men gemakkelijk 4 SD's steken, en die staan ook niet stil.

[Japs]

Tsja...
Voordelen van CF die meestal worden genoemd:
* CF kaartjes worden als robuster gezien dan (mini/micro) SD (handig voor fotografen in het veld).
* Volledig compatible met IDE/ATA, dus heel makkelijk als "harddisk" te gebruiken (voornamelijk handig voor allerlei embedded system, machines etc.).
* Tot nu toe is het volgens mij nog altijd zo dat de snelste, en grootste geheugenkaartjes CF zijn.

[Thasquealer]

Owk, dank u!
Ik denk dat ik me wel kan herinneren welke dat zijn
Edit:
Denk dat dit dan ook vooruitgang kan betekenen voor de sd kaarten?

[Reactie gewijzigd door Thasquealer op 3 augustus 2024 17:44]

[kozue]

Ik dacht dat CF kaartjes jaren geleden al een zachte dood waren gestorven, omdat die dingen veel te groot waren voor moderne verwachtingen... ik zat dus ook vreemd te kijken bij de titel van dit bericht en ben nog steeds sceptisch.
Zouden we binnenkort ook weer een revival van de minidisk of de hd-dvd gaan krijgen?

[R-O-Y]

Wat dacht je van CompactFlash kaartjes Zelfde idee maar allebei net even anders.

[Rexxar]

Ik denk dat het belangrijkste nieuws hier toch wel de transfersnelheid is, met full HD filmen en steeds meer pixels op camera's lijkt me 100MB/s harder nodig dan 144TB aan opslagruimte. Ik ken iig nog niemand die de nu mogelijke 128GB kaartjes al heeft.

[Jazco2nd]

Voor (full) HD is 100MB/s vette overkill hoor.
Het is een kwestie van een goede zuinige microprocessor voor de compressie (H.264). De bitrate die nu door compactcamera's en hd camera's wordt gebruikt is erg hoog omdat er anders een veel sterkere, duurdere en dus ook minder zuinige processor nodig is.

[HotFix]

Ik snap je redenering niet helemaal (dat kan komen door een gebrek aan kennis van mijn kant). Doordat er nu geen sterkere, duurdere en minder zuinige processoren (voor de compressie) worden gebruikt betekent dat je een hogere bitrate op je camera hebt; maar dat is toch niet slecht? Bitrate staat volgens mij recht evenredig met kwaliteit, dus waarom zou je een lagere bitrate willen?

[cPT.cAPSLOCK]

bitrate staat in verband met de kwaliteit afhankelijk van het gebruikte algoritme.

Om je een voorbeeld te geven:
We pakken een film van 200mb. Deze zippen we. In het archief is hij nog maar 150MB. Toch is er geen kwaliteit verloren - de computer moet alleen harder werken om het af te spelen (namelijk unzippen, dan pas afspelen).

Als je een snelle computer hebt zou dit real-time kunnen, maar een trage computer trekt dat niet.

Ditzelfde voorbeeld geld voor FLAC - hogere compressie op FLAC audio geeft een kleiner bestand, precies dezelfde geluidskwaliteit, alleen meer CPU usage (en dus ook stroomverbruik, belangrijk voor portables) tijdens het afspelen.
Er zijn nog wel meer compressiemethodes waar dit bij van toepassing is.

Terug naar de originele kwestie: als de huide microprocessor, die de compressie voor zijn rekening neemt, vervangen wordt met een krachtiger exemplaar, dan zal je met lagere bitrates (en dus kleinere filesizes en lagere benodigde schrijfsnelheid) dezelfde kwaliteit hebben.

[Reactie gewijzigd door cPT.cAPSLOCK op 3 augustus 2024 17:44]

[NESFreak]

Er is idd een verband tussen bitrate en de theoretisch maximaal haalbare kwaliteit.

Echter bij (laten we zeggen) 25 fps betekend dit wel dat er dus 25 beelden per seconde op het kaartje moeten opgeslagen worden.
Elk van deze beelden word door de processor gecomprimeerd. En de processor moet dus na 1/25 seconde klaar zijn met dat beeld. De meeste cameraprocessors zijn echter niet in staat om in deze 1/25 seconde het beeld ook daadwerkelijk goed te comprimeren. Daarom daarom gebruiken de meeste camera's vaak wat lichtere algoritmes, met als gevolg dat bij een anders 'goede' bitrate de kwaliteit ineens een stuk lager uitvalt, en je dus genoodzaakt bent naar een hoge bitrate uit te wijken.

Kijk je bijvoorbeeld naar de h264 codec dan zie je dat deze op 1.5mbit grofweg de zelfde kwaliteit haalt als mpeg-2 bij 3.5mbit (echter realtime encoden van h264 is zelfs op de huidige pc's nog moeizaam, laat staan op een digitale camera dus).

Met andere woorden, voor je digitale camera om een beetje een mooie compressie verhouding te leveren in filmpjes wil je er toch eigenlijk wel een i7 in je camera hebben zitten. En zoals al aangeven. Snelle processors zijn snel, kosten veel en vreten stroom.

[Rexxar]

Ik denk dat het bij slo-mo camera's geen overkill is (paar 100fps), al;hoewel ik bergrijp dat bij standaard 30/60fps het geen probleem is, zie ik dat zodra de techniek het toelaat high speed camera's een toffe gimmick zijn.

En een hogere bitrate (natuurlijk wel afhangend van de compressie) betekend in principe ook meer kwaliteit. Dit soort ontwikkelingen maken dus ook ruimte voor hogere bitrates en nieuwe compressie. HotFix meld ongeveer hetzelfde (het is mij ook nooit 100% duidelijk geweest hoe het precies zit).

[Aham brahmasmi]

Ik denk dat het belangrijkste nieuws hier toch wel de transfersnelheid is, met full HD filmen en steeds meer pixels op camera's lijkt me 100MB/s harder nodig dan 144TB aan opslagruimte. Ik ken iig nog niemand die de nu mogelijke 128GB kaartjes al heeft.

Met 128GB is de capaciteitslimiet van CF4.1 al bereikt, maar er bestaan ook 600x CF-kaartjes die al 90MB/s halen. Ik zie hier dus gek genoeg helemaal geen verbetering (10MB/s is niets) in de nieuwe standaard.

[Verwijderd]

Ik snap dat het verstandig is om technologie op de toekomst voor te bereiden, maar is 144 PB niet erg overdreven voor dit moment?

Als ik even snel door Wikipedia heen snuffel voor vergelijkingsmateriaal kom ik de volgende nummers tegen:
- Archive.org heeft op dit moment 2PB aan gecachte pagina's.
- De Large Hadron Collider gaat ongeveer 15PB per jaar aan data produceren.
- En de laatste, als quote: "the entire [written] works of humankind, from the beginning of recorded history, in all languages" would amount to 50 petabytes of data."

Denk er hierbij ook aan dat het om compactflash kaarten gaat, en niet over de specificaties van een file system. Tegen de tijd dat we 144PB nodig hebben voor camera's en pda's zullen we gegarandeerd al een tig aantal uitgaves van de standaard verder zijn, en het is maar de vraag of er tegen die tijd niet een ander medium voor flash drives wordt gebruikt. (Floppy, Cd-Rom, Dvd, Blue-Ray)

En boven alles: Zie maar eens 144PB op het huidige formaat kaartje te persen!

[Clavius]

Ja ok, het is veel, maar wat is volgens jou dan het nadeel van de mogelijkheid om veel te adresseren?

[Verwijderd]

Ik zeg ook zeker niet dat het een nadeel is!

In het geval van de Y2K bug zou het heel wat consternatie en paniekeriger gedrag gescheeld hebben als de techniek voorbereid was op de toekomst. Op dat gebied is deze standaard dus goed voorbereid.

Waar ik vooral op doel is dat deze technologie vooral voor consumenten gebruikt lijkt te worden, en welke gewone consument zal binnen nu en 100 jaar zoveel ruimte nodig hebben?

Maar echt duidelijke nadelen... Ik zou ze op dit moment niet kunnen noemen. Het woord "Overbodig" is hoogstens van toepassing. Maar mischien weet iemand anders met meer inzicht nog wat te noemen.

[MittaM]

Das een flinke hoeveelheid. En we zullen dus weer en tijd vooruit kunnen met de nieuwe standaard. Maar in hoeverre is de oude standaard dan al aan vernieuwing toe. Qua opslag zit het nog wel redelijk goed lijkt mij? Is de snelheid dan zo een erge bottleneck?

[Aham brahmasmi]

Maar in hoeverre is de oude standaard dan al aan vernieuwing toe. Qua opslag zit het nog wel redelijk goed lijkt mij? Is de snelheid dan zo een erge bottleneck?

De opslaglimiet was wel bereikt hoor. Er waren namelijk al 128GB CF-kaartjes.
Gek genoeg lijkt de doorvoersnelheids helemaal niet verhoogd te zijn. Er zijn namelijk ook al CF-kaartjes die 90MB/s halen (600x).

[Verwijderd]

Door toepassing van de ata-6- en ata-8-standaarden in plaats van het nu gangbare ata-4-protocol, kan udma 5 in plaats van udma 2 worden gebruikt, waardoor de transfersnelheid naar 100MBps kan worden verhoogd.

Ik vraag me af waarom er nog energie in ATA CF gestoken wordt. IMO zou SATA ( CFast )de enigste redding van CF zijn, maar dan zullen ze er vaart achter moeten zetten. Zeker omdat een groot gedeelte van de DSLR's al over het gaan zijn naar SD kaarten.

Ik verwacht dat SDXC uiteindelijk de positie van CF over zal nemen.

Dit is een vergelijking van de verschillende formaten.

[Pyronick]

Ik neem aan dat dit ook de laatste revisie is van de PATA-based CompactFlash reeks.

Alleen heb ik het idee dat de incompatibiliteit met de standaard 15 pins SATA power kabel een probleempje kan worden.

Het lijkt mij wel een logische stap met SATA controllers die steeds vaker in ARM-gebaseerde system-on-a-chips verschijnen.

[Kalief]

Door toepassing van de ata-6- en ata-8-standaarden in plaats van het nu gangbare ata-4-protocol [knip] Daarnaast bevat de 5.0-specificatie ondersteuning voor het trim-commando.

Het TRIM commando zit niet in het ATA-6 protocol maar is een voorgesteld onderdeel van het ATA-8 protocol. (Of loop ik achter?)
Dat zou betekenen dat toepassing van TRIM optioneel blijft en dat zou i.m.o. een slechte zaak zijn omdat het verwarring bij de consumenten oplevert.

Voorbeeld: een nieuw en groot maar verrassend goedkoop kaartje vermeldt iets met ATA-6 en CF5.0 en blijkt na verloop van tijd behoorlijk traag te worden. Daar weet de winkelier wel wat op en verkoopt je een ogenschijnlijk identiek kaartje waar ATA-8 op staat. Aha denkt de consument en koop later een kaartje waar ATA-8 en CF4.1 op staat die na verloop van tijd natuurlijk even traag wordt.

(doc over TRIM in ATA-8)

[Aham brahmasmi]

Aha denkt de consument en koop later een kaartje waar ATA-8 en CF4.1 op staat die na verloop van tijd natuurlijk even traag wordt.

CF4.1 gebruikt ATA-4 volgens de specificatie, dus kan er logischerwijs niet ATA-8 op het kaartje staan.

[rvdven]

Om met 100MBps 144PB vol te krijgen ben je volgens mij wel even bezig...

Google zegt: (100 petabytes) / (100 MBps) = 34.0255519 years

[Reactie gewijzigd door rvdven op 3 augustus 2024 17:44]

[Verwijderd]

precies, er is niks mis mee om een standaard te maken die zo veel data kan opslaan dat deze nog decennia kan meegaan (zoals sommige het hier belachelijk maken). Maar dan moet de theoretisch haalbare snelheid wel in proportie zijn.