Sandisk stelt introductie mlc-ssd's uit 'wegens tekortkomingen Vista'

Sandisk heeft de introductie van een drietal ssd-drives voorlopig uitgesteld. De reden voor de vertraging is volgens de flashfabrikant de gebrekkige ondersteuning van Windows Vista voor ssd's op basis van mlc-technologie.

Het zal zeker tot 2009 gaan duren voordat Sandisk ssd's met capaciteiten van 128, 160 en 256GB op de markt zal brengen, zo schrijft Cnet. Sandisk geeft als reden voor het uitstel dat het bedrijf 'de beperkingen van het Vista-platform nog onvoldoende kent'.

Volgens Sandisk-ceo Eli Harari vormt Windows Vista een uitdaging voor ssd-fabrikanten, omdat het OS onvoldoende zou zijn toegerust voor moderne sdd-drives op basis van mlc-flashchips. Hierdoor zouden de huidige ssd-controllers ondermaats presteren. Sandisk gaat nu terug naar de tekentafel om zijn controllers alsnog voor Vista aan te passen. Volgens Harari moeten de controllers 'in feite de tekortkomingen van Vista compenseren'.

Het bedrijf verwacht eind dit jaar de eerste samples van zijn opgepoetste ssd's aan hardwarefabrikanten te kunnen leveren. De problemen die Sandisk met Vista heeft, treden overigens niet op bij de goedkopere modellen met een opslagcapaciteit van maximaal 32GB, die minder complex zouden zijn. Hierbij doelt de flashfabrikant vermoedelijk op ssd-drives op basis van slc-flashgeheugen. Onduidelijk is echter of Sandisk daadwerkelijk tegen structurele tekortkomingen van Microsofts besturingssysteem is aangelopen, of dat het bedrijf met zijn kritiek op Vista probeert te verhullen dat het te laat is begonnen met het compatibel maken van zijn hardware.

Reacties (105)

[Rob Coops]

De slc en mlc zijn natuurlijk enigzins verschillend omdat de eerste maar een bit opslaat per cell en de tweede meerdere kan opslaan.
Dit verschil kan je natuurlijk in drivers oplossen iets wat SanDisk schijnbaar van Microsoft verwachte, maar je kan dit ook door de controller laten afhandelen waardoor je een simplere driver overhoud maar wel duurdere hardware moet bouwen. Microsoft heeft hoogst waarschijnlijk voor de laatste optie gekozen waar SanDisk op de eerste had gehoopt en waarschijnlijk de handleiding gewoon niet goed gelezen heeft.

Ik zou zeggen dit is gewoon de schuld afschuiven door SanDisk en om eerlijk te zijn niet meer dan logisch aan de kand van Microsoft. Een software vendor zou niet verantwoordelijk moeten zijn voor het zorgen voor driver die optimaal werken met alle SSD's in alle verschillende opstellingen slc, mlc en wie weet wat de toekoms brengt. De hardware vendor moet zich of aanpassen aan de bestaande drivers of moet zelf een betere driver schrijven.

[Umbrah]

Exact. Zeker bij een relatief "nieuw" product als een SSD, zou je er vanuit mogen gaan dat de fabrikant met een driver of een degelijke firmware/controller komt.

Dat windows versies in principe aardig wat nvidia videokaarten herkennen, wil nog niet zeggen dat het goed werkt, sterker nog: iedereen installeert gelijk de meest recente driver van het driver CD-tje of internet. En dat hebben die fabrikanten juist weer erg graag.

Ik denk niet dat de gevolgen te overzien zijn als je MS verantwoordelijk gaat stellen voor ALLE drivers wat sandisk volgens mij graag wil als ik dit zo hoor. Het OS zou dan geleverd mogen worden op 4-5 BD-ROM's, zodat ook m'n HP deskjet 400 op de zolder werkt en zelfs het inktniveau kan weergeven!

[Fiander]

Dacht je nou werkelijk dat windows zo dicht op de hardware zit ?
Hier zijn firmwares op de SSD zelf voor, deze heeft een controller welke dit werk hoort te doen.

