USB Performance mit ext2 Dateisystem verschlechtert

[Fox.Mulder]

Beim Vergleich der Geschwindigkeit des gleichen Datenträgers, und gleiche zu übertragende Datei habe ich mit unterschiedlichen Freetz-FW-Versionen einen deutlichen Einbruch der USB Ext2 Performance auf einer 7270 festgestellt:

jeweils Maximalwerte

54.04.99-10771-freetz-2342M
ext2: 4,5 MByte/s

54.04.67freetz-devel-2846M
ext2: 3,6 MByte/s

Das bedeutet ein Verschlechterung von 20%. Hat jemand eine Idee, wodurch diese Verschlechterung verursacht wird und wie diese ggf. zu beheben ist?

Früher wurde ja der ext2 Treiber, welcher von AVM mitgeliefert wurde, verwendet. Bei der aktuellen FW ist aber kein ext2 Treiber mehr enthalten, so dass dieser von Freetz bereitgestellt wird.

VG. M.

 

[cuma]

Also ich komme problemlos in den MegaByte-Bereich

 

[Fox.Mulder]

War natürlich MByte/s gemeint. Oben berichtigt. Sind trotzdem min. 900 kByte/s weniger und das tut bei der nicht gerade berauschenden Performance der Fritzbox schon weh.

 

[cuma]

Wie hast du denn gemessen? Am besten ist "time dd" dazu geeignet. Über Netzwerk per Samba ist sehr CPU-lastig

 

[Fox.Mulder]

Ich messe immer mit TotalCMD. Die Verbindung läuft über ftp und auf der Box nutze ich vsftpd. Die Kette ist mit beiden FW Versionen die gleiche bis hin zu verwendeten Datenträger und der verwendeten Datei. Es handelt sich um Maximalgeschwindigkeiten. Könnte also sein, dass der Unterschied bei richtiger Messung noch größer ist.

Was macht time dd?

VG. M.

 

[cuma]

Ext2 3,5" HDD

Schreiben:

time dd if=/dev/zero of=dd.tmp count=1M bs=100
real    0m 33.14s

~3,02 MB/s

Lesen

time dd if=dd.tmp of=/dev/null count=1M bs=100
real    1m 6.58s

~1,5 MB/s

Stimmt, irgendwie lahm!

 

[rgrr]

Zuerst habe ich den dd-Test auch so laufen lassen wie cuma und musste ganz schön schlucken, da bei mir richtige Katastrophenwerte herauskamen.

Kleine Korrektur macht das besser:

Schreiben:

/var/media/usb-hdd # time dd if=/dev/zero of=dd.tmp count=100 [b]bs=1M[/b]
[b]sys     0m 7.88s[/b]

--> ~12.5MB/s

Lesen

/var/media/usb-hdd # time dd if=dd.tmp of=/dev/null count=100 [b]bs=1M[/b]
[b]sys     0m 4.32s[/b]

--> ~23MB/s

Hardy

 

[cuma]

Mit den vertauschten Parametern bekomme ich 6,5MB/s schreiben. Du musst aber "real"-Zeit nehmen!

time dd if=/dev/zero of=dd.tmp count=100 bs=1M
real    0m 14.99s
sys     0m 3.22s

time dd if=dd.tmp of=/dev/null count=100 bs=1M
real    1m 6.23s
sys     0m 0.08s

 

[rgrr]

Hi cuma,

meine Zahlen:

time dd if=/dev/zero of=dd.tmp count=100 bs=1M
real    0m 5.66s
sys     0m 3.47s
--> ~18MB/s

time dd if=dd.tmp of=/dev/null count=100 bs=1M
real    0m 7.26s
sys     0m 4.40s
--> ~14MB/s

Alte Zahlen: mit 10M-Blöcken beim Schreiben 5.6s (~18MB/s), 'cat dd.tmp > /dev/null' 7.7s (~14MB/s) (beides ext2).
[b]Veränderung gegenüber der alten Firmware ist bei mir vernachlässigbar![/b]

Das Interessante an Deinen Zahlen ist, dass bei Dir der Unterschied zwischen real und sys sehr gross ist. Woran kann das liegen?

Hardy

 

[Fox.Mulder]

Meine Zahlen mit neuer Firmware (FW Version s. 1. Beitrag):

time dd if=/dev/zero of=dd.tmp count=100 bs=1M
real    0m 14.32s
sys     0m 2.70s

time dd if=dd.tmp of=/dev/null count=100 bs=1M
real    0m 12.21s
sys     0m 3.93s

ältere FW:

time dd if=/dev/zero of=dd.tmp count=100 bs=1M
real    0m 15.52s
sys     0m 2.93s

time dd if=dd.tmp of=/dev/null count=100 bs=1M
real    0m 12.87s
sys     0m 3.42s

Also wäre USB seitig die neue FW marginal schneller.
Werde aber nochmal eine Datei in einem schnelleren Bereich der Platte ausprobieren. Habe dazu eine bereits vorhandene Datei verwendet, also nicht dd.tmp - deshalb auch nur lesend

ältere FW:
time dd if=??? of=/dev/null count=100 bs=1M
real    0m 11.03s
sys     0m 3.48s

