Gigabit-netz mit dlink 530T lahmt ~10mb/s

[mark.j]

abend zusammen.

ich fass mich kurz:
- debian-server (p3 450mhz) mit dlink-530, kernel 2.6.8.1 und sk98-treiber (aus kernel)
- winXP-client (>2ghz) auch dlink-530

tcpspray winXP -> debian sagt:

Transmitted 10100000 bytes in 0.460 seconds (21441.916 kbytes/s)

wobei das ja auch schon ziemlich langsam ist (?)

samba und ftp performance sind ziemlich ähnlich (auch in beide richtungen), bei ca. 8-12mb/s

sind die karten sooo schlecht?
oder
sind 450mhz sooo langsam?

weiß nicht mehr weiter

gruß mark

[erni]

du könntest mal einen größeren transfer starten und Dir dann unter top die Prozessorauslastung ansehen...

[diedl2003]

Hi,

ich habe zwei Realtek 8169. Zwischen zwei Debian Rechnern (1und 2 Ghz) komme ich bei ftp
auf ca 25 Mb/s, in eine richtung etwas langsamer. Bei NFS komme ich auch nur auf ca 12 Mb/s. Die Hd's sind aber in beiden Rechnern wesentlich schneller,daran kann es wohl nicht liegen. Ich denke es sind die billig Karten und vielleicht auch der Treiber, der überhaupt erst seit 2.4.27 so richtig läuft.

[mark.j]

gut, habs jetzt mal mit top versucht, während 2gb übers netz gegangen sind.

übrigens: mittlerweile ist kernel 2.9.1 drauf, hatte gehofft dass der neue sk98 treiber dort besser laufen wird.

FTP: win -> debian , bei ~8mb/s
andere richtung auch

TOP sagt, der ftp-dienst braucht ca. 50-80% , also ist ja noch ein wenig spielraum da.

habe mich in der dmesg gerade noch davon überzeugt, dass auch wirklich die autonegotiation mit 1000 mbit geklappt hat...

an den festplatten kann es auch nicht liegen, sind beide aktuelle modelle.
samsung 120gb und samsung 160gb.

[mark.j]

habe hier noch einiges versucht, denke mir aber einfach mal, dass die langsame performance von der 450mhz CPU kommt.
werde es erstmal mit nem neuem cat5e kabel probieren und wenn das auch nix bringt...
naja, wollte mir sowieso nen neuen rechner gönnen und weihnachten steht ja bald vor der tür

gruß

mark

[diedl2003]

Hi,

Du könntest es noch mal in der smb.conf mit einem "socket options = TCP_NODELAY" probieren,vielleicht nutzt es was. Um die Hd's auszuschliessen, kannst Du mit hdparm die transfer rate nochmal prüfen.
Gruss und viel Erfolg

[mark.j]

habe es noch mit netio probiert.
auf der debian-maschine server und client ausgeführt, ergebnis:

server:/home/mark# ./linux-i386 -t server

NETIO - Network Throughput Benchmark, Version 1.23
(C) 1997-2003 Kai Uwe Rommel

TCP connection established.
Packet size 1k bytes: 24729 KByte/s Tx, 35526 KByte/s Rx.
Packet size 2k bytes: 35460 KByte/s Tx, 40664 KByte/s Rx.
Packet size 4k bytes: 39152 KByte/s Tx, 43103 KByte/s Rx.
Packet size 8k bytes: 40890 KByte/s Tx, 40746 KByte/s Rx.
Packet size 16k bytes: 48421 KByte/s Tx, 40033 KByte/s Rx.
Packet size 32k bytes: 48995 KByte/s Tx, 41973 KByte/s Rx.
Done.

bei der messung müsste netio ja auch gleich von den platten lesen und drauf rumschreiben, oder?

wenn nicht, wie kann mich mit hdparm die performance testen? habe da nur parameter zur abfrage von bestimmten einstellungen gefunden...

socket options = TCP_NODELAY

war übrigens schon drin...

auf debian server und winXP client:

d:\Downloads>win32-i386.exe -t server

NETIO - Network Throughput Benchmark, Version 1.23
(C) 1997-2003 Kai Uwe Rommel

TCP connection established.
Packet size 1k bytes: 15478 KByte/s Tx, 10370 KByte/s Rx.
Packet size 2k bytes: 17670 KByte/s Tx, 12375 KByte/s Rx.
Packet size 4k bytes: 18794 KByte/s Tx, 13920 KByte/s Rx.
Packet size 8k bytes: 19905 KByte/s Tx, 14497 KByte/s Rx.
Packet size 16k bytes: 20641 KByte/s Tx, 15137 KByte/s Rx.
Packet size 32k bytes: 21903 KByte/s Tx, 16263 KByte/s Rx.
Done.

[diedl2003]

Die Lesegeschwindigkeit ermittelt man mit

Code: Alles auswählen

 hdparm -t /dev/hda

habe es noch mit netio probiert.
auf der debian-maschine server und client ausgeführt, ergebnis

Hast Du da nicht das loopback interface gemessen?

bei der messung müsste netio ja auch gleich von den platten lesen und drauf rumschreiben, oder?