Windows doet niks anders dan zeggen welke bytes naar welke cluster geschreven moeten worden. Een controller zal dat aanpassen naar de juiste sector, en het daar neer zetten.

[MSalters]

Nee. Cluster/sector translatie gebeurt door de file system driver (FAT/NTFS).

[OddesE]

De slc en mlc zijn natuurlijk enigzins verschillend omdat de eerste maar een bit opslaat per cell en de tweede meerdere kan opslaan.
Dit verschil kan je natuurlijk in drivers oplossen

Klok, klepel...
Windows praat alleen tegen de SATA interface en die weet toch niet wat voor een chipjes *intern* in de drive gebruikt worden?

Smoesjes, smoesjes.

[Toontje_78]

Enige wat een fundamenteel probleem zou kunnen zijn zou het file system zijn, NTFS. Hardware word gezien als een device, en verder heeft het OS er niets te zoeken.

Hoe NTFS een probeem zou zijn... Het gaat al een paar jaar mee. Het probleem zou dan journaling zijn.

[Keeper of the Keys]

Ik zal dit wel verkeerd zien, maar als de schijf het sata/scsi protocol "praat" en het OS doet dat ook (of communiceert met de southbridge/sata-controller op het niveau en de manier die het wil die dat op zijn beurt "vertaalt" naar "normale" sata/scsi commandos...), zou het dan niet totaal irrelevant moeten zijn hoe de schijf werkt/gebouwd is (vanuit het OS gezien dan)?

Wat ik me kan indenken is dat bewustzijn van het type harde schijf misschien tot een ander schrijf/lees patroon zou lijden (en het uitzetten van defragmenteren).
Maar zulk soort dingen zou de schijf ook zelf kunnen afhandelen (al zou dat dingen wel flink compliceren voor de schijf, maar als je iets aan generieke bus hangt dan denk dat je dat juist zelf moet afvangen en niet in software, want de software die is er niet altijd [POST, ander OS, etc.] de hardeschijf is er "altijd")

[Fiander]