neue FW:
time dd if=??? of=/dev/null count=100 bs=1M
real    0m 12.66s
sys     0m 4.13s

also ca. 15% langsamer mit der neuen FW

Vergleich der lesenden Übertragung derselben Datei per ftp (vsftpd TotalCMD):

ältere FW: 143s für 608,71 MByte = 4,26 MByte/s
neue FW: 176s für 608,71 MByte = 3,46 MByte/s

also 23% langsamer mit der neuen FW

Könnte es einen zusätzlichen Flaschenhals zwischen USB Treiber und vsftpd geben?
Warum die oberen Zahlen invers zu den unteren Ergebnissen ausfallen kann ich mir auch nicht erklären...

 

[Darkyputz]

servus kinners...

time dd if=/dev/zero of=/var/media/ftp/uStor02/dd.tmp count=100 bs=1M

ergibt

real 0m 9.02s
user 0m 0.00s
sys 0m 3.76s

 

[cuma]

Ich frag mich, weshalb ich nur 1,5MB beim lesen hab

 

[rgrr]

Netzwerkperformance oder allgemein Performancemessung

...
Könnte es einen zusätzlichen Flaschenhals zwischen USB Treiber und vsftpd geben?

Du könntest die Netzwerkperformance mit netcat messen, z.B.:

FB->PC:
  auf PC: nc -l -v 10000 > /dev/null
  auf FB: time dd if=/dev/zero bs=1M cnt=100 | nc <ip-pc> 10000

PC->FB:
  auf FB: nc -l -p 10000 > /dev/null
  auf PC: time dd if=/dev/zero bs=1M cnt=100 | nc fritz.box 10000

Hat bei mir mit alter Firmware 32s (FB->PC) und 22s (PC->FB) gedauert.

Hardy


PS: die Syntax weicht bei den netcats ab. Auf meinem PC lief ein nc.openbsd. Also probieren (bzw man lesen)

 

[Darkyputz]

hmm..wie schliesst ihr denn aus den sekunden auf die MB/s??
was habe ich denn danngehabt bei meinem test oben?

 

[frank_m24]

Hallo,

das "dd" Kommando kopiert 100 MB Daten durch die Gegend. "time" spuckt aus, wie lange das dauert. Der Rest ist Mathematik.

 

[Darkyputz]

oh danke...die 100 MB groesse war mir nicht bewusst...
bin ich ja mit --> ~10MB/s garnicht so uebel...
vor allem weil die platte bei dem test noch ausm spindown erwachen musste...

 

[Fox.Mulder]

Beim mir wird beim Automount der Festplatte ein Write Through Cache aktiviert. Kann man die Aktivierung dieses Datenträgercaches unterbinden? Wenn ja, wie?

Viele Grüße.
M.

 

[Darkyputz]

du koenntest mal schauen ob das fuer dein nicht bekannt gegebenes filesystem eingetragen iss in der /etc/hotplug/run_mount

	case $FSTYPE in
	vfat)
		mount -t vfat -o $READMODE,uid=$FTPUID,gid=$FTPGID,fmask=0000,dmask=0000 $DEVNODE $MNTPATH
		;;
	ext2)
		mount -t ext2 $DEVNODE $MNTPATH -o noatime,nodiratime,rw,async
		;;
	ext3)
		mount -t ext3 $DEVNODE $MNTPATH -o noatime,nodiratime,rw,async
		;;
	ntfs)
		/usr/bin/ntfs-3g $DEVNODE $MNTPATH -o $READMODE -o force -o locale=de_DE.ISO-8859-1
		;;
	reiserfs)
		mount -t reiserfs $DEVNODE $MNTPATH -o noatime,nodiratime,rw,async

wenn da fuer dein filesystem das drin steht nimm es vor dem naechsten freetzen raus...that's it...

 

[Fox.Mulder]

War natürlich EXT2_FS gemeint. Habe mal manuell gemountet und async weggelassen. Hatte jedoch keinen Einfluß auf die Performance.
Mit dem Image 54.04.99-10771-freetz-2342M erreiche ich einen deutlich höheren Datendurchsatz.

Mit dem Cache war folgende Ausgabe gemeint (67er Firmware):

sda: assuming drive cache: write through
sda1 sda2

Also offensichtlich ein Drive Cache. Ob dieser Cache allerdings beim manuellen Mounten, nachdem die Partition umounted wurde, nicht aktiv ist, kann ich nicht sagen.

Viele Grüße.
M.

 

[Fox.Mulder]

Um das Performance Problem näher einzugrenzen habe ich die Freetz SVN Version 2838 für die FW Release 54.04.59 einmal mit aktivierter ext2 Option kompiliert. Wenn diese Option nicht aktiviert ist, wird das von AVM mitgelieferte ext2 Kernel Modul verwendet und bei Aktivierung der Option wird das ext2 Modul durch ein selbst kompiliertes Freetz Modul ersetzt.

Ergebnis:
Original ext2 Kernel Modul: keine Performance Einbußen
Freetz ext2 Kernel Modul: Performance Einbußen von ca. 20-25% vorhanden

Viele Grüße.
M.