PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Frage des Datendurchsatzes



Seiten : [1] 2

TuxServer
28.03.08, 19:57
Hallo zusammen

gibt es eine Tool oder eine Möglichkeit den Datendurchsatz einer Netzwerkkarte zu messen?
Habe hier einen ThinClient (neoware 3000) und dieser ist kommt mir unheimlich langsam vor was den OnBoard NIc (Realtek 8139c) angeht.
Wenn ich da z.b. 1GB auf meinen anderen Rechner kopieren will dann dauert das schonmal bis zu 30Minuten.
Der NIC soll 100Mbit machen, aber mir kommt das schon noch langsamer als 10Mbit vor.

gruß
Martin

Stephanw
28.03.08, 20:12
Moin!

iftop

Gruß Stephan

TuxServer
28.03.08, 20:30
werde mir das mal genauer anschauen. danke dir erstmal
produziert das auch selber Netzlast oder zeigt es nur die momentane Netzlast?

bei einem ersten test jetzt wurden mir sage und schreibe 1.03Mb angezeigt.

TuxServer
28.03.08, 20:44
Also ich habe jetzt nochmal ein wenig länger das Tool laufen lassen und bin erschüttert. Ich habe auf dem Thinclient noch torrent laufen was gerade am Downloaden ist. Wenn ich versuche von meinem Client aus was auf die kiste zu spielen dann schaffe ich sage und schreibe 15Mb wobei aber der up und download von torrent fast auf null zurückgeht. Wenn ich von der Kiste was auf meinen Client kopieren will das passiert mit dem torrent up/download das selbe und ich schaffe irgendwie nicht mehr als 8Mb.
Irgendwie kann das doch nicht normal sein.

stefan.becker
28.03.08, 20:49
MB oder MBit?

TuxServer
28.03.08, 20:55
Sorry das ich das abgekürzt habe....ich meinte natürlich Mbit :)

stefan.becker
28.03.08, 20:56
Sorry, keine Idee. Ich dachte, du meintest zuletzt MB. Und dann wären die Raten bei 100 MBit ja in Ordnung.

TuxServer
28.03.08, 21:03
ne also ich meinte bei allen angaben immer Mbit....

und das kommt mir sehr wenig vor für eine 100Mbit NIC.
Habe gerade noch gesehen das der TorrentClient eine PC-Auslastung von bis zu 80% schafft, aber leider ändert dich der Datensatz auch nicht wenn ich den TorrentClient beende und diese PC-Last dann weg ist.

403
28.03.08, 21:08
laeuft der torrent client schon mit freiwilliger Bandbreiten Begrenzung wie z.B. bei rtorrent?

TuxServer
28.03.08, 21:16
also ich nutze hier bittornado und der ist so eingestellt das bein download keine begrenzung und beim upload habe ich eine grenze von 35kbit eingestellt.

TuxServer
28.03.08, 21:37
Habe jetzt nochmal den bittornado ausgestellt und festgestellt wenn ich dann kopiere Samba bis zu 99,9% CPU-Last erzeugt....dann sollte es ja eigentlich kein wunder sein das der Transfer so zäh ist.
Also dem System steht zwar nur 128MB RAM und der Geode 300Mhz zur verfügung, aber beim simplen Kopieren fast 100% CPU auslastung ist doch auch nicht wirklich richtig oder?
Die Frage ist natürlich ob mich da eine NIC weiterbringen würde die z.b. einen Intel Chip benutzt...diese sollen ja nicht so CPU-Lastig sein.

