(nog wat stukken van mijn posts uit het andere topic hierheen overgezet)
Ik kom op iets minder dan 3 MB/sec, dat is aardig traag ja.
en als ik iets vanaf mijn harddisk naar een externe harddisk kopieer gaat dat ook met slechts 3.5MB's. Kopieren vanaf de externe hd naar mijn lokale hd gaat wel gewoon met 20MB/s.
En dat vind ik ook vreemd...
Nu iets heel vaags. Ik log uit en log in onder een ander account en daarbij werkt alles WEL gewoon snel (alles wat ik hierboven noemde met zo'n 20MB's ipv. 3.5MB/s). Daarna log ik uit en weer in onder mn eigen account en hij kopieert nu wel gewoon snel naar mn NTFS-partitie. Dit is best wel vreemd, omdat ik voor de zekerheid al een keer gereboot had.
Merk op dat als je niet gereboot hebt tussen die account-wisselingen en je getest hebt met dezelfde file, de resultaten vertekend zullen zijn door caching. Als je genoeg geheugen hebt (bv 2GB terwijl je test met een 700MB file) dan zal de inhoud van die file gecached worden waardoor hij de volgende keer niet meer van je disk gelezen hoeft te worden.
Toevallig heb ik vandaag ergens gelezen hoe je die caches kan flushen, dus dat kunnen we hier mooi in de praktijk brengen
Op mijn systeem zie ik het volgende (met dd omdat die mooi de snelheden weergeeft):
# sync; echo 3 >! /proc/sys/vm/drop_caches
% dd if=test.in of=test.out bs=4K conv=fsync
734107648 bytes (734 MB) copied, 39.8148 s, 18.4 MB/s
% rm test.out; sync
% dd if=test.in of=test.out bs=4K conv=fsync
734107648 bytes (734 MB) copied, 20.1204 s, 36.5 MB/s
# sync; echo 3 >! /proc/sys/vm/drop_caches
% dd if=test.in of=/dev/null bs=4K
734107648 bytes (734 MB) copied, 17.3096 s, 42.4 MB/s
% dd if=test.in of=/dev/null bs=4K
734107648 bytes (734 MB) copied, 1.15084 s, 638 MB/s
(commando's met # moeten als root uitgevoerd worden, die met % mogen als user)
Eerst clear ik dus de caches, en daarna kopieer ik met ongeveer 18 MB/sec.
Daarna is test.in volledig aanwezig in cache, en een tweede kopieer-actie (na verwijderen test.out) hoeft dus niks meer van disk te lezen, alleen maar te schrijven, en de snelheid ligt daardoor een stuk hoger (36 MB/sec).
Ik clear de caches nogmaals, en kopieer test.in naar /dev/null. Daarvoor hoeft alleen maar van disk gelezen te worden, en dat gaat met 42 MB/sec.
Nu is test.in weer volledig in geheugen aanwezig, en nogmaals naar /dev/null kopieren heeft de harddisk helemaal niet meer nodig en is dus beperkt door CPU- en geheugensnelheid (638 MB/sec).
Wat voor snelheden zie jij zoal? Ik ben vooral benieuwd naar uncached file->devnull, aangezien je daarop zo'n lage snelheden haalde (3 MB/sec harddisk -> externe HD).
Ik gebruik een andere I/O scheduler (anticipatory) dan standaard is (cfq), al leek dat in mijn tests niet al te veel uit te maken. Maar als je wil dan kun je het ook met anticipatory proberen:
# cat /sys/block/hda/queue/scheduler
noop [anticipatory] deadline cfq
(kun je veranderen door de gewenste naam ernaar te echo'en)
Ik heb overigens een MSI K8T moederbord + athlon64 3200 en VIA S-ATA chipset.
Hmm, ik heb best slechte ervaringen met disk I/O performance op Via chipsets onder GNU/Linux (geen idee van de performance onder Windows): lage throughput, en een traag en slecht-reagerend systeem onder zware disk I/O. Vervanging door Intel of nForce chipsets deed de performanceproblemen verdwijnen.
Maar dat was wel met oudere chipsets (P2/P3/athlon tijdperk).
DrClaw schreef op woensdag 30 juli 2008 @ 02:11:
voor degene met de langzame harddrives .. pas eens je /etc/fstab aan voor een langzame drive, en zet bij de options van desbetreffende partitie eens 'noatime,nodiratime' zonder de quotes neer:
Een paar dingen:
- atime heeft vziw vooral effect als je veel files benadert. Voor één grote file zou die overhead verwaarloosbaar moeten zijn.
- nodiratime is niet nodig als je noatime gebruikt
- sommige programma's zijn afhankelijk van correct atime gedrag (maar dat zijn er niet veel)
Verder altijd een interessante performance tweak. Relatime is ook nog een interessante optie.
verder kun je eens kijken of er in je bios, danwel in je grub bootloader config, aangegeven staat of je 'noapic' hebt aangegeven. Dit is een fallback methode voor oudere pctjes, wat een beperktere set van IRQs gebruikt, die gedeeld moeten worden.
Mja, apics zijn mooi enzo, maar ik weiger te geloven dat dat zo'n performanceverschil veroorzaakt.
/u/26742/000000751.png?f=community)
/u/164410/Untitled-2.png?f=community)
:strip_exif()/u/26278/wapen60.gif?f=community)
:strip_icc():strip_exif()/u/1508/sax_k.jpg?f=community)