Ich kenne netio nicht und weiss nicht was da passiert

[mark.j]

danke dir.

server:~# hdparm -t /dev/hda

/dev/hda:
Timing buffered disk reads: 40 MB in 3.14 seconds = 12.73 MB/sec

wurde wohl doch nur das loopback device gemessen

nur was mach ich jetzt... wie tunt man die leseperformance der platte?

server:~# hdparm -c -d /dev/hda

/dev/hda:
IO_support = 1 (32-bit)
using_dma = 1 (on)

die 2 sachen sind wenigstens schon gesetzt, hab ich aus anderen threads hier im forum rausgelesen

[diedl2003]

Code: Alles auswählen

hdparm -I /dev/hda

zeigt dir mehr Details. Benutzt du ein 80 poliges Kabel? Und was zeigt denn dein bios bzw. gibts da noch was einzustellen?

nur was mach ich jetzt... wie tunt man die leseperformance der platte?

Ich glaube mit dem Parameter -X setzt man den (u)dma mode, laut help aber gefährlich

[mark.j]

server:~# hdparm -I /dev/hda

/dev/hda:

ATA device, with non-removable media
Model Number: SAMSUNG SP1614N
Serial Number: S016J10X328186
Firmware Revision: TM100-24
Standards:
Supported: 7 6 5 4
Likely used: 7
Configuration:
Logical max current
cylinders 16383 65535
heads 16 1
sectors/track 63 63
--
CHS current addressable sectors: 4128705
LBA user addressable sectors: 268435455
LBA48 user addressable sectors: 312581808
device size with M = 1024*1024: 152627 MBytes
device size with M = 1000*1000: 160041 MBytes (160 GB)
Capabilities:
LBA, IORDY(can be disabled)
Queue depth: 1
Standby timer values: spec'd by Standard, no device specific minimum
R/W multiple sector transfer: Max = 16 Current = 16
Recommended acoustic management value: 254, current value: 0
DMA: mdma0 mdma1 mdma2 udma0 udma1 *udma2 udma3 udma4 udma5
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=240ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
* READ BUFFER cmd
* WRITE BUFFER cmd
* Host Protected Area feature set
* Look-ahead
* Write cache
* Power Management feature set
Security Mode feature set
* SMART feature set
* FLUSH CACHE EXT command
* Mandatory FLUSH CACHE command
* Device Configuration Overlay feature set
* 48-bit Address feature set
Automatic Acoustic Management feature set
SET MAX security extension
* DOWNLOAD MICROCODE cmd
* SMART self-test
* SMART error logging
Security:
Master password revision code = 65534
supported
not enabled
not locked
not frozen
not expired: security count
supported: enhanced erase
56min for SECURITY ERASE UNIT. 56min for ENHANCED SECURITY ERASE UNIT.
HW reset results:
CBLID- above Vih
Device num = 0 determined by CSEL
Checksum: correct

ähm... also gesetzt ist der UDMA2 mode, sonst seh ich da nix böses drin.

kabel hab ich grad ein neues eingesetzt, 40-poliges aber.

Ich glaube mit dem Parameter -X setzt man den (u)dma mode, laut help aber gefährlich Rolling Eyes

muss ich das überhaupt? UDMA2 ist ja gesetzt, und müsste ausreichen. (?)
das BIOS geh ich mir jetzt mal anschauen. da muss ich extra meinen monitor zum schrank schleppen wo die debian-kiste ihren dienst macht


bis gleich...

[diedl2003]

Was mir auffällt ist

Device num = 0 determined by CSEL

Sieht danach aus, als ob ein jumper nicht gesetzt ist. Ich weiss aber nicht, ob das irgendwas an der performance ändern würde.Auch was ein anderes Kabel ändern würde weiss ich nicht. udma2 ist mit 33Mb/s angegeben, die Samsung bringt bestimmt an die 60Mb/s, ein bisschen scheller als die 12Mb/s sollte es also schon sein... Ansonsten musst du hier mal auf ein paar Experten Tips warten,ich weiss da auch nicht so gut bescheid..

[mark.j]

wegen dem jumper: cable select soll, soweit ich gehört habe, nur vorteile bringen (komfort halt) aber keine nachteile. daher setze ich diesen jumper nie.

war ziemlich problematisch die platte ins system einzubinden, weil das board nur max 128gb erkennt. erst hatte ich einne partition mit den vollen 160gb, da trat dann aber datenverlust auf.

da habe ich sie auf 128gb verkleinet und seitdem gibt es keine probleme bezüglich des datenverlustes.

im bios wird sie mit stolzen 8mb erkannt

server:/usr/src/linux# hdparm -tT /dev/hda

/dev/hda:
Timing cached reads: 444 MB in 2.01 seconds = 220.82 MB/sec
Timing buffered disk reads: 40 MB in 3.14 seconds = 12.74 MB/sec

hier nochmal mit der cache anzeige

habe übrigens noch

Limiting direct PCI/PCI transfers

in der dmesg gefunden, ist das schlimm?

außerdem wurde hier im forum auch erwähnt, man soll nicht den generic IDE driver benutzen? weil:

Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2

steht auch in der dmesg