bla!zilla
29.03.08, 11:41
Bei Realtek Chipsätzen ist es bekannt, dass sie wenig sparsam mit CPU Ressourcen umgehene. Schau doch mal bitte mittels vmstat nach, was das System so macht. Eine Anleitung zu vmstat findest du hier (http://www.blazilla.de/index.php?/archives/284-vmstat-Mini-Anleitung.html).

TuxServer
29.03.08, 13:34
Habe jetzt mal vmstat getestet wärend ich vom Client auf den Thinclient was kopiert habe.
Die ausgabe sa so aus:

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 52680 19968 1656 6584 5 5 749 122 453 76 43 18 33 6
0 0 52680 19968 1656 6584 0 0 0 0 252 22 1 0 99 0
0 0 52680 19968 1656 6584 0 0 0 0 251 22 2 0 98 0
0 0 52680 19968 1656 6584 0 0 0 8 252 30 1 0 99 0
0 0 52680 19968 1656 6584 0 0 0 0 251 24 1 0 99 0
0 0 52680 19944 1680 6584 0 0 0 57 258 37 1 2 97 0
0 0 52680 19944 1680 6584 0 0 0 0 264 45 2 1 97 0
0 0 52680 19944 1680 6584 0 0 0 0 253 24 0 0 100 0
0 0 52680 19944 1680 6584 0 0 0 0 251 22 2 0 98 0
0 0 52680 19944 1680 6584 0 0 0 0 251 23 1 0 99 0
0 0 52680 19944 1688 6584 0 0 0 20 254 23 2 0 98 0
0 0 52680 19800 1704 6692 0 0 106 3 285 81 2 4 91 3
1 0 52680 19800 1704 6692 0 0 0 0 257 32 2 1 97 0
3 0 52680 17876 1704 8444 32 0 60 0 741 190 5 82 2 11
1 0 52680 15908 1704 10384 0 0 0 0 731 191 6 93 1 0
2 1 52680 13652 1704 12364 0 0 0 5644 725 170 8 92 0 0
2 0 52680 12236 1720 13984 0 0 0 49 629 91 9 91 0 0
1 0 52680 10304 1724 15908 0 0 0 0 773 192 6 92 2 0
1 0 52680 8300 1724 17824 0 0 0 4 711 167 8 91 0 1
2 0 52680 6284 1728 19804 0 0 0 0 726 185 5 94 1 0
1 0 52680 4268 1728 21772 0 0 0 0 724 197 7 92 1 0
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
2 0 52680 3224 1736 22916 0 0 0 9580 507 73 4 96 0 0
2 1 52680 1732 1692 24384 0 0 0 0 743 159 8 91 1 0
1 2 52680 1996 564 25168 0 0 0 4 690 204 7 93 0 0
2 1 52680 2004 568 25128 0 0 0 0 758 177 7 92 0 1
1 1 52680 2084 568 25032 0 0 0 0 856 161 9 91 0 0
2 0 52680 1904 580 25344 0 0 0 9340 485 147 5 94 0 1
1 0 52680 1956 580 25276 0 0 0 0 701 240 7 92 0 1
2 1 52680 2316 584 24836 0 0 1 4 682 216 6 93 0 1
2 0 52680 2172 568 24920 0 0 0 384 735 180 7 93 0 0
1 0 52680 2004 572 25056 0 0 4 0 684 189 8 83 0 10
2 0 52680 1988 584 25164 0 0 0 8664 507 118 5 94 0 1
1 1 52680 2144 576 25108 0 0 4 0 795 132 8 91 0 1
2 0 52680 2372 580 24836 0 0 4 66 707 221 7 86 1 6
2 1 52680 2060 580 25100 0 0 4 0 705 205 7 92 0 1
2 0 52680 2128 576 24984 0 0 0 0 650 211 5 93 1 1
4 0 52680 2256 584 24948 0 0 0 9596 743 130 6 93 0 1
2 1 52680 1968 576 25268 0 0 0 0 723 183 7 93 0 0
2 1 52680 2184 576 25024 0 0 4 21 706 214 6 88 1 6
2 0 52680 2260 564 24872 0 0 0 0 702 118 10 90 0 0
1 1 52680 1904 568 25192 0 0 0 0 840 194 7 93 0 0
4 0 52680 2032 576 25172 0 0 0 8868 583 152 6 92 0 2
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
1 1 52680 2156 556 25136 0 0 0 0 747 182 6 94 0 0
2 1 52680 2324 544 24888 0 0 0 16 759 167 6 94 0 0
1 0 52680 1952 544 25268 0 0 0 0 760 136 4 95 0 1
2 1 52680 2048 536 25160 0 0 0 0 717 210 7 93 0 0
3 0 52680 2540 544 24704 0 0 0 9584 709 226 6 94 0 1
2 1 52680 2536 508 24700 0 0 0 4 733 163 8 92 0 0
1 0 52680 2064 508 25276 0 0 0 4 741 239 8 90 1 1

Habe dazu "vmstat 1" benutzt.
Ich kann da bisher aber noch nicht wirklich sehr viel rauslesen.

bla!zilla
29.03.08, 14:16
Also deine Maschine hat defintiv ein Problem mit der CPU Last. IOWait kann man ausschließen, da die Wert maximal bei 6 bis 11% lag. Viel interessanter ist das immer wieder ein Prozess in den Status D verfällt, also uninterruptible sleep. Bitte mal per ps alx | grep [D] danach suchen. Kopier irgendwas großes auf die Kiste, oder von der Kiste, und führe den Befehl ein paar Mal aus. Dann solltest du sehen welcher Prozess das ist.

TuxServer
29.03.08, 14:40
Also ich habe jetzt beim kopieren einer großen Datei auf die Kiste einige male den Befehlt ausgeführt und es wiederholen sich immer nur folgende Ausgaben

debian:~# ps alx | grep [D]
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
1 0 74 5 15 0 0 0 pdflus D ? 1:01 [pdflush]
1 0 75 5 10 -5 0 0 kswapd D< ? 1:19 [kswapd0]
5 0 2056 1 15 0 5880 728 - Ss ? 0:01 /usr/sbin/nmbd -D
5 0 2058 1 15 0 8952 1216 429496 Ss ? 0:00 /usr/sbin/smbd -D
1 0 2067 2058 19 0 8952 64 pause S ? 0:00 /usr/sbin/smbd -D
5 1000 5902 2058 16 0 9348 2684 - R ? 0:14 /usr/sbin/smbd -D
0 0 5908 5896 18 0 2020 724 - R+ pts/1 0:00 grep [D]
debian:~# ps alx | grep [D]
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
5 0 2056 1 15 0 5880 728 - Ss ? 0:01 /usr/sbin/nmbd -D
5 0 2058 1 15 0 8952 1216 429496 Ss ? 0:00 /usr/sbin/smbd -D
1 0 2067 2058 19 0 8952 64 pause S ? 0:00 /usr/sbin/smbd -D
5 1000 5902 2058 15 0 9348 2684 - S ? 0:18 /usr/sbin/smbd -D
0 0 5910 5896 18 0 300 104 - R+ pts/1 0:00 grep [D]


Kannst Du da war rauslesen?
Bin leider noch nicht so der Linux-Profi :-)