Maar zulk soort dingen zou de schijf ook zelf kunnen afhandelen (al zou dat dingen wel flink compliceren voor de schijf,

Als je dat soort dingen niet op de schijf zelf zou doen, zou je zelfs de kabel overbelasten met alleen maar opdrachten, ipv dat je 1 opdracht met veel data over kunt sturen.

[Aetje]

De kabel heeft over het algemeen (en zeker bij SATA) een hogere transfer rate dan het medium, in zowel de platter harddrives als de SSDs. Dat je aan opdrachten bandbreedte verliest maakt dus geen moer uit.

[kiddyl]

Nu werkt Vista anders met het bestand systeem dan XP. Er wordt aan prefetching gedaan op een manier die veel intensiever is, daarnaast is NTFS niet de meest ideale oplossing voor SSD's omdat bij elke bestand benadering iets wordt weggeschreven ook al lees je het alleen maar. Daarnaast doet Vista ook automatisch defragmenteren wat in principe niet nodig is voor SSD's.

Met de huidige nog vrij hoge prijzen voor de snelle SSD's zijn de kopers ook de gebruikers die zelf weten hoe ze een SSD het beste kunnen inzetten, maar zodra de prijzen het consumenten niveau bereiken dan is dat niet meer zo. Verkeerd ingezette SSD's kunnen het einde van hun theoretische levensduur daarom veel sneller bereiken en dat kan Sandisk voor garantie kosten wat de inzet van SSD's op de markt door hun nu dus niet rendabel is.

[HeyDude]

De (meeste) grote producenten maken voor hun product roadmaps die andere producenten en toeleveranciers in staat stellen om te anticiperen op toekomstige (architectuur) wijzigingen. In dit geval lijkt me dat MS dit ook heeft gedaan, los van het feit dat Sandisk nauwe contacten zal onderhouden om dit product verder te ontwikkelen.

Inderdaad twijfelachtig of Sandisk niet voldoende heeft ingespeeld op de ontwikkelingen of niet genoeg capaciteit (lees geld) had om dit voor elkaar te boksen op tijd.

Edit typos

[Reactie gewijzigd door HeyDude op 26 juli 2024 01:42]

[Verwijderd]

De essentie van het snelheidsprobleem met MLC is dat elke afzonderlijke chip hooguit iets van 10 tot 20MB/s haalt bij random writes

Als ik het goed begrijp heeft OCZ dit overwonnen door 8 of meer MLC chips parallel te zetten. De doorbraak is dat er nu een controller+driver is die alle 8 tegelijk kan aan drijven. Dus MLC is niet opeens beter, maar nu kunnen ze synchroon zwemmen.

Transcend had een soortgelijk probleem. Zij hadden zomer 2007 al een SSD uitgebracht met een simpele controller. Dit leverde hun een aantal zeer slechte reviews op. Transcend heeft nu echter ook een nieuwe controller en naar eigen zeggen is de performance nu aanzienlijk verbeterd (circa 2/3e van de snelheid van de OCZ Core's volgens hun eigen tests)

Dus de perfomance komt hoofdzakelijk uit de controllers. Omdat SLC's van zichzelf al snel zijn, hebben die controllers met SLC gewoon minder te doen. Vandaar dat een grote drive van dure SLC chips eenvoudiger te maken is. Maar natuurlijk minder populair vanwege de prijs. Maar ja, je kan niet alles hebben.

[Reactie gewijzigd door Verwijderd op 26 juli 2024 01:42]

[the_stickie]

Vooral jammer dat dit artikeltje voor velen weer een anti-Vista argument is of zal zijn.
Ik lees zo vaak dat er vanalles mis is met Vista, dat het traag is en onwerkbaar, meestal "van horen zeggen" en slecht, of niet, gestaafd.
Hierbij dus voor die mensen alweer een uitgelezen kans om Vista de nek om te draaien.

[TD-er]

Hierbij dus voor die mensen alweer een uitgelezen kans om Vista de nek om te draaien.

Daar heb ik geen artikeltje voor nodig hoor

Maar goed, MS claimde met de introductie van Vista dat het juist goed om zou kunnen gaan met de nieuwste technieken, flash-geheugen in zou kunnen zetten als performanceboost, etc.
In de praktijk vind ik dat behoorlijk tegen vallen en dus kan ik me best wel wat voorstellen bij dit verhaal van Sandisk. Maar aan de andere kant zou het niet het eerste bericht zijn waarbij de fabrikant wat meer de hand in eigen boezem zou kunnen steken ipv Vista de schuld te geven.
Het hoeft echt niet een boegeroep richting Vista (of zelfs MS) op te leveren, al is dat wel waar Sandisk in deze een beetje op lijkt te hopen.

[Cergorach]

Dat komt omdat het na de introductie ook behoorlijk bagger werkte, niet van horen zeggen, maar netjes meegeken tijdens installatie en het werken ermee. Een gedeelte van de problemen werdt veroorzaakt door drivers (die MS netjes had goekgekeurd), maar een PC gebruiken werkt nu eenmaal makkelijk als je een monitor heb...

Maar dat is alweer een hele tijd geleden, en volgens mij zijn het meerendeel van de problemen de wereld uit geholpen. Wat overblijft is het vooroordeel van de mens, maakt niet uit of ze de kennis hebben om hier over te oordelen, mens eigen ;-)

Je hoort vaak dat je met Vista niet de 'snelheid' eruit kan halen die je met XP (of Linux) kan halen, daar hebben ze gelijk in. Echter, Win98SE is dan weer net iets sneller dan XP, en Win3.11 is nog sneller. Maar we zijn al jaren geleden overstapt naar nieuwere OSen omdat we meer bling/gemak willen hebben, het zelfde geld voor de overstap naar Vista. Linux is weer een heel ander verhaal, dat zal vast niet de zelfde problemen hebben als Core4 64-bit van een paar jaar geleden, Ubuntu schijnt enorm makkelijk te installeren te zijn. Maar het heeft nog niet het gemak van het windows platform, voornamelijk omdat de meeste software er niet voor geschreven is (natuurlijk heb je Wine en dergelijke, maar dat kost weer een hoop tijd/kennis).

[hamsteg]

SATA is bit georienteerd (1-en en 0-en). Krijg jij een karakter stroom aangeboden dan is de transformatie vrij snel te doen, namelijk bit voor bit. Mlc-flashchips zijn in staat twee bits per geheugencel bewaren. Het klinkt mij niet onmogelijk in de oren dat de datastroom efficienter kan door bijvoorbeeld niet als bit-stream data aan te leveren maar als een speciale MLC-stream met een soort van RAID-5 karakteristieken.

Ga je toch SATA bitstream aanbieden zal ScanDisk deze eerst zelf moeten transformeren en dat benadeelt de performance enorm. Verrassend wel dat ze daar nu al (=sarcatisch) achter komen.

[Reactie gewijzigd door hamsteg op 26 juli 2024 01:42]

[Femme]

Grote kans dat de bitjes er via de seriële interface van de flashchip gewoon één voor één ingeduwd moeten worden, ook al kunnen er twee bits per cel opgeslagen worden. De bandbreedte van de sata-interface is bovendien veel groter dan die van een enkele flashchip. Dit vraagstuk lijkt me totaal niet relevant voor de discussie over de vermeende ongeschikt van mlc-ssd's onder Windows Vista.

Grotere problemen lijken mij de lage schrijfprestaties, de hogere kans op bitfouten en het feit dat er met agressievere wear levelling tactieken gewerkt moet worden om erase cycles zo goed mogelijk te verdelen over de cellen. De lage schrijfprestaties worden o.a. veroorzaakt door het feit dat de cellen alleen in hele blocks van bijv. 256 of 512KB leeggemaakt kunnen worden voordat ze weer geprogrammeerd kunnen worden. Dit zorgt voor veel overhead bij schrijfacties op willekeurige locaties. Mlc-flash moet dan ook zoveel mogelijk sequentieel beschreven worden.

[Reactie gewijzigd door Femme op 26 juli 2024 01:42]

[Verwijderd]

Zou je dat schrijf probleem dan niet kunnen oplossen door de schijf met 256 of 512 KB clusters te formatteren? Is weliswaar meer dan de standaard 4KB van NTFS, maar volgens mij ondersteunt het het wel..

Zowiezo.. de 60MB/s schrijfsnelheid van de huidige SSD's is eigenlijk meer dan zat. Is toch meer theoretisch dan wat anders. De werkelijke snelheid komt uit de toegangstijd.

[Aetje]

Dan moet ScanDisk SANDISK een compleet nieuw adressingsprotocol voor hun schijven ontwerpen. Wat zij willen zal immers niet aan het SATA protocol voldoen.

[Verwijderd]

Ga je toch SATA bitstream aanbieden zal ScanDisk deze eerst zelf moeten transformeren en dat benadeelt de performance enorm.

Waarom? Een 100 MB/s datastroom is niks voor een beetje CPU.

Daarbij, ik kan uit het oorspronkelijke artikel niet opmaken dat het probleem bij MLC zelf ligt. Het lijkt eerder te maken te hebben met Vista's gebruik van virtueel geheugen en de manier waarop data geordend wordt. Zaken die voor een harde schijf een gemiddelde prestatieverhoging kunnen opleveren zullen voor een SSD vaak een verkwisting zijn.

[Verwijderd]

Wat een onzin. Er wordt niet bit voor bit geschreven hoor. Dat gaat gewoon een buffertje in.

Een pagina in het Flash geheugen (512 bytes of meer) kan in een keer worden volgeschreven.

[maratropa]

En elke aap die de auto defrag laat aanstaan is ook de sigaar

[Navi]

Inderdaad, defragmentatie schijnt heel slecht te zijn voor SSD's

[Verwijderd]

Volgens mij is het ook niet echt gezond voor gewone schijven. Het klinkt in ieder geval altijd erg belastend, contstant die koppen die bezig zijn.

[Vyo]

Bij harde schijven hoort het de sequentieele leessnelheid te verhogen en de accestime te verlagen, doordat alles netjes achter elkaar op de schijf wordt geplaatst en de kop dus niet/minder random heen en weer hoeft te gaan.

Een SSD daarentegen heeft op elke chip dezelfde accestime, en gezien die dingen maar "beperkt" overschreven kunnen worden is defragmenteren inderdaad niet alleen nutteloos maar zelfs slecht voor je schijf.

[OddesE]

Bij harde schijven hoort het de sequentieele leessnelheid te verhogen

Met nadruk op 'hoort het' want ik merk er geen zak van in de praktijk. Vroeger wilde ik nog wel eens defragmenteren, maar omdat ik er nooit wat van heb gemerkt qua snelheid, en wél een keer een groot drama heb gehad toen de PC crashte midden in de defrag, doe ik het nooit meer...
EDIT: quotje toegevoegd

[Reactie gewijzigd door OddesE op 26 juli 2024 01:42]

[Verwijderd]

Volgens mij is het ook niet echt gezond voor gewone schijven. Het klinkt in ieder geval altijd erg belastend, contstant die koppen die bezig zijn.

Ja, tijdens het defraggen is de schijf hard bezig... Maar daarna is de schijf juist veel minder hard aan het werk... Omdat je dan per bestand slechts 1 zoekactie hoeft te doen, i.p.v. 100.

Regelmatig defragmenteren is dus wel degelijk minder belastend voor de schijf, dan het zaakje gefragmenteerd te laten.

[leuk_he]

Een SSD heeft een maximaal aantal schrijf acties. Echter dat is zo groot dat je hier de komende jaren onder hoge belasting geen last van zou moeten hebben.

Ze hebben het hier over driver probelemen..


ik moest denken aan

http://hothardware.com/Ne..._VelociRaptor_Sneak_Peek/

We've seen some oddities with SSD drives in our standard HD Tach testing, so we're going to look deeper into that and experiment with different SATA controllers. Our testing was done on an Intel X48 chipset board (Asus P5E3 Premium) with the ICH9R Southbridge.

[siepeltjuh]

Defragmentatie is ook niet meer interresant voor SSD`s.

Bij een HD worden alle blokken van een bestand of veel gebruikte blokken bij elkaar gezet zodat de leeskop niet steeds hoeft te bewegen.

Bij een SSD zijn geen bewegende delen. Er is ook geen vertraging als een bestand uit blok 123 en 456 komt tov 123 en 124.
Defragmentatie is gelukkig met de komst van SSD`s een irritant iets uit het verleden.

[dasiro]

meer nog, fragmentatie is zelfs goed voor SSD's omdat de levensduur dan gerokken wordt, doordat je niet steeds dezelfde posities gebruikt op de chips.

[Grrrrrene]

Dat geldt alleen voor bestanden die je vaak nodig hebt, je swap file of opstartbestanden bijvoorbeeld en dan nog: tegenwoordig kunnen die dingen 1M lees/schrijfacties aan. Dat is heel heel heel lang voor je ssd kapot gaat. Het punt is alleen dat daar nu harde cijfers over beschikbaar zijn en iedereen er ineens op gaat letten. Heb je ooit zoveel aandacht voor mtbf-cijfers gezien?

[OddesE]

meer nog, fragmentatie is zelfs goed voor SSD's [...]

Nee dat lijkt me onzin. Of je file nou op blokken 1, 2 en 3 staat of op blokken 235, 12 en 187 maakt verder niets uit. Waar het over gaat is hoevaak je hetzelfde blok opnieuw schrijft. Tuurlijk, als je steeds gaat defraggen dan zul je dezelfde blokken vaker beschrijven, en dat is slecht. Maar volgens mij kun je het omgekeerde niet stellen, dat veel fragmentatie goed is. Oftewel, fragmentatie is geen goedkoop alternatief voor een slim algoritme om schrijfacties te spreiden.

[stok]

Sorry, maar 'gerokken'?

Gerekt.

[Verwijderd]

Hoi Sandisk, er zijn ook mensen die geen Vista gebruiken en wel geïntereseerd zijn

[ArawnofAnnwn]

Inderdaad, ik denk zelfs dat de meeste mensen die SSD's gebruiken, geen vista draaien. Ik denk eerder dat het in de regel meer gebruikt zal worden voor embedded oplossingen (XP/Linux) dan in normale desktops, en als het al in desktops gebruikt word, dan is het door mensen die graag een snel systeem willen, en dat is een niche markt, dus zal dat ook richting XP en Linux gaan. Daarnaast word het ook al gebruikt in de servermarkt, en daar word geen vista gebruikt, aangezien dat geen server versie heeft. Dat zijn dan weer de Unix/Linux systemen, en de Server 2003/2008 systemen. Vista zie je in de regel toch alleen bij mensen die een systeem gekocht hebben van een leverancier en niet weten hoe ze XP moeten installeren. (ik hoor regelmatig mensen die dat niet kunnen of niet durven, en om die reden bij vista blijven).

[Cergorach]

Wat moeten die embeded systemen met SSDs van 128GB+?

Vista werkt prima op laptops, er moet echter wel een behoorlijke sloot geheugen in zitten (ten opzichte van XP/Linux), maar als je SSDs van 128GB kan betalen dan zal 2GB voor je laptop.

Vista => Windows Server 2008. En binnen een hele hoop bedrijven wordt er windows op servers gebruikt, nu zullen ze niet allemaal zijn overgestapt op 2008...

Persoonlijk ga ik eerdaags overstappen van XP-32bit naar Vista-64bit, voornamelijk omdat het 'rijgedrag' van Vista wat soepler blijkt te zijn, daar staat tegenover dat de 'maximum snelheid' die je er uit kan halen iets lager is. Maar processor snelheid is al heel lang niet meer een issue voor mij sinds ik een quad core heb (Q6600).

Ik vind dit een heel slap excuse van SanDisk, Vista is nogal een tijd uit en dit 'probleem' hadden ze veel eerder constateren. Het is tegenwoordig wel heel makkelijk om Vista de schuld te geven.

[Verwijderd]

Met een quadcore en 4GB zal 64 bits Vista ook gewoon sneller zijn dan XP

[hiostu]

Windows Server 2008 heeft dezelfde kernel als Vista. Plus server systemen gebruiken denk ik andere oplossingen voor SSD.

[OddesE]

Vista zie je in de regel toch alleen bij mensen die een systeem gekocht hebben van een leverancier en niet weten hoe ze XP moeten installeren.

Nou nou dat lijkt me toch niet. Vista staat gewoon op heel veel nieuwe PC's die worden gekocht, ook door (grote) bedrijven. Over één of twee jaar staat het gewoon op alle nieuwe systemen. De gedachte dat alleen n00bs het zouden draaien vind ik lachwekkend. Volgens mij heb je hier last van projectie.

[watercoolertje]

Man toch, moest xp dat kunnen zou vista het zeker kunnen, vista en xp hebben dezelfde basis kernel.

En dat geloof je zelf?

[Verwijderd]

Euhm ja, omdat dat zo is.

XP, 2K, 2K3, Vista, 2K8 zijn opgebouwd vanuit de NT kernel.
Dus ja ik denk wel dat ik gelijk heb.

Het is alsof je zou zeggen dat Ubuntu niet als basis Unix gebruikt en suse wel.

Dat ze me daarvoor een troll geven hier, ja dat is weer typisch deze site vol subjectieve mods.

[Plofkotje]

Ubuntu en SUSE gebruiken als basis beide niet het klassieke UNIX. Linux is een UNIX-like operating system, geen echte UNIX variant..

[Verwijderd]

'T gaat hier blijkbaar om drivers en daar is Vista radicaal aangepast.

[3raser]

Dus alle drivers die in Suse werken, doen dat ook in alle andere distributies?
Ze gebruiken tenslotte allemaal Unix als basis.

[Cyphax]

Het is wel off-topic onderhand, maar ja: drivers die in Suse werken werken ook in ubuntu en andersom, als ze dezelfde kernel gebruiken. Het kan afwijken met versies, maar aangezien 99% van de drivers met de kernel worden meegeleverd...

Ontopic: jammer dat een fabrikant wegens een tekortkoming in Vista het product maar niet op de markt brengt. Het komt een beetje over als een smoes (hoeft het zeker niet te zijn). Aan de andere kant: als de drivers van Vista niet goed zijn willen ze niet riskeren dat teveel mensen slechte ervaringen hebben met hun product, en dat kan ik ook wel weer begrijpen.

[arjankoole]

XP, 2K, 2K3, Vista, 2K8 zijn opgebouwd vanuit de NT kernel.

Tja, maar om nou rücksichtslos die kernels met elkaar te gaan vergelijken? Het hele driver model voor vista is compleet niet compatible met XP bijvoorbeeld, dus in de kernel versies onderling zitten wel degelijke grote verschillen.

Je kan een linux 2.4 kernel ook niet vergelijken met een 2.6 kernel.

[Navi]

De nieuwe OCZ Core SSD's, zijn die eigenlijk op MLC technology of SLC?

Daar hoor ik verder niks over kwa compatibiliteit met vista?

[gertvdijk]

SLC, want anders waren de access times ook niet zo ontzettend laag
Verder zijn over het algemeen alleen de SLC memory chips die in aanmerking komen voor het Vista Readyboost certificering.

[sergev]

Daar moet ik je toch corrigeren. Ocz heeft ssd's op mlc. Verschillende fabrikanten hebben ook al ssd's op mlc aangekondigd want ze hebben de schrijfsnelheid van mlc flash geheugen op weten te schroeven. En accestimes zijn bij slc en mlc nauwelijks verschillend. Het belangrijkste verschil lag altijd in prestaties, de schrijfsnelheden dus.
Verder denk ik dat omdat mlc ingewikkelder werkt vista het niet aankan. Slc is heel simpel een bit per cel, terwijl mlc 2 bits per cel op kan slaan. Vista is schijnbaar niet voldoende geschikt om data te schrijven naar multibits cellen. Maar zoals in het artikel ook al gemeld wordt kan het ook zo zijn dat sandisk gewoon niet zo snel op de nieuwe ontwikkelingen in kan spelen en gewoon een excuus nodig heeft om zijn aandeelhouders tevreden te stellen.

[OddesE]

Mmm.. raar verhaal. Het is toch gewoon een harddisk die je aansluit via standaard SATA aansluitingen? Voor zover ik weet doet Vista daar hoegenaamd niets mee. Vista is zeker niet vernatwoordelijk voor welke bits in welke cellen terechtkomen ofzo. Voor het OS is de harddisk gewoon een black box waar je data heenstuurt. De drivers zouden misschien wel op zon laag niveau werken, maar zelfs dan denk ik dat zaken als welke bit in welke zel terechtkomen door de HDD zelf, inwendig worden bepaald.

Ik zou graag wat onderbouwing horen van de heren van Sandisk, maar zoals ik het nu lees kan ik maar een conclusie trekken: Smoesjes.

[Toontje_78]

Een block device is een block device.

Besturingssystemen horen er niets van te merken, wat er ook aan de interface hangt.

[flippy]

dus de accesstijden van MLC zijn traag?

[OddesE]

Niet traag, maar laag. Lage accestime == snel

[Verwijderd]

De OCZ core series gebruikt geselecteerde MLC's

[SSD] Wat is er beschikbaar en werkt het ?
http://blog.laptopmag.com...lc-flash-will-reach-256mb

De snelheid is bereikt door een "meerdere kanalen configuratie" te gebruiken in combinatie met speciaal gemaakte firmware, aldus de CEO van OCZ.

Ze hebben de nadelen van MLC dus weten te omzeilen blijkbaar.

[Reactie gewijzigd door Verwijderd op 26 juli 2024 01:42]