GBit LAN: CPU-limitiert?

@MoZ, es kann schon sein, dass der Rechner zu langsam ist. Wenn dem so ist, dann muss ich das natürlich hinnehmen. Ich habe mich trotzdem gefragt, warum man für diesen Zweck einen schnelleren Prozessor bräuchte. Bin halt neugierig, und wenn es Einstellungen gibt, die das beschleunigen oder auch eine andere NIC, dann wäre das Problem evtl einfach gelöst.

PCI-Durchsatz: ~66MB/s. Da während der Übertragung sonst nichts (oder keine großen atenmengen) auf dem Bus passiert, dürfte das fast vollständig der Karte zur Verfügung stehen. Ist aber auch nicht die Frage, ob der Bus limitiert, denn ich seh ja an der CPU-Auslastung, dass die CPU die Bremse ist. Möglicherweise ist dann auch irgendwann beim PCI-Bus Schluss, aber sicher noch nicht bei 28 MB/s.


@olympiakos:
Habe es mit dem Registry-Eintrag mal getestet: keine Änderung (natürlich nach Reboot). Habe in die Ereignisanzeige geschaut (ich hatte früher schon im Gerätemanager bei "Statusmeldungen protokollieren" den Wert "Alle Meldungen" aktiviert), und da sind jetzt die Einträge
- "TCP hardware checksum offload enabled"
- "IP hardware checksum offload enabled "
- "TX TCP hardware checksum offload enabled "
vorhanden. Das scheint also formell funktioniert zu haben. Allerdings, wenn ich in der Ereignisanzeige weiter herunterblättere, wurden diese Einträge auch schon vor dem Eintrag in die Registry ins Eventlog geschrieben. Heißt also: Das ist wohl schon die Standardeinstellung, folglich hat sich an der Speed auch nichts geändert.

Aber: Habe beim NIC bei beiden Rechnern die "Jumbo-Frames" aktiviert. Komme jetzt immerhin auf 30 MB/s (statt 28). Die CPU-Limitierung ist natürlich geblieben.

Ich suche mal weiter bzgl Netzwerkoptimierung bei GBit...

Danke bis hierher schonmal!
 
Du könntest unter Linux auch einfach einen FTP Server aufsetzen und auf eine Ramdisk zugreifen oder so. Ansonsten schaue dir mal das an: http://lbs.sourceforge.net/


edit: "Jumbo-Frames" vergrößern einfach die MTU ...


mfg
 
Was ich noch mir noch einfällt..dieser Registry Eintrag funktioniert nur wenn die Netzwerkkarte einen eigenen Prozessor besitzt.

Ältere Netzwerkarten, oder billige Netzwerkarten haben keinen eigenen Prozessor und das könnte auch der Grund sein, warum die CPU so gefordert wird.
 
:freak:

Also, Leute, ihr glaubt es nicht...

Auf dem Rechner ist Zonealarm installiert. Zum Testen habe ich dat Ding natürlich beendet. Auch der zugehörige Dienst "Truevector..." ist beendet. So schlau bin ich dann doch, dass ich das vorher ausschalte. Aaaaber....

Habe mir jetzt mit dem Process Explorer den "System"-Prozess genauer angesehen. Dort auf den Reiter "Threads". Rund 20% CPU-Last gehen auf das Konto "vsdatant.sys". Ich suche das Ding auf der Platte, gehe in die Eigenschaften und sehe, dass das zu Zonealarm gehört!

Also, runter mit Zonealarm, und siehe da: 49 MB/s

Was soll man sagen? Wieder etwas dazugelernt!?

Natürlich sind es jetzt immer noch 100% CPU-Last, aber die 49 MB sind ja schon fast das Maximum, was man rausholen kann. Bin also (fast) wunschlos glücklich.

Äh, also.... :mussweg: :D

Danke an alle Mitmacher! :daumen: Und allen zukünftigen Lesern mit demselben Problem sei hiermit die Suchfunktion nochmal ans Herz gelegt. :p
 
Das Problem hatte ich auch mal in einem 100MBit Netzwerk. Mit DC++ ist ZoneAlarm zum CPU Killer geworden.
 
Es macht ja wenig Sinn, das Ganze zu messen, ohne die Festplatten einzubeziehen. 28 MB/s ist für ein GBit-Netzwerk ein ganz normaler Wert (ein entscheidender Parameter für die Geschwindigkeit sind z.B. auch die Dateigrößen). Wenn ich von RAM-Disk zu RAM-Disk übertrage, komme ich auch auf den doppelten Wert.
 
Zuletzt bearbeitet:
Kuhni Lingus schrieb:
Es macht ja wenig Sinn, das Ganze zu messen, ohne die Festplatten einzubeziehen.

Wieso? Wenn du einen Plattenbenchmark fährst, dann machst du das ja auch nichts übers LAN, weil du willst ja die Plattengeschwindigkeit wissen.