Habe jetzt auch mal den Befehl "ps faxu" benutzt und mir die Ausgabe da angesehen.
Was bedeutet denn da die Angabe "%CPU"?
Also wenn ich nämlich da schaue dann hat Samba eine CPU-Last von 25% und phyton (was ich für bittornado brauche) 55% CPU-Last.
Aber diese angaben sind wohlgemerkt im Leerlauf, also weder Samba verschiebt oder kopiert Daten und Bittornado ist nur geöffnet und hat nichts zum down oder uploaden, also keine Torrent-Datei ist geladen.
Wenn ich aber dann in "top" schaue werden mir die Prozesse mit 0.0 CPU-Last angezeigt.

bla!zilla
29.03.08, 16:50
Interessant sind diese beiden Zeilen:



1 0 74 5 15 0 0 0 pdflus D ? 1:01 [pdflush]
1 0 75 5 10 -5 0 0 kswapd D< ? 1:19 [kswapd0]


Was für eine Platte hängt darunter? Wieviel RAM? Wie groß ist die Swappartition? Was ist per NFS eingebunden??

Beende mal bitte bittornado und teste erneut.

TuxServer
29.03.08, 21:34
Also ich habe jetzt nochmal ein wenig rumprobiert.
Habe übrigens gesehen das ich doch nur 96MB RAM habe. Der eine 128MB SD-RAM Riegel wird nur zu hälfte erkannt und dann ist da noch ein 32MB S0-SDRAM verbaut.
Für mehr Speicher habe ich leider nicht das passende hier, das Gerät ist da sehr wählerisch.
Als HD wird eine 100GB 2,5" Samsung verwendet. Hier mal die ausgaben von df und free
free:

debian:~# free
total used free shared buffers cached
Mem: 92032 89944 2088 0 584 75048
-/+ buffers/cache: 14312 77720
Swap: 273064 64 273000



df:

debian:~# df
Dateisystem 1K-Blöcke Benutzt Verfügbar Ben% Eingehängt auf
/dev/hda1 264445 75336 175456 31% /
tmpfs 46016 0 46016 0% /lib/init/rw
udev 10240 64 10176 1% /dev
tmpfs 46016 0 46016 0% /dev/shm
/dev/hda9 87531360 4443464 78641508 6% /home
/dev/hda8 381138 10289 351171 3% /tmp
/dev/hda5 4806904 289432 4273288 7% /usr
/dev/hda6 2885780 186364 2552828 7% /var


Diese Angaben sind jetzt gemacht bei einem Kopiervorgang.
Der RAM scheind ja fast komplett benutzt zu sein.

Klar 96MB sind nicht wirklich viel, aber sollte das nicht ausreichen und ein paar Daten im LAN zu kopieren?
Bittornado ist übrigens ausgeschaltet.

Die Ausgabe von "df" kommt mir komisch vor.
Was ist denn da noch tmpfs, udev und tmpfs?
Habe hier mal nochmal die mtab:

/dev/hda1 / ext3 rw,errors=remount-ro 0 0
tmpfs /lib/init/rw tmpfs rw,nosuid,mode=0755 0 0
proc /proc proc rw,noexec,nosuid,nodev 0 0
sysfs /sys sysfs rw,noexec,nosuid,nodev 0 0
procbususb /proc/bus/usb usbfs rw 0 0
udev /dev tmpfs rw,mode=0755 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
devpts /dev/pts devpts rw,noexec,nosuid,gid=5,mode=620 0 0
/dev/hda9 /home ext3 rw 0 0
/dev/hda8 /tmp ext3 rw 0 0
/dev/hda5 /usr ext3 rw 0 0
/dev/hda6 /var ext3 rw 0 0


Ist das alles so richtig? Habe sowas von anderen Systemen eher so in erinnerung wie hier hda9, hda8, hda5 und hda6 eingebunden sind.

Aqualung
29.03.08, 21:40
Klar 96MB sind nicht wirklich viel,

Vielleicht etwas knapp für samba. Speicherausbau scheint "conditio sine qua non" (Unbedingt nötig). Welchen Chipsatz hat die Box?

BTW: ich finde
xnetload
ganz nett zum Bandbreitentracking.
http://www.xs4all.nl/~rsmith/software/xnetload-1.11.3.tar.gz

Gruß Aqualung

TuxServer
29.03.08, 21:50
Also das das Samba-Dienste sind weiß ich und das ist auch alles richtig so.
Die Debian Installation ist erst 4 Tage alt und Samba wird auch be jedem Systemstart neu mitgestartet. Die Kiste läuft ebend nicht 24/7 sondern nur dann wenn sie gebraucht wird.
Bandbreitentracking ist sicherlich eine nette sache, aber mir sowas nichts denn ich erreiche wie oben schonmal geschrieben nur eine bandbreite von 12-15Mbit bei einem 100Mbit LAN.

Aqualung
30.03.08, 00:03
Wie siehts mit der NIC aus? Läuft die in full-duplex?

mit

dmesg | grep eth0
nachsehen. Manchmal hilft auch ein besseres Kabel.

Gruß Aqualung

