mich nerven seit der Umstellung meines Home LAN auf 1000 MBit Aussetzer von mehreren Sekunden. Wie sich das auf größere Dateitransfers auswirkt ist wohl klar ...
Habe ein Testszenario aufgebaut und das Ganze auf HD Last zurückgeführt:
"Client":
# nc -l -p 21234 > /dev/null
"Server":
# cat /dev/zero | nc [client-ip] 21234
Bringt erstmal ~250 MBit/s auf die Leitung. Läuft soweit stundenlang, keine Probleme. Ist zwar kein Gigabit, aber da bin ich mir auch nicht sicher, ob nc und cat das praktisch überhaupt hinbekommen.
Jetzt das Interessante:
"Server":
# cat /dev/zero > zeros.tmp
a) Mache ich das auf den per IDE oder USB2 angeschlossenen Festplatten, setzt die Netzwerkkarte prompt aus und meldet sich nur wieder, weil ich ein kleines Skript laufen lasse, das bei Unerreichbarkeit sämtlicher Netzteilnehmer "/etc/init.d/networking restart" durchzieht. Hin und wieder zur gleichen Zeit im message log: "NETDEV WATCHDOG: eth_lan: transmit timed out". Die Karte nennt sich eth_lan, ist umbenannte eth2 oder eth1 - Firewire hat mein Leben an der Stelle ein wenig versüßt.
b) Mache ich das auf einer per PCI SATA-Controller angeschlossenen Platte, gibt es keine Aussetzer.
Die Festplatten machen alle ~20-30 MiB/s (aber nur je eine aktiv), die per SATA und USB2 angeschlossenen sind sogar identische Modelle und machen nur via USB2 Probleme! Auf IDE konnte ich unmaskirq per hdparm schalten, bringt aber auch nix.
Meine vorläufige Lösung: Karte auf 100 MBit betreiben. Dann gibt es keine Aussetzer. Per ethtool runtergedreht. Langfristig werde ich ohnehin komplett auf SATA umziehen, erledigt sich früher oder später also von selbst. Trotzdem etwas enttäuscht. Läuft da der PCI Bus voll? Oder ist irgendwas anderes überlastet?
Software:
Debian Unstable, Debian Kernel 2.6.22-2-686 SMP
Hardware:
Code: Alles auswählen
# lspci:
00:00.0 Host bridge: VIA Technologies, Inc. VT8377 [KT400/KT600 AGP] Host Bridge (rev 80)
00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge
00:08.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 46)
00:09.0 Ethernet controller: D-Link System Inc DGE-528T Gigabit Ethernet Adapter (rev 10)
00:0b.0 RAID bus controller: Silicon Image, Inc. SiI 3512 [SATALink/SATARaid] Serial ATA Controller (rev 01)
00:0e.0 Ethernet controller: VIA Technologies, Inc. VT6105 [Rhine-III] (rev 8b)
00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80)
00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80)
00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80)
00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82)
00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge
00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 50)
01:00.0 VGA compatible controller: nVidia Corporation NV34 [GeForce FX 5200LE] (rev a1)
Die D-Link Karte basiert auf handelsüblichem r8169, entsprechend ist das Modul geladen.
Code: Alles auswählen
# cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 8
model name : AMD Duron(tm) processor
stepping : 1
cpu MHz : 1599.784
cache size : 64 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow up ts
bogomips : 3202.63
clflush size : 32
Ich denke mal das System ist einfach überfordert, aber dass SATA so viel besser läuft hätte ich nicht gedacht ...