Warum sollten 28MB "normal" sein? Es geht darum, Bremsen auszubauen, um dem theoretisch Maximum möglichst nahe zu kommen. Wenn ich jetzt schon bei 49 MB bin, dann würde ich 28 nicht mehr als normal bezeichnen. Natürlich geht es erst einmal um das theoretische Maximum und nicht um das praktische Mittel. Für Flaschenhälse muss man ja nicht sorgen sondern ich versuche ja erst einmal, sie zu beseitigen.
 
Zuletzt bearbeitet:
Kuhni Lingus schrieb:
Messen sollte man nur unter realistischen Bedingungen. Sonst ist das Messen relativ wertlos.

Ich weiß nicht, was du messen willst. Ich weiß aber, was ich messen will. Offenbar ist das nicht das gleiche.
 
Kuhni Lingus schrieb:
Mit welchem Programm hast du denn überhaupt getestet ? Ich würde das gerne mal nachvollziehen.

s. Anhang. ABER: Das Ding ist eigentlich nciht für die Öffentlichkeit gedacht, als net dran rummeckern. :D Ich kann auch weder für Fehlerfreiheit noch Funktionsfähigkeit unter allen Umständen garantieren. Einsatz also auf eigene Gefahr. So, damit das formelle.

Voraussetzung ist .Net Framework 3.5 (evtl läufts auch mit Framework 2.0, also erst mal nur damit versuchen. Nur wenn das net geht, Framework 3.5 draufmachen; ebenso auf eigene Gefahr)

Anleitung:
Auf einem Rechner links unter einem Adapter eine IP wählen und auf "Start server" klicken

Dann auf dem anderen Rechner rechts oben bei "remote host" die IP des Servers eingeben und "Start send" klicken.


Es gibt aber sicher noch massenweise andere Progs, die die LAN-Speed testen.
 

Anhänge

So, ich habe getestet. Ist 'ne interessante Geschichte, denn das Tool (hast du das selber programmiert ?) misst exakt. Ich habe gegengecheckt mit AdapterWatch

http://www.nirsoft.net/utils/awatch.html

, welches mir genau denselben Wert anzeigt wie dein Tool; ich komme auf 52 MByte/s. Das ist in etwa auch der Wert, den ich beim Vergleich RAM-Disk zu RAM-Disk hatte; insofern kann man sagen, dass hier tatsächlich das gemeseen wird, was gemessen werden soll (das ist ja nicht immer selbstverständlich), nämlich der reine Geschwindigkeitswert zwischen den Netzwerkkarten.

Also, ich muss dir da im Nachhinein doch Recht geben; ein solcher Wert ist schon interessant, gerade auch in der Differenz zu den Werten von Festplatte zu Festplatte.

Die CPU-Auslastung liegt dabei bei meinem Client, mit dem ich getestet habe (Pentium M, 1.86 GHz) bei ungefähr 50%.
 
Hallo.

Die CPU Belastung kommt schlicht und ergreifend i.d.R. von Scheiss Netzwerkkarten.
Solltest du PCIe haben, kauf die ne Intel Pro 1000/pt, ansonsten irgend ne vernuenftige Intel Karte, welche TOE, Interrupt Moderation und Checksum Offload beherrscht, und einen moeglichst grossen internen Puffer hat.

Was bei dir so eine hohe CPU Last verursacht sind die Interrupts der NIC. Wenn es eine billige ist, hast du pro Paket einen Interrupt - bei high performance Gbit koennen das 10000 - 50000/s sein.

Aber dennoch wirst du nach dem upgrade noch keine (wesentlich) hoeheren Werte sehen, die kommen erst, wenn du die TCP Window Size anpasst (google ist dein Freund).



greetz
 
MrWeedster schrieb:
Die CPU Belastung kommt schlicht und ergreifend i.d.R. von Scheiss Netzwerkkarten.
Solltest du PCIe haben, kauf die ne Intel Pro 1000/pt, ansonsten irgend ne vernuenftige Intel Karte, welche TOE, Interrupt Moderation und Checksum Offload beherrscht, und einen moeglichst grossen internen Puffer hat.

Was bei dir so eine hohe CPU Last verursacht sind die Interrupts der NIC. Wenn es eine billige ist, hast du pro Paket einen Interrupt - bei high performance Gbit koennen das 10000 - 50000/s sein.


- Habe AGP
- Interrupt-Limit habe ich auf 10.000 hochgesetzt (Standard: 1.000). Danach habe ich ~5000 Interrupts/s gemessen. Macht bei Jumbo Frames von 9000 Bytes wirklich (grob gerechnet) 1 Interrupt pro Paket (9000 x 5000 = 45.000.000). Damit könntest du also recht haben.
- Die "Anzahl der Empfangspuffer" (bei der NIC) zu erhöhen hat nichts gebracht.

Ansonsten sagt mir die NIC:
- "TCP hardware checksum offload enabled"
- "IP hardware checksum offload enabled "
- "TX TCP hardware checksum offload enabled "


Aber dennoch wirst du nach dem upgrade noch keine (wesentlich) hoeheren Werte sehen, die kommen erst, wenn du die TCP Window Size anpasst (google ist dein Freund).

Muss ich ma gucken.
 
Zurück
Oben