TuxServer
30.03.08, 00:16
debian:~# dmesg | grep eth0
eth0: RealTek RTL8139 at 0xe000, 00:e0:c5:bc:3c:e6, IRQ 11
eth0: Identified 8139 chip type 'RTL-8139C'
eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
eth0: no IPv6 routers present


Ja läuft alles in full-duplex und Kabel habe ich auch schon ausprobiert aber leider null änderung.

TuxServer
30.03.08, 16:03
Hat keiner mehr eine Idee warum die Datei mtab so merkwürdig aussieht?

bla!zilla
30.03.08, 16:11
Öhmmm... von den 96 MB sind rund 77 MB frei, bzw. verfügbar. Die werden als Diskcache genutzt. Und stehen damit im Prinzip zur Verfügung.

Läuft die Platte im DMA Modus? Bitte mal die Ausgabe von hdparm /dev/hda posten.

TuxServer
30.03.08, 17:14
Hier mal die Ausgabe.

debian:~# hdparm /dev/hda

/dev/hda:
multcount = 0 (off)
IO_support = 0 (default 16-bit)
unmaskirq = 0 (off)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 16383/255/63, sectors = 195371568, start = 0



Ist denn mit der mtab alles ok oder sollte da was geändert werden?
Weiß ja nicht was die ganzen zusätzlichen Optionen noch machen.

bla!zilla
30.03.08, 17:24
Was hast du denn mit der mtab??? Die /etc/fstab ist viel interessanter. Die mtab wird dynamisch generiert.

Hast du jetzt mal den Bittorrent Client beendet und erneut getestet?

TuxServer
30.03.08, 17:34
Also die fstab sieht folgendermaßen aus.

# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
/dev/hda1 / ext3 defaults,errors=remount-ro 0 1
/dev/hda9 /home ext3 defaults 0 2
/dev/hda8 /tmp ext3 defaults 0 2
/dev/hda5 /usr ext3 defaults 0 2
/dev/hda6 /var ext3 defaults 0 2
/dev/hda7 none swap sw 0 0
/dev/hdb /media/cdrom0 udf,iso9660 user,noauto 0 0


Ja ich habe die ganzen Tests ausprobiert mit laufendem Bittoreentclient und beendeten Bittorrentclient, aber da ist nichts schneller oder langsamer geworden. Das einzigste war ebend nur das bei laufendem Client die up/downloadrate vom Bittrorrentclient fast gegen 0kb gegangen ist und nach fertigem kopiervorgang erst wieder gestiegen ist.
Aber an der eigentlichen Geschwindigkeit oder des Datendurchsatzes hat sich nichts getan.
Es ist mir wärend eines Kopiervorgangs auch so ziemlich unmöglich mich lokal oder über ssh an dem Rechner anzumelden. Er scheind wirklich total ausgelastet zu sein mit dem Kopieren.

bla!zilla
30.03.08, 17:42
Was halt extrem auffällt sind die Kernelprozesse (pdflush und kswapd0) die auf IO warten, und die hohe CPU Zeitnutzung durch den Kernel (hohe SY Werte bei vmstat). Das passt auch zusammen, die Kernelprozesse erklären den hohen Nutzungsanteil an CPU Zeit. Irgendwas an deinem System ist grütze. Ich tippe auf irgendwas in Richtung Platte. Hast du die Möglichkeit mal mittels dd ein paar Blöcke zu schreiben und dabei mittels vmstat zu testen??



time dd if=/dev/null of=/home/test.dat bs=1M count=1024


Damit legst du eine 1 GB große Datei an. Mal sehen was die Platte so hergibt.

TuxServer
30.03.08, 18:29
So habe das mal ausprobiert und die einzigste ausgabe die ich bekomme ist

debian:/home# time dd if=/dev/null of=/home/test.dat bs=1M count=1024
0+0 Datensätze ein
0+0 Datensätze aus
0 Bytes (0 B) kopiert, 0,000326811 Sekunden, 0,0 kB/s

real 0m0.035s
user 0m0.016s
sys 0m0.016s


Die Datei wird auch erstellt in /home/ aber sie ist ebend 0Byte groß.

