Flash Benchmark

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.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-Share Alike 2.5 License.