Spring naar inhoud

Waarom de Asus EEEPC zo langzaam is onder windows.

We hebben bij onze klanten diverse EEEPC's in de running. Toen deze leuke kleine laptopjes net uitkwamen was er keuze uit de 7" versie in diverse hippe kleuren. Deze EEEPC-700 draait standaard onder een speciaal aangepaste linux versie die erg goed werkt. Omdat er slechts een 4Gb SSD (dat is een soort flash harddisk) in zit is Windows XP geen optie op deze 7" EEEPC. Op de beperkte beelscherm grootte na was iedereen tevreden over deze leuke snelle laptop.

Een maand of twee later kwam de EEEPC-900 beschikbaar. Ietsje duurder was ie, maar met een 9" scherm en een SSD van 20Gb "zou" deze versie prima geschikt zijn voor Windows XP was de verwachting. De eerste teleurstelling kwam echter snel toen bleek dat er 2 SSD's in zaten. Eentje van 4GB en eentje van 16GB. De laptoppies werden ook nu weer uitgeleverd met een leuke snelle linux distributie geinstalleerd op de eerste 4Gb SSD.

Het plan was snel getrokken. We zouden de linux laten staan op de eerste SSD en via een dual-boot configuratie windows XP installeren op de tweede SSD van 16Gb. Zo kon de klant kiezen wel OS hij wou gebruiken. Natuurlijk had dit nogal wat voeten in aarde (het is nauwelijks te doen om windows te laten booten vanaf een 2e disk); maar de aanhouder wint en wij hadden na een aantal middagen pionierswerk een mooie dual-boot configuratie met een werkende linux én windows.

"Eind goed; al goed" zou je denken. Een betere uitdrukken zou "Helaas, Pindakaas" zijn, want de Windows-XP installatie was niet vooruit te branden. ZEER langzaam met veel vertragingen. Soms bleef het systeem tientallen seconden "hangen" om daarna weer verder te draaien alsof er niks aan de hand was. Er was zo absoluut niet mee te werken.

Benchmark EEE C schijf ATTO
Benchmark EEE C schijf ATTO
Benchmark EEEPC D schijf ATTO
Benchmark EEEPC D schijf ATTO

Toen zijn we wat benchmarks gaan draaien om te kijken waar de bottleneck zat (zie afbeeldingen links). Het bleek al snel dat de 4Gb SSD disk sneller was als de grote 16Gb disk. De leessnelheid van de D schijf zit met 30 Mb/s op zo'n beetje driekwart van de C schijf (42 Mb/s). De schijfsnelheid liep daar nog wat verder bij achter. De D schijf schrijft met 14 Mb/s; zowat de helft dan de C schijf die dat met 25 Mb/s doet.

Geen mooie meetwaarden, maar ze zijn nou ook weer niet zo extreem laag als je zou verwachten gezien de performance van Windows XP.

Toch maar de stoute schoenen aangetrokken en windows als enig OS geinstalleerd. Qua ruimte kon dat niet op de C schijf; dus we hebben een speciale "n-lited" editie van Windows XP gebakken zodat Windows zelf met de DLL's, registry en tempfiles op C staat en documenten, bureaublad, settings en temporary internetfiles op D. Deze versie hebben we vervolgens geinstalleerd, de index service verwijderd, de swap teruggezet naar een paar MB (swap is verplicht voor veel applicaties) en wat overige optimalisaties gedaan.

Nu draait windows op z'n best gezegd redelijk. Er zijn nog wel wacht-momenten, maar die duren "slechts" 2 a 3 seconden. In deze staat hebben we de EEE-PC's afgeleverd aan onze klanten die persé windows willen draaien.

Omdat we toch van nature erg nieuwsgierig zijn zijn we nog wat meer benchmarks gaan draaien om te kijken wat de oorzaak van de nog steeds aanwezige vertragingen was. De meeste benchmarks geven best redelijke waarden zoals de ATTO benchmark die ook weergeeft. Sommige benchmarks gaven echter op de random write test extreem lage waarden.