Aqualung
30.03.08, 19:24
IMHO meinte bla!zilla:


time dd if=/dev/zero of=/home/test.dat bs=1M count=1024

Gruß Aqualung

TuxServer
30.03.08, 19:33
ahhhh naja dann konnte es ja nichts werden :-)
jetzt hat es aber geklappt und es sieht nicht wirklich gut aus.

free:

debian:~# free
total used free shared buffers cached
Mem: 92032 90140 1892 0 420 78664
-/+ buffers/cache: 11056 80976
Swap: 273064 4892 268172


ps alx | grep [D]:

debian:~# ps alx | grep [D]
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
1 0 75 5 10 -5 0 0 blk_co D< ? 1:18 [kswapd0]
5 0 18535 1 15 0 6312 912 - Ss ? 0:00 /usr/sbin/nmbd -D
5 0 18537 1 18 0 9648 1316 429496 Ss ? 0:00 /usr/sbin/smbd -D
1 0 18542 18537 18 0 9380 232 pause S ? 0:00 /usr/sbin/smbd -D
0 0 21223 21166 18 0 2020 720 - R+ pts/3 0:00 grep [D]
debian:~# ps alx | grep [D]
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
1 0 74 5 16 0 0 0 blk_co D ? 0:45 [pdflush]
5 0 18535 1 15 0 6312 912 - Ss ? 0:00 /usr/sbin/nmbd -D
5 0 18537 1 18 0 9648 1316 429496 Ss ? 0:00 /usr/sbin/smbd -D
1 0 18542 18537 18 0 9380 232 pause S ? 0:00 /usr/sbin/smbd -D
0 0 21225 21166 18 0 2020 720 - R+ pts/3 0:00 grep [D]


vmstat 1:

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
2 1 4892 1532 368 79156 0 0 0 0 253 29 0 100 0 0
1 1 4892 1808 364 78788 0 0 0 6628 306 107 0 100 0 0
2 0 4892 2584 348 77936 0 0 0 5152 310 107 0 100 0 0
2 0 4892 2400 348 78036 0 0 0 5992 313 106 0 100 0 0
2 1 4892 2696 352 77924 0 0 0 15212 455 136 0 100 0 0
1 1 4892 2028 364 78676 0 0 0 0 262 35 0 100 0 0
2 0 4892 2536 360 78076 0 0 0 5904 292 79 0 100 0 0
2 0 4892 2320 356 78208 0 0 0 6160 319 109 1 99 0 0
2 0 4892 2380 360 78060 0 0 0 5936 324 117 1 99 0 0
3 2 4892 2416 372 78280 0 0 0 14576 436 123 1 99 0 0
1 1 4892 2260 372 78444 0 0 0 0 258 37 0 100 0 0
2 0 4892 2280 360 78328 0 0 0 5308 296 64 0 100 0 0
1 1 4892 1564 348 78984 0 0 0 6328 322 117 0 100 0 0
2 0 4892 2412 348 78048 0 0 0 5600 313 109 1 99 0 0
1 0 4892 2260 352 78328 0 0 0 15280 451 162 1 99 0 0
1 1 4892 1724 372 78980 0 0 0 0 256 33 0 100 0 0
2 0 4892 2560 376 78036 0 0 0 4436 273 48 0 100 0 0
0 2 4892 2160 380 78368 0 0 8 7896 348 150 0 99 0 1
0 0 4892 2564 424 77948 0 0 375 180 332 54 1 6 68 25
0 1 4892 2648 424 77948 0 0 0 8152 273 6 0 7 93 0
0 0 4892 2900 432 77948 0 0 0 52 245 11 0 14 73 12


time dd if=/dev/zero of=/home/test.dat bs=1M count=1024:

debian:/home# time dd if=/dev/zero of=/home/test.dat bs=1M count=1024
1024+0 Datensätze ein
1024+0 Datensätze aus
1073741824 Bytes (1,1 GB) kopiert, 236,103 Sekunden, 4,5 MB/s

real 3m56.612s
user 0m0.048s
sys 1m55.171s