Il test si compone di tre parti:
- verifica delle prestazioni in scrittura del supporto
- verifica indipendenza prestazioni dal pc che scrive
- correlazione delle prestazioni con il filesystem e il tipo di scrittura
Verifica delle prestazioni in scrittura del supporto
PC: Acer Aspire 5051
OS: Ubuntu 6.10
FS: EXT3,async,noatime
UF: Kingston 2Gb Data Traveler 2.0
rm -f /media/usbdisk/test; sync
time (dd if=/dev/zero bs=1M count=$size >/media/usbdisk/test; sync)
Valori espressi in Kb/s per scrittura di file di dimensione:
| 10Mb | 100Mb | 1000Mb |
|---|---|---|
| 1955 | 3047 | 3742 |
| 1913 | 2892 | 3695 |
| 3041 | 5058 | |
| 1912 | 5025 | |
| 1915 | 5183 | |
| 2146 | ||
| 2179 | ||
| 2822 | ||
| 1919 | ||
| 2835 |
Le prestazioni in scrittura variano da 1912 a 5183 Kb/s, cioè da 1.9 a 5.2 Mb/s.
Verifica indipendenza prestazioni dal pc che scrive
PC: Asus e³PC 4G (701)
OS: Xandros per e³PC
FS: EXT3,async,noatime,data=ordered
UF: Kingston 2Gb Data Traveler 2.0
rm -f /media/usbdisk/test; sync
time (dd if=/dev/zero bs=1M count=$size >/media/usbdisk/test; sync)
Valori espressi in Kb/s per scrittura di file di dimensione:
| 10Mb | 100Mb | 1000Mb |
|---|---|---|
| 1932 | 5318 | 3808 |
| 2474 | 5195 | |
| 3393 | 4921 | |
| 3386 | 4978 | |
| 2891 | 4909 |
Le prestazioni in scrittura variano da 1932 a 5318 Kb/s, cioè da 1.9 a 5.3 Mb/s.
Correlazione delle prestazioni con il filesystem e il tipo di scrittura
Il tipo di piattaforma HW e/o la pre-emption del kernel permettono una più o meno ripetibilità delle misure per dimensione di file fissa più che altro la Ubuntu 6.10 ha una pletora di servizi attivi in più rispetto a e³PC Xandros quindi non stupisce la maggiore variabilità sui file da 10 e 100Mb.
La lunghezza del file pare influenzare la velocità di scrittura in particolare si può dire che su un file piccolo 10Mb/s è difficile raggiungere la massima velocità di scrittura (per via del filesystem) mentre su file molto grandi è difficile mantenere la velocità di scrittura massima:
| inizializzazione filesystem | data transfer | finalizzazione del filesystem |
Risulta perciò che per file di 10Mb si possa misurare la velocità massima in scrittura sul supporto a filesystem fissato mentre per file di 1000Mb la velocità media.
Confronto fra filesystem: EXT2 vs EXT3
PC: Asus e³PC 4G (701)
OS: Xandros per e³PC
FS: EXT2,async,noatime
UF: Kingston 2Gb Data Traveler 2.0
| 1Mb | 10Mb | 100Mb | 1000Mb |
|---|---|---|---|
| 1548 | 4184 | 4570 | |
| 1517 | 4812 | 4452 | |
| 4825 | 4439 | ||
| 4792 | |||
| 4586 |
Le prestazioni in scrittura sono intorno ai 4.5 Mb/s con una variazione inferiore a +/- 10% per file grandi (dai 10Mb in su).
Dal confronto e dall'intuizione delle prove con file da 1Mb appare che EXT3 lavora in maniera da ripetere un certo schema interlacciato:
| inizializzazione filesystem | data transfer | journal | data | … | journal | data | finalizzazione filesystem |
che rende le prestazioni fluttuanti e mediamente inferiori a EXT2 che invece ha uno schema più vicino a quello più semplice precedentemente mostrato.
Confronto fra filesystem: VFAT vs EXT2
SD sandisk 2 Gb extreme 2
si prende la moda:
for i in $(seq 1 20); do dd if=/dev/zero bs=1M count=$size of=/dev/sdb
seek=$[$RANDOM%1000] 2>&1 | grep copied; done | sort
| no filesystem | VFAT | ||||||
| 1Mb | 10Mb | 100Mb | 1Mb | 10Mb | 100Mb | 1000Mb | |
|---|---|---|---|---|---|---|---|
| 7,8 Mb/s | 7,6 Mb/s | 988 kB/s | 6393 | 6615 | 7560 | 7771 | |
| 2668 | 7468 | 7472 | 7566 | ||||
| 4481 | 4458 | 7527 | |||||
| 4245 | 4504 | 7424 | |||||
| 6432 | 7415 | 7420 | |||||
| 6278 | 5661 | ||||||
| 5698 | 7420 | ||||||
| 6393 | 7431 | ||||||
| 6432 | 7500 | ||||||
| 6316 | 6278 | ||||||
Il valore a 100Mb senza filesystem è anomalo ma si spiega tramite questa sequenza di misure che è mirata alla ricerca della grandezza della cache interna alla SD che è di 32Mb:
100Mb: 988 Kb/s
50Mb: 1.4 Mb/s
25Mb: 7.6 Mb/s
38Mb: 1.1 Mb/s
32Mb: 7.6 Mb/s
35Mb: 1.0 Mb/s
33Mb: 980 Kb/s
si prende la moda:
for i in $(seq 1 100); do dd if=/dev/zero bs=$chunk count=$count of=/dev/sdb
seek=$[$RANDOM%($totchunk-1)] 2>&1 | grep copied; done | sort
1M,1: 7.6 Mb/s (3.1 - 8.0 Mb/s)
512k,2: 4.6 Mb/s (2.2 - 7.9 Mb/s)
32k,32: 3.3 Mb/s (2.1 - 7.6 Mb/s)
8k,128: 2.3 Mb/s (1.8 - 7.7 Mb/s)
1k,1024: 1.7 Mb/s (1.0 - 2.3 Mb/s)
mkfs -t ex2 -b $block /dev/sdb
tune2fs -m0 /dev/sdb
cd
rm -f test*; sync; time (dd if=/dev/zero bs=$chunk count=$count of=test; sync)
block=4096
1M,100: 15.665s
128k, 800: 18.700s
block=1024
1M,100: 27.782s
128k, 800: 26.661s
rm -f test*; sync; time (for i in $(seq 1 100); do dd if=/dev/zero bs=$chunk count=$count of=test$i 2>/dev/null; done; sync)
block=4096: 1950880 Kb
8k,128: 100 Mb in 47.842s
1M,1: 100 Mb in 44.817s
block=1024: 1950504 Kb
8k,128: 100 Mb in 48.147 s, 2126 Kb/s
1M,1: 100 Mb in 44.849 s, 2283 Kb/s
mkfs.vfat -s 4 -S $[4*1024] -v -I /dev/sdb
non pare portare analoghi vantaggi
Confronto fra diverse modalità di scrittura:
Utilizziamo uno schema di scrittura più complesso dove oltre alla dimensione del file vi siano altri parametri e operazioni impostabili
rm -f /media/usbdisk/test
mount -o remount,$option /media/usbdisk; sync
time (for i in $(seq 1 10);
do
dd if=/dev/zero bs=1M count=$size >/media/usbdisk/test;
$oper1;
done; $oper2)
La dimensione del file viene ridotto a 1M in maniera da rendere ancora più appariscente l'influenza del tipo di scrittura:
| scenario | option | oper1 | oper2 | 1Mb | range |
|---|---|---|---|---|---|
| #1 | async | (sync &) | sync | 4250 | 1.6-4.8 |
| 1616 | |||||
| 3048 | |||||
| 1911 | |||||
| 4777 | |||||
| #2 | async | sync | 4647 | 2.7-4.6 | |
| 2711 | |||||
| 2949 | |||||
| 3345 | |||||
| 3707 | |||||
| #3 | async | sync | 2509 | 2.3-2.8 | |
| 2728 | |||||
| 2573 | |||||
| 2840 | |||||
| 2260 | |||||
| #4 | sync | sync | 1682 | 1.6-1.8 | |
| 1571 | |||||
| 1648 | |||||
| 1764 | |||||
| 1654 | |||||
| #5 | sync | 1857 | 1.3-1.9 | ||
| 1464 | |||||
| 1790 | |||||
| 1798 | |||||
| 1291 | |||||
| #6 | async | (rem,ro; rem,rw) | 3866 | 2.5-4.7 | |
| 4211 | |||||
| 2453 | |||||
| 4723 | |||||
| 4689 | |||||
| #7 | async | (rem; sync) | 2539 | 2.5-4.7 | |
| 3657 | |||||
| 4662 | |||||
| 4725 | |||||
| 3380 | |||||
| #8 | async | (rem) | 4708 | 2.9-4.7 | |
| 4283 | |||||
| 2850 | |||||
| 3730 | |||||
| 4281 | |||||
| #9 | async | (sync &) | (rem) | 1653 | 1.7-4.9 |
| 2525 | |||||
| 4859 | |||||
| 2542 | |||||
| 2500 |
rem,xx: mount -o remount,xx /media/usbdisk
Gli scenari #4 e #5 mostrano che la modalità EXT2 sync è quella più limitata come prestazioni da 1.3 a 1.9 Mb/s.
Gli scenari #2, #6, #7 e #8 sono equivalenti a un EXT2 finalizzato e le prestazioni praticamente uguali da 2.5 a 4.7 Mb/s.
Gli scenaro #1 e #9 simulano un'interazione tipo EXT3 basata su EXT2 e infatti le prestazioni simili da 1.6 a 4.9 Mb/s.
Lo scenario #3 async simula uno scenario EXT2 sync e ottiene prestazioni da 2.3 a 2.8 Mb/s, probabilmente scendendo alla dimensione dei file fra 100 e 10Kb si otterrebbero prestazioni equivalenti alla modalità sync reale.
Conclusioni
Lo scenario #3 confrontato con #4 e #5 fanno sospettare, così come il buon senso vorrebbe, che la sincronizzazione del filesystem più è fitta e più le prestazioni sono basse. Ma questo non è una regola aurea infatti se fosse vero in assoluto allora EXT3 risulterebbe molto lento almeno come EXT2 sync invece, sebbene al peggio lo sia, riesce a essere anche più prestante di EXT2 probabilmente perchè il processo di sincronizzazione di questo alla fine non è ottimale come si vorrebbe. In passato ho verificato su particolari sistemi che la sincronizzazione finale è molto molto più veloce ottenerla mediante un mount -o remount piuttosto che un comando di sync.