Benchmark EEEPC D schijf Crystalmark
Benchmark EEEPC D schijf Crystalmark
Benchmark EEEPC C schijf Crystalmark
Benchmark EEEPC C schijf Crystalmark

Bijvoorbeeld de CrystalDiskMark 2.2 test behalve op sequentiële snelheden (het achter elkaar lezen van blokken data) ook op de random access snelheden (op willekeurige positie lezen/schrijven van blokken data). Hoewel de sequentiële snelheid wel in orde is en overeenkomt met de overige benchmarks ligt echter de random access snelheid beduidend lager. Vooral de schrijfsnelheid is met recht dramatisch te noemen. Op zowel de C schijf als de D schijf zakt de schrijfsnelheid voor random blokken van 4Kb naar onder de 0.1 Mb/s.

Wat onderzoek naar de werking van SSD's bracht het volgende naar voren. Als er data geschreven moet worden op een SSD dan moet de bestaande data eerst gewist worden (erase cycle) voordat de nieuwe data geschreven kan worden. Het probleem is dat deze erase cycle alleen per blok uitgevoerd kan worden. Afhankelijk van het type SSD is de grootte van zo'n blok 128Kb t/m 4Mb. Als we nu eens uitgaan van een SSD eraseblockgrootte van 2MB voor de D schijf; dan geldt dat  als er een stukje random data van 4kb geschreven moet worden, de controller eerst 2048Kb moet lezen, in dat gelezen block op de juiste plek de 4kb gewijzigde data neerpoten, dan 2048Kb moet wissen en tenslotte 2048 moet schrijven. Dit betekent dat er 6144Kb aan data transfer is voor deze 4Kb. Dat is een overhead van een factor 1536!

Kunnen we nu de extreem lage 4k random write verklaren? Ja; want de leessnelheid op de D-schijf van 30Mb per seconde (gemeten met crystalmark) gedeeld door 1536 is zo'n beetje de 18kb/s die de Crystalmark meet. Voor de C schijf geldt bijna hetzelfde. Deze gebruikt waarschijnlijk een kleiner erase-block-size van 1Mb. Als we dan 4kb schrijven dan hebben we met een totale transfer van 3072Kb een overhead van een factor 768. Delen we nu de sequential read snelheid van 41Mb/s door deze factor dan krijgen we 53kb/s. En dat is dan weer bijna de 62kb/s die we meten.

Voor dit probleem zijn een aantal oplossingen denkbaar. Zo is er met een goede write-cache al veel op te lossen door veel kleine wijzigingen in een bepaald gebied te cachen en ineens weg te schrijven. Ook is het NTFS filesystem niet erg geschikt voor SSD's. Onder linux is er het JFFS2 filesystem dat speciaal ontworpen is om met flash geheugen te werken. Hierbij worden random writes fysiek achter elkaar als sequential write geschreven. Hiermee zijn grote snelheidsvoordelen te behalen. Tenslotte is er natuurlijk ook nog de aller-evidentste oplossing; namelijk het verminderen van de random writes door de harddisk niet als buffer te gebruiken.

Terugkomend op de titelvraag waarom de EEEPC zo langzaam is onder windows kunnen we nu concluderen dat dit het geval is omdat windows blijkbaar veel kleine wijzigingen op de SSD wil doorvoeren wat gewoon te langzaam is voor flash opslag. De bijgeleverde Xandros linux distributie doet dat al veel beter door voor de diverse tijdelijke bestanden gewoon een ramdisk te gebruiken. Optioneel is met bijvoorbeeld de linux distributie EEE-Ubuntu ook JFFS mogelijk.

In de praktijk is het handig om de volgende stelregel aan te houden: Voor een redelijke performance is de EEEPC met windows leverbaar, maar voor een snelle EEEPC kan het beste de bijgeleverde Xandros Linux distributie gebruikt worden.