Artikel
Aktives GUI-Element
Statisches GUI-Element
Quelltext
WPS-Objekt
Datei/Pfad
Befehlszeile
Inhalt Eingabefeld
[Tastenkombination]
GigaBit LAN
oder: Turbolader für Netzwerke
Historie
Über die Jahre ist mein einfaches Heimnetzwerk gewachsen. Ursprünglich hatte ich einst zwei PCs, die über ein Crossover-Kabel (gekreuztes Kabel) miteinander verbunden waren - und eine Einwählverbindung zum Internet über ein Modem. Als ich dann meinen Kabelanschluß hatte, installierte ich eine zusätzliche separate Netzwerkkarte und schloß darüber das WAN-(Kabel-)Modem direkt an meinen Hauptrechner an. Ich verwendete statische IP-Adressen für das lokale Netzwerk und eine dynamische für die Internetverbindung via Kabelmodem. Diese Konfiguration ist in Abbildung1 dargestellt.
Abb. 1: Ursprüngliche Netzwerkkonfiguration
Damit ich nun mit beiden PCs ins Internet konnte, mußte der Hauptrechner immer eingeschaltet sein, ebenso, wenn ich von meinem zweiten Heimrechner (Home2) etwas drucken wollte. Die Lösung hierfür war relativ simpel: Ein Breitbandrouter mit eingebautem Druckserver. Ich entschied mich für einen SMC7004ABR, der 4 LAN-Anschlüsse hatte (ich konnte jetzt also bis zu 4 Rechner anschließen), einen WAN-Anschluß für die Verbindung mit meinem Motorola-Kabelmodem und zu guter Letzt einen Parallel-Port für den Druckserver (siehe Abbildung 2).
Abb. 2: Überarbeitete Netzwerkkonfiguration
Da der Router über einen eingebauten DHCP-Server verfügt (der standardmäßig aktiviert ist), konnte ich also relativ leicht von statischen zu dynamischen IP-Adressen wechseln. Zumindest theoretisch. Die Installation des Routers war nicht kompliziert. Ich entfernte also schlicht das Netzwerkkabel vom LAN0-Anschluß meines Rechners Home1 und steckte es in die WAN-Buchse des Routers. Mit Hilfe des Netzwerkkabels aus dem Lieferumfang des Routers schloß ich dann meinen Home1 (über seine LAN0-Buchse) an den ersten der vier Netzwerkanschlüsse des Routers an. Dann fiel mir auf, daß ich ein zusätzliches Kabel benötigen würde, um auch meinen zweiten Rechner Home2 an den Router anzuschließen, da mein verbliebenes Netzwerkkabel ja ein Kreuzkabel und kein simples Patchkabel war. Einige Router und Netzwerkkarten sind in der Lage, den verwendeten Kabeltyp selbsttätig zu ermitteln und sich entsprechend automatisch zu konfigurieren, ohne daß dadurch irgendwelche Einbußen entstehen. In Unkenntnis darüber, ob das auch auf meinen Router und die fragliche Netzwerkkarte zutraf, entschloß ich auf Nummer sicher zu gehen und ein zusätzliches Standardnetzwerkkabel zu kaufen.
Abb. 3: Konfiguration der LAN-Schnittstelle zur Verwendung von DHCP im TCP/IP-Einrichtungsdialog
Zunächst deaktivierte ich die Schnittstelle Lan1 an Home1 (weil diese ja nicht länger benötigt wurde). Nachdem ich dann mit dem neuen UTP-Kabel die Verbindung zwischen Home2 und der zweiten der vier LAN-Buchsen des Routers herstellte, beschäftigte ich mich mit der Umstellung der statischen IP-Adressen von Home1 und 2 auf dynamische Adreßvergabe. Dies wird erreicht durch die Verwendung des Programms TCPCFG in Warp (unter eCS 1.2 lautet der Name TCPCFG2) oder alternativ durch Starten von Systemkonfiguration -> Netzwerk > TCPIP > TCP/IP-Konfiguration. Welchen Weg auch immer Sie nehmen, findet sich die ausschlaggebende Einstellung auf der ersten Seite (Reiter Netzwerk) und kann mittels der Option Automatisch mit DHCP eingestellt werden (siehe Abb. 3).
Namen
Nachdem ich das auf beiden System gemacht, die Änderungen gespeichert und jeweils einen Neustart durchgeführt hatte, waren beide Rechner im Netzwerk wieder sichtbar. Obwohl die Namen der Rechner im File and Print Client Browser sichtbar waren, stand diese Information nur über das NETBEUI-Protokoll zur Verfügung, nicht aber für Programme, die TCP/IP verwendeten. Obwohl ich also Home1 im File-Browser sehen konnte, lief der "ping" mit diesem Namen ins Leere. Das TCP/IP-Protokoll benötigt eine Übersetzung von Hostnamen in IP-Adresse. Diese Umsetzung wird entweder durch einen Domain Name Server (DNS) erreicht, oder durch eine Suchfunktion auf Basis der hosts-Datei - oder einer Kombination beider. Sowohl Suchreihenfolge als auch alle in der hosts-Datei (\mptn\etc\hosts) enthaltenen Informationen wird im Reiter Hosts Names (s. Abb. 4) des Einstellungsdialogs TCP/IP-Konfiguration angezeigt.
Abb. 4: Einstellung zur Auflösung der Hostnamen mittels der TCP/IP-Einstellungen
Da ich keinen DNS Rechner einsetze, mußte ich also meine hosts-Datei so aufbauen, daß die benötigten Angaben darin enthalten waren. dafür benötigte ich also die IP-Adressen der PCs, die via DHCP vergeben wurden. Dies läßt sich mittels des Programms DHCPMON auf dem jeweiligen Rechner bewerkstelligen oder (zumindest mit meinem 3COM 3CRWE554G72T Router, der den ursprünglichen SMC2804 WBRP-g-Router aufgrund dessen Ausfalls ersetzte) dadurch, daß der Router die Liste der Rechnernamen und IP-Adressen selbsttätig in die Hostliste einfügt. Für diese letztgenannte Variante muß man allerdings den einzelnen PCs noch mitteilen, daß Sie dem DHCP-Server ihrem jeweiligen Hostnamen mitteilen. Bei einigen Betriebssystemen wie Windows 2000 ist das die Voreinstellung - nicht so bei eCS. Hier muß der Datei \mptn\etc\DHCPCD.CFG des jeweiligen PCs eine Zeile im Abschnitt Options hinzugefügt werden, die da lautet:
option 12 Host name
Wobei der "Host name" natürlich je nach PC unterschiedlich ist.
Nachdem ich alle fraglichen DHCPCD.CFG-Dateien angepaßt und die betroffenen PCs neu gestartet hatte, tauchte in meinem Router dann auch eine entsprechende Liste von Hostnamen und IP-Adressen auf (Abb. 6). Der Vorteil hiervon ist, daß ich von jedem Rechner in meinem Netzwerk nun auf eine zentrale Liste der Rechnernamen und IP-Adressen zugreifen kann - nämlich im DHCP-Server meines Routers. Das erlaubte es mir, diese Angaben mittels Kopieren-und-Einfügen in die hosts-Dateien der PCs meines Netzwerks einzufügen. Das unmittelbare Ändern der hosts-Dateien ist meiner Meinung nach einfacher, als die Arbeit mit dem Host Names Reiter aus dem Einstellungsnotizbuch von TCP/IP-Konfiguration, obwohl man sorgfältig auf das Format achten muß.
Internet
Das Internet war wiederum ein anderes Problem. Ich konnte keine Verbindung zu meinem Provider aufbauen. Ich mußte hier auf schmerzliche Art erfahren, daß einige ISPs (darunter auch meiner, UPC) die MAC-Adresse der Netzwerkkarte als Authentifizierungskriterium bei der Einwahl in deren System verwenden. Als ich den Router anschloß, hatte ich mich also quasi "ausgeschlossen", da die MAC-Adresse auf Seite meines Providers nun eine andere war und ich damit ein ungebetener Gast. Obwohl ich die Änderung der MAC-Adresse meinem ISP mitteilen und eine erneute Freischaltung hätte beantragen können, entschied ich mich für die alternative Methode, die mein Router mit zur Verfügung stellte: Das Klonen der MAC-Adresse. Dies ist ein Verfahren, bei dem die Adresse der Netzwerkkarte vom Router übernommen und über die WAN-Verbindung zur Außenwelt übergeben wird. Um diese Methode zu verwenden startete ich das Einstellungsmenü meines Routers. Dieses Menü kann über Mozilla oder jeden anderen Browser bedient und erreicht werden, indem man einfach die Netzwerkadresse des Routers in der URL-Eingabezeile angibt. Darauf antwortet der Router mit einem Login-Bildschirm. Nach einem erfolgreichen Login stehen dann alle verfügbaren Einstellungen in Form von Webseiten zur Verfügung. Im 3COM-Router befindet sich die Funktion zum Klonen der MAC-Adresse auf der Seite Internet Settings (s. Abb. 7), die über einen einzigen Reiter verfügt und sich auf die Auswahl der entsprechenden Option beschränkt.
Das Einrichten des Druckers ist übrigens genauso einfach und wurde bereits in einer früheren Ausgabe des VOICE-Newsletters beschrieben.
Verbindung mit Windows
Das Verbinden mit Windows war kein Problem, solange ich dabei darauf achtete, den gleichen Arbeitsgruppennamen, Benutzernamen und Paßwort auf beiden System zu benutzen. Im Installationshandbuch zu eCS gab es einen Hinweis am Ende von Kapitel 4, daß man die Einstellung LMannounce auf ON für jegliche Windows-Systeme (95/98/ME/NT/2000/XP) ändern soll. Bei 95/98 und ME ist das nicht weiter schwierig, jedoch erfordert es in NT, 2000, und XP eine Änderung in der Windows-Registry. Nachdem ich diese Einstellung auf ON änderte, konnte ich nicht wirklich einen Unterschied feststellen. Ein Problem, welches sich damit nicht beheben ließ und das bei der Verbindung zu einem XP-System scheinbar häufiger auftrat als bei Verbindung zu einem W2K-System war, daß eine Fehlermeldung erschien, auf eine Datei oder ein Verzeichnis könne nicht zugegriffen werden und daß mein eCS-Rechner keine weiteren Verbindungen mehr akzeptieren könne. Dieses Problem löst man durch die Änderung der folgenden Parameter im Reiter Konfiguration von Sharing and Connecting (s. Abb. 7a).
Abb. 7a: Anpassen der maximalen Anzahl von Verbindungen über Gemeinsame Ressourcen und Netzwerkverbindungen [Großes Bild]
Setzen Sie hier die Shareable resources (MAXSHARES) von 16 auf 160, Connections to resources
(MAXCONNECTIONS) von 26 auf 2000 (obwohl das wahrscheinlich viel zu hoch ist) und Open files
(MAXOPENS) von 128 auf 160. Die Namen in Klammern stehen für die entsprechenden Parameter aus der
IBMLAN.INI-Datei, die sich dahinter verbergen und die Sie dort direkt ändern
können, falls Ihnen das lieber ist. Nach dem Speichern der gemachten Änderungen ist ein Neustart
nötig, damit die neuen Angaben vom System übernommen werden.
Zwei Router
Die nächste Änderung in meinem Netzwerk geschah, als ich ein ASUS-Notebook kaufte und damit eine drahtlose Netzwerkverbindung herstellen wollte. Ich ging also auf die Suche nach einem WLAN-Router und entschied mich für einen SMC2804 WBRP-g-Breitbandrouter, da der SMC Barricade immer problemlos funktioniert hatte und ich die Hoffnung hatte, die Konfiguration würde ähnlich aussehen und funktionieren - was sie auch tat. Ich war mir nicht sicher, wie ich zwei Router gleichzeitig benutzen könnte, doch ich wollte nicht auf die Druckserver-Funktionalität meines ursprünglichen Router verzichten und ferner den WLAN-Router an einem beliebigen Ort installieren können, wo immer die Empfangsqualität am besten erschien. Nach Rücksprache mit SMC’s Kundendienst wurde mir klar, wie ich zwei Router in meinem Netzwerk einrichten müßte. Es stellte sich heraus, daß es zwei Methoden dafür gab - in Abhängigkeit davon, was man damit bezwecken will (s. Abb. 8).
Methode A benutzt man, wenn alle Ressourcen des Netzwerks für alle PCs im Netzwerk zur Verfügung stehen sollen. In diesem Fall wird der zweite Router als Switch verwendet. Methode B dient zur Isolierung der am zweiten Router angeschlossenen Rechner vom Rest des Netzwerks. Die Isolierung wird dadurch erreicht, daß es nun zwei Netzwerksegmente gibt. Mit Methode B ist die Internetverbindung für das Notebook nach wie vor möglich, die gemeinsame Nutzung von Dateien jedoch in einem bestimmten Maß eingeschränkt. Ich entschied mich für Methode A.
Ich schloß lediglich den WLAN-Router an einen PC an und schaltete diesen ein. Da dieser Router der primäre Router des Netzwerks sein würde, wäre er für die Vergabe von IP-Adressen über DHCP zuständig. Das bedeutete, daß ich den DHCP-Server des anderen Routers würde ausschalten müssen und, da beide Router mit derselben initialen IP-Adresse ausgeliefert wurden, ich auch seine IP-Adresse ändern mußte. Mit der bestehenden Verbindung vom PC aus meldete ich mich am Router an. Zunächst änderte ich den DHCP-IP-Adreßbereich des Routers, um eine freie Adresse zu bekommen, die ich dem anderen Router zuweisen konnte. Hierfür rief ich im Menü den Einstellungsbildschirm auf (s. Abb. 9) und änderte die Adressen (des sog. IP-Adreßpools), damit diese zwischen 192.168.2.100 und 192.168.2.254 lagen. Dadurch wurden nur noch IP-Adressen aus dem angegebenen Bereich per DHCP vergeben und ich konnte eine der entsprechenden darin nicht enthaltenen Adressen (mit Ausnahme von 255, die für Rundsendeadressierung verwendet wird) als IP-Adresse meines zweiten Routers verwenden.
Da mein anderer Router nach wie vor dieselbe Adresse wie mein gerade eingestellter neuer WLAN-Router besaß, mußte ich zunächst einmal den zweiten, alten Router wieder anschließen und dessen Einstellung ändern. Nach dem Anmelden (über die bisherige alte IP-Adresse) deaktivierte ich den DHCP-Server des alten Routers, um Konflikte zu vermeiden und änderte seine IP-Adresse auf 192.168.2.99. Ein potentielles Risiko dabei war allerdings, daß, wenn ein Reset des (alten) Routers hätte stattfinden müssen (aus welchem Grund auch immer, zum Beispiel wegen eines vergessenen Paßworts), dieser wieder mit seiner werksmäßig voreingestellten Konfiguration gestartet wäre - einschließlich der IP-Adresse. Das würde es dann nötig machen, den neuen Router wieder zwischenzeitlich zu deaktivieren. Ein sehr nützliches Merkmal, daß meines Wissens nach wohl in den meisten Routern vorhanden ist, ist deren Fähigkeit, sämtliche Einstellungen in einer beliebigen Datei zu sichern, was ich dann auch prompt tat. Vorsichtshalber habe ich diese dann auch direkt auf einer Floppy-Diskette gespeichert. Nach circa zwei Jahren ging der Router allerdings leider - wie bereits erwähnt - kaputt, und seitdem arbeitet an seiner Stelle ein 3COM 3CRWE554G72T.
Nachdem der WLAN-Router dann wieder angeschlossen wurde, hatte ich wieder vollen Zugriff, sowohl über Netzwerkkabel mit meinem beiden PCs als auch drahtlos mit dem Notebook. Das Bereitstellen einer drahtlosen Verbindung für das Notebook öffnete natürlich nicht nur mir den Zugang zu meinem Netzwerk sondern de facto auch der ganzen Welt. Um mich zu schützen verwendete ich WEP-Verschlüsselung zusammen mit einer Zugangsliste (s. Abb. 10). Dadurch war es nur noch einem PC mit einer bestimmten MAC-Adresse gestattet, drahtlosen Zugriff auf mein Netzwerk zu bekommen. Die MAC-Adresse in Abbildung 10 wurde aus offensichtlichen Gründen entfernt.
Gigabit
Als ich das Mainboard meines Haupt-PCs durch ein ASUS K8V mit einem Athlon 64 CPU ersetzte, verwendete ich zunächst weiterhin meine vorhandene 3COM-3C905-Netzwerkkarte. Aber ich begab mich auch auf die Suche nach einem Treiber, der die auf dem Mainboard enthaltene Gigabit-LAN-Netzwerkkarte unterstützte, da die CDs aus dem Lieferumfang eines Mainboards für gewöhnlich nur Windows-Treiber enthalten. Ich hatte gelesen, daß ein möglicher Treiber die GENMAC Wrapper-Treibersammlung sein könnte (ftp://ftp.netlabs.org/pub/wlan/genmac100.zip). Dieser Treiber unterstützt 21 unterschiedliche Chipsätze - da ich aber keine Ahnung hatte, welcher Chipsatz auf dem ASUS Mainboard verarbeitet war, startete ich das PCI-Bus-Sniffer-Programm (pci104vka.zip auf Hobbes). Dieses ermittelt eine ausführliche Menge an Informationen zu allen Geräten im Dunstkreis von PCI und VGA, die auf einem Mainboard enthalten sind, darunter auch die Informationen zum Onboard-Netzwerkkarten-Chipsatz. Hierzu erhielt ich folgendes:
Bus 0 (PCI), Device Number 10, Device Function 0
Vendor 10B7h 3COM Corp, Networking Division
Device 1700h 3C940 Gigabit Ethernet PCI CODEC
Subsystem ID 80EB1043h Integrated Gigabit Ethernet Controller
Subsystem Vendor 1043h ASUSTeK Computer Inc
Da dieser Chipsatz vom GENMAC Wrapper-Treiber unterstützt wurde, startete ich also dessen Installationsroutine, welche die enthaltenen Treiber im System verfügbar macht. Danach rief ich das MPTS-Programm über Systemkonfiguration > Netzwerk > Protokolle und Adapter auf, um den neuen Treiber auszuwählen.
Da die 3COM 3C905 bereits installiert und vollständig konfiguriert war, erwies es sich für den Wechsel zur Onboard-Netzwerkkarte als die einfachste Methode, lediglich den GenMac-Wrapper-Treiber über die Schaltfläche Change auszuwählen. Dies bewirkte einen simplen Austausch des Treibers unter Beibehaltung aller Protokolle, die nun jedoch mit der neuen Netzwerkkarte verknüpft wurden. Damit hatte ich also TCP/IP, NetBIOS over TCP/IP und NetBIOS alle mit dem Gigabit-LAN verbunden. Nach einem Neustart jedoch zeigte sich, daß hier zweifelsohne etwas nicht in Ordnung war, denn obwohl ich über DHCP eine IP-Adresse erhalten hatte, starteten die PEER-Dienste nicht korrekt. Normalerweise erscheint beim Start des PEER-Dienstes nach ein paar einleitenden Textzeilen eine Zeile mit Punkten, die ca. alle zwei Sekunden um einen Punkt ergänzt wird. Es dauert dann für gewöhnlich ungefähr 7 Punkte, bis der PEER-Dienst gestartet wurde. Nun aber hatte ich eine Zeile mit Punkten, die bis zum rechten Bildschirmrand reichte und danach eine Fehlermeldung: NET 3060. Die Eingabe help NET3060 lieferte mir den folgenden nützlichen(?) Schnipsel an Information:
NET3060: The service did not respond to a control signal and was stopped with the DosKillProc function.
Cause: The service may not be responding to a request to stop or start. An unrecoverable error might have occurred. The service was stopped.
Action: If this error occurred while starting the requester, ensure that the product of the PROTOCOL.INI file parameters NETBIOSTIMEOUT and NETBIOSRETRIES does not exceed 20000 (20 seconds). Try the operation again. If the problem persists, start the workstation again. If the problem still persists, report the problem and the method by which it can be reproduced to your IBM support representative.
Soweit ich mich erinnern kann, war zu diesem Zeitpunkt gerade kein IBM-Verantwortlicher in der Nähe - aber ich konnte mich erinnern, irgendwo etwas über Probleme mit NetBIOS und dem GenMac-Wrapper-Treiber gelesen zu haben. Ich entfernte also das NetBIOS-Protokoll, startete neu - und dann lief alles.
Die nächsten Schritte
Jetzt also hatte ich meine neue Hardware am Laufen. Um sie jedoch nutzen zu können, benötigte ich mindestens eine weitere Netzwerkkarte mit Gigabit-Unterstützung. Nachdem ich mir die Webseite mit der Liste OS/2-kompatibler Hardware angeschaut und diese mit dem Netzwerkkartenbestand meines örtlichen PC-Händlers abgeglichen hatte, kam genau ein Modell in Frage. Eine 3Com 3C2000-T 1000/100/10Mbps-PCI-Netzwerkkarte. Diese kaufte ich dann, obwohl sie mit 55 Euro schon relativ teuer war. Nachdem ich die Karte in meinen anderen Rechner eingebaut hatte, installierte ich den OS/2-Treiber hierfür, bei dem es sich um den GENMAC-Treiber handelte (nicht zu verwechseln mit dem GENMAC Wrapper-Treiber). Da der Router die Geschwindigkeit meines Netzwerks auf 100 Mbps begrenzen würde, verband ich meine beiden PCs direkt miteinander - nachdem ich das alte Kreuzkabel wieder ausgegraben hatte. Da die LED für Übertragung mit 1 Gbit an der 3COM aufleuchtete und die Übertragungsgeschwindigkeit höher als zuvor war, schloß ich daraus, daß die Verbindung nun also mit 1 Gbps lief. Das war nun also die halbe Miete auf dem Weg zum Gigabit, aber wie sollte ich jetzt das Routerproblem lösen? Zwar gibt es bereits Router mit 1 Gbps, allerdings sind diese im großen und ganzen noch sehr, sehr teuer und definitiv sehr, sehr weit von meinem Budget entfernt.
Die Antwort erwies sich als ausgesprochen simpel. Man verwendet einen 1 Gbps Netzwerkswitch um die beiden Rechner mit Gigabit LAN untereinander und mit dem Rest des Netzwerks zu verbinden. Meine Wahl fiel auf einen Edimax ES-5500P 5port 10/100/1000 Mbps Switch, der für knapp unter 50 Euro angeboten wurde. Seit dem Hinzufügen des Switchs zu meinem Netzwerk sieht dieses wie folgt aus:
Abb. 12: Netzwerktopologie mit Gigabit-Transfer zwischen den dafür ausgelegten Geräten [Großes Bild]
Anfängliche Überraschungen
Um mir einen Eindruck davon zu verschaffen, welchen Unterschied 1 Gbps macht, führte ich umfangreiche Tests durch. Da ich zunächst wissen wollte, welche Geschwindigkeit ich maximal erreichen könnte, entschloß ich mich zur Verwendung von virtuellen Laufwerken (im Hauptspeicher) um jegliche Verfälschung der Ergebnisse wegen Plattenzugriffszeiten zu vermeiden und mittels FTP eine 150 MB große Datei (157,286,400 Bytes) zu übertragen. Daraus ergab sich die Notwendigkeit, einen FTP-Server einzurichten und virtuelle Laufwerke anzulegen. Für letzteres verwendete ich RAMFS121 (erhältlich von Hobbes) und legte damit auf jedem der beiden PCs ein virtuelles Laufwerk an. Dann konfigurierte ich ebenfalls auf beiden Rechnern einen FTP-Server, indem ich den Reiter Security aus der TCP/IP-Konfiguration verwendete, einen Benutzernamen und Paßwort hinzufügte und für uneingeschränkten Zugriff zwischen beiden Systemen sorgte. Der eigentliche Test bestand aus dem 'Senden' der Daten vom RAM-Laufwerk des einen PCs zu einer NUL-umgeleiteten Datei auf dem anderen PC sowie dem 'Empfangen' der Daten vom RAM-Laufwerk des anderen Rechners entsprechend in eine NUL-Umleitung des lokalen PCs. Die Daten bestanden wie bereits erwähnt aus einer 150-MB-Datei, und die Test wurden 10mal jeweils mit 1 Gbps und 100 Mbps im binären Übertragungsmodus wiederholt. Bei den folgenden Angaben handelt es sich um die mit der Befehlszeilenversion des FTP-Programms ermittelten Durchschnittswerte.
Wie zu erkennen ist, liegt der konstante Durchsatz bei Leseoperationen mit 100 Mbps knapp über 91 Mbps. Bei 1 Gbps sieht das allerdings anders aus. Hier gibt es signifikante Unterschiede in Abhängigkeit vom Initiator und der Richtung des Datentransfers. Der höchste erreichte Wert liegt bei 321 Mbps, was ungefähr dreimal weniger ist als die Spezifikation von 1 Gbps, während der niedrigste Wert bei 231 Mbps liegt. Bei der Datenübertragung mit 1 Gbps betrug die CPU-Last auf der sendenden Seite nahezu durchweg 99.8 %, wobei die IRQ-Last bei ca. 46 % lag. Das läßt darauf schließen, daß die Rechenkapazität des Senders hier für die erzielbare Übertragungsrate ausschlaggebend war. Diese theoretische Annahme läßt sich auch durch folgenden Sachverhalt untermauern: Der schnellere Rechner ist Home1, ein PC mit einem 3000+ (2.0 GHz) AMD 64-Bit-Athlon-Prozessor (2120 CPU integer marks – SysBench 0.94g), wohingegen Home2 über einen 1700+ (1.7 GHz) AMD-Athlon-Prozessor (1443 CPU integer marks) verfügt. Anders gesagt ist also die Rechenleistung von Home1 circa 1,47mal (2120/1443) so hoch wie die von Home2. Die Übertragungsrate beim Versenden einer Datei von Home1 beträgt 321 Kbps und ist damit im Vergleich zu 231 Kbps (beim Senden von Home2 aus) ungefähr 1,42mal höher bzw. schneller.
Da das obige eher theoretisch war, wollte ich eine etwas realistischere Situation ausprobieren und entschied mich, die herkömmlichen PEER-Dienste für gemeinsame Zugriffe zu verwenden. Für diese Test verwendete ich wiederum die beiden PCs Home1 und Home2. Da auf beiden Rechner sowohl eCS als auch Windows 2000 installiert war, wollte ich zusätzlich auch noch die Übertragungsraten für beide Betriebssysteme ermitteln. Die Testmethode war im Prinzip dieselbe wie zuvor, allerdings ordnete ich nun einem Netzwerklaufwerk einen Laufwerksbuchstaben zu und kopierte eine 500 MB große Datei (524,288,000 bytes) in jeweils beide Richtungen für jeden PC. Ich testete ebenfalls die Kombinationen mit verschiedenen Betriebssystemen - also von und nach eCS, von und nach W2k sowie von eCS nach W2K und umgekehrt mit jeweils 100 Mbps und 1 Gbps. Auch diese Tests wurden jeweils 10mal durchgeführt, wobei aber die Mittelwertberechnung ohne die jeweils zwei schlechtesten Messungen gemacht wurde, also basierend auf den restlichen 8 Durchgängen. Der Grund hierfür war, daß in Windows manchmal ein Dienst erst bei Beginn der Übertragung gestartet wurde - was das Meßergebnis natürlich verfälschte. Um die Messungen zu automatisieren und das Ganze etwas weniger aufwendig zu gestalten verwendete ich eine Stapeldatei, die wie folgt aufgebaut war:
Time < Enter >time
Copy 500Mb.bin v:\
Time < Enter >>time
(...und die obigen Zeilen insgesamt neun Mal wiederholt)
Enter ist nichts als eine Datei, die dem time-Befehl das Drücken der Eingabetaste unterjubelt, damit die aktuelle Systemzeit angezeigt, aber nicht verändert wird. Die jeweilige Ausgabe der Uhrzeit wird umgeleitet in eine Datei namens time.
Die ersten Ergebnisse waren irgendwie verwirrend. Die Übertragung unter eCS bei 1 Gbps von Home2 zu Home1 war zweieinhalbmal langsamer als mit 100 Mbps.
Abb. 17: CPU-Last während der Übertragung zwischen Home1 und Home2
Ich prüfte alles. Kabel, Verbindungen, Einstellungen, Switch, einfach alles und das Ganze doppelt - es half nichts. Da die ermittelten Werte für die Übertragungsraten unter Windows keine solche Auffälligkeiten zeigten, schloß ich daraus, daß es sich nicht um einen Hardwarefehler handeln könne. Außerdem war die CPU-Last bei 1 Gpbs ziemlich seltsam bei der Übertragung von Home2 zu Home1, wie in Abbildung 17 (links) zu erkennen ist. Bei Übertragung in umgekehrter Richtung (also von Home1 zu Home2) war die Auslastung viel gleichmäßiger und auch niedriger (Abb. 17, rechtes Diagramm) und der Durchsatz um ein vielfaches besser.
Neuer Treiber
Da ich Hardware als Ursache ausschließen konnte, mußte der Übeltäter wohl eher der Gattung Software entstammen. Da der GenMAC Wrapper-Treiber (ver 1.0) ganze 21 Chipsätze unterstützt, nahm ich nochmals das PCI-Sniffer-Programm zur Hand und untersuchte, welcher Chipsatz in der neuen 3Com 3C2000-T-Netzwerkkarte verbaut war. Stellen Sie sich meine Überraschung vor, als ich heraus fand, daß es sich um denselben Chipsatz handelte, der auch auf dem Mainboard meines Home1 verwendet wurde. Das Wechseln zum neuen Treiber behob die vorgenannten Probleme und lieferte nun folgende Werte in meiner Meßreihe:
Abb. 18: Übertragungszeiten beim Schreiben zwischen eCS-Rechnern mit dem GenMac 1.0 Wrapper-Treiber [Großes Bild]
Abb. 19: Übertragungszeiten beim Lesen zwischen eCS-Rechnern mit dem GenMac 1.0 Wrapper-Treiber [Großes Bild]
Wie man erkennen kann, sind die Meßwerte nun in sich konsistenter. Die Unterschiede bei 1 Gbps kommen vermutlich durch unterschiedliche Zugriffszeiten der Festplatte oder aufgrund anderer Leistungsparameter zustande. Der maximale Durchsatz erhöhte sich durch Einsatz dieses Treibers ebenfalls um 12 %.
eCS ist schneller als W2k und W2k ist schneller als eCS
Da ich auf beiden Rechnern sowohl eCS als auch Windows 2000 hatte, war ich sehr neugierig, wie es sich mit der Leistung verhielt und ob sich dort signifikante Unterschiede ergeben würden. Wie bei allen anderen Tests mit dem Übertragen von 500-MB-Daten, verwendete ich für Lese- und Schreibzugriffe dieselben physischen Laufwerke und Partitionen auf Home1 und Home2. Obwohl es diverse Dateisysteme gibt, die auf beiden Betriebssystemen verwendet werden können, benutzte ich ausschließlich FAT, da ich befürchtete, daß sich die Messungen ansonsten verfälschen könnten aufgrund von betriebssystemspezifischen Optimierungen für das eine oder andere jeweils bevorzugte Dateisystem. Das erste, was mich dann wirklich überraschte, war, daß ich für das Schreiben von Home1 zu Home2 bei 1 Gbps unter W2K 18,1 Sekunden benötigte und unter eCS 22,1 Sekunden - also satte 18 % Unterschied mit Vorteil für W2K (siehe Abb. 22 und 19). Beim Lesen allerdings (Abb. 23 und 20) waren die Rollen genau umgekehrt: Hier benötigte W2K 25,4 Sekunden, eCS aber nur 19,0 Sekunden - diesmal heftige 35 % Unterschied zum Vorteil von eCS. Ebenfalls ein interessanter Umstand war, daß bei 100 Mbps die Transferzeiten in allen Fällen zwischen 3 % und 9 % langsamer waren als mit eCS. Das Wiederholen der Messungen machte keinen Unterschied!
Basierend auf den Ergebnissen für die Tests mit Übertragungen für eCS/eCS und W2K/W2K war ich gespannt, wie es beim Netzwerktransfer zwischen unterschiedlichen Betriebssystemen aussah, und wie sich das auf den Durchsatz auswirken würde. Auch hier gab es erhebliche Unterschiede.
Abb. 24: Transferzeiten beim Schreiben mit verschiedenen Kombinationen der Betriebssysteme [Großes Bild]
Abb. 25: Transferzeiten beim Lesen mit verschiedenen Kombinationen der Betriebssysteme [Großes Bild]
Ein interessanter Aspekt beim Lesen von Home1 zu Home2 (wie in Abb. 25 zu erkennen) ist, daß eCS zu eCS 25 % schneller ist als W2K zu W2K - ein Vorteil, der sich beim schreibenden Zugriff allerdings auf 5 % reduziert. Auch sehr interessant: Die schnellste Übertragung fand statt bei eCS zu W2K!
FTP ist eines von vielen weiteren Protokollen für den Datentransfer und gilt gemeinhin als effizienter als seine Mitbewerber - aber ist das wirklich wahr? Mit Blick auf die Abbildungen 26 und 27 scheint hier ein Dementi nötig zu sein. Beim schreibenden Zugriff ist FTP nur in einem einzigen Fall schneller als NetBEUI, und beim Lesen ist es grundsätzlich immer langsamer. Was mir auffiel — und ich mir nicht erklären konnte — war der Umstand, daß mit dem GENMAC-Treiber einige der FTP-Zeiten kürzer waren als mit dem neuen GENMAC Wrapper-Treiber, obwohl, wie bereits erwähnt, die Zeiten für NETBEUI ziemlich schlecht waren. Wenn ich allerdings die FTP-Zeiten mit denen für NETBEUI vergleiche (s. Abb. 28) bei der Verbindung von eCS zu W2K, dann sehen die Dinger schon wieder anders aus. Es gibt also kein grundsätzlich schnelleres Protokoll. Ob man also FTP einsetzt oder nicht hängt immer davon ab, was man machen möchte. FTP ist in zwei Geschmacksrichtungen erhältlich: Zum einen im Textmodus als Befehlszeilenprogramm (FTP), zum anderen als GUI-Version (FTPPM). Ein nicht ganz so bekannte (obwohl in verschiedenen Hilfedateien wie den REXX Tips & Tricks oder dem Konfigurationshandbuch zu den Multi-Protokoll Transportdiensten, MPTS, erklärte) Tatsache ist, daß man FTP mittels Skriptdateien steuern kann, wenn es über die Befehlszeile gestartet wird. Um diese Funktionalität einzusetzen, muß man eine Skriptdatei anlegen und deren Namen in einer Umgebungsvariablen namens NETRC speichern.
Zum Beispiel:
Der Name der Skriptdatei lautet d:\usr\keith\script1.rc
SET NETRC=d:\usr\keith\script1.rc
Hier der Inhalt der Datei script1.rc :
machine NETDRIVE login myloginname1 password PW1 macdef machine HOME1 login myloginname1 password PW2 macdef machine HOME3 login myloginname1 password PW3 macdef init binary lcd h:\
Würde ich nun eingebe: FTP XXX (wobei XXX entweder für NETDRIVE, HOME2 oder HOME3 steht), würde mich das obige Skript automatisch mit dem angegebenen Hostrechner verbinden, mit dem entsprechenden Benutzernamen und Paßwort anmelden, den binären Übertragungsmodus einstellen und mein lokales Verzeichnis H:\ wechseln.
Ein weiterer entscheidender Vorteil von FTP ist, daß für Dateien mit einer Größe von mehr als 2 GB (so weit ich weiß) nur eine einzige Methode zu deren Transfer existiert - nämlich eine spezielle Version von FTP eben, die auf Alex Taylors Webseite erhältlich ist (http://www.cs-club.org/~alex/os2/utils/).
Abb. 26: Vergleich von Übertragungszeiten beim Schreiben für die Protokolle FTP und NETBEUI unter eCS [Großes Bild]
Abb. 27: Vergleich von Übertragungszeiten beim Lesen für die Protokolle FTP und NETBEUI unter eCS [Großes Bild]
Abb. 28: Ergebnisse der Transferzeiten für die Protokolle FTP und NETBEUI für Lese- und Schreibzugriffe sortiert nach NETBEUI-Durchsatz
Dieses Diagramm (Abb. 28) beinhaltet sämtliche obigen Daten zusammen mit den Transferzeiten für sowohl FTP als auch NETBEUI. Und hier sind die Meßwerte, die dem Diagramm zugrunde liegen:
| Übertragung | Zeit [s] | CPU + IRQ Last Home 1 NETBUI [%] | IRQ Last Home 1 NETBUI [%] | CPU Last Home 1 NETBUI [%] | CPU + IRQ Last Home 2 NETBUI [%] | IRQ Last Home 2 NETBUI [%] | CPU Last Home 2 NETBUI [%] | FTP [s] |
|---|---|---|---|---|---|---|---|---|
| Home1eCS > Home2W2k1GB | 18.75 | - | - | - | - | - | - | 17.8 |
| Home1eCS < Home2eCS1G | 19.00 | 63 | 26 | 37 | 90 | 26 | 64 | 87.2 |
| Home2eCS > Home1W2k | 19.63 | - | - | - | - | - | - | 23.5 |
| Home2eCS > Home1eCS1G | 19.88 | 60 | 24 | 36 | 96 | 26 | 70 | 21.6 |
| Home2W2k < Home1w2K1GB | 20.00 | 22 | - | 22 | 60 | - | 60 | 19.7 |
| Home1W2k < Home2eCS | 20.00 | 7 | - | 7 | 58 | 8 | 50 | 59 |
| Home1eCS > Home2eCS1GB | 22.13 | 45 | 14 | 31 | 66 | 26 | 40 | 37.3 |
| Home1W2k > Home2w2K1GB | 23.25 | 15 | - | 15 | 30 | - | 30 | 18.3 |
| Home2W2k > Home1w2K1GB | 23.25 | 22 | - | 22 | 60 | - | 60 | 17.3 |
| Home1W2k > Home2eCS | 23.25 | 6 | - | 6 | 54 | 14 | 40 | 23.8 |
| Home1W2k < Home2W2k1GB | 25.38 | 17 | - | 17 | 35 | - | 35 | 19.5 |
| Home1eCS < Home2W2k1GB | 25.50 | - | - | - | - | - | - | 17.5 |
| Home2eCS < Home1eCS1G | 29.00 | 30 | 10 | 20 | 52 | 20 | 32 | 61 |
| Home2eCS < Home1W2k | 29.13 | - | - | - | - | - | - | 21.1 |
| Home2eCS > Home1eCS | 47.13 | 38 | 26 | 12 | 40 | 15 | 25 | 44.9 |
| Home2eCS < Home1eCS(JFS) | 47.88 | 24 | 8 | 16 | 53 | 22 | 31 | - |
| Home2eCS < Home1eCS | 48.13 | 38 | 12 | 26 | 54 | 21 | 33 | 82.2 |
| Home1W2k > Home2W2k | 49.13 | 5 | - | 5 | 6 | - | 6 | 44.3 |
| Home1eCS > Home2W2k | 49.25 | 25 | 7 | 18 | 16 | - | 16 | 44.3 |
| Home1eCS < Home2eCS | 49.63 | 51 | 17 | 34 | 43 | 13 | 30 | 67.9 |
| Home1eCS > Home2eCS | 49.88 | 34 | 9 | 26 | 65 | 24 | 41 | 50.8 |
| Home1eCS < Home2W2k | 50.00 | - | - | - | - | - | - | 45.7 |
| Home2eCS < Home1W2k | 51.25 | 12 | - | 12 | 59 | 31 | 28 | 45.9 |
| Home2W2k > Home1W2k | 51.75 | 11 | - | 11 | 12 | - | 12 | 44.3 |
| Home1W2k < home2W2k | 53.38 | 10 | - | 10 | 15 | - | 15 | 29 |
| Home2W2K < Home1eCS | 53.875 | - | - | - | - | - | - | 49.2 |
| Home2W2K > Home1eCS | 54.63 | - | - | - | - | - | - | 18.7 |
| Home2W2k < Home1W2k | 55.00 | 6 | - | 6 | 24 | - | 24 | 44.4 |
| Home2eCS > Home1W2k | 81.50 | 6 | - | 6 | 32 | 15 | 17 | 44.4 |
| Home2W2K < Home1eCS | 98.13 | - | - | - | - | - | - | 73.2 |
| Home1W2K < Home2eCS | 103.00 | 8 | - | 8 | 31 | 13 | 18 | 67 |
| Home1W2K > Home2eCS | 108.75 | 5 | - | 5 | 11 | 5 | 6 | 53.8 |
| Home2W2K > Home1eCS | 134.75 | 25 | 6 | 19 | 8 | - | 8 | 47.5 |
Wie für alle Tests gilt auch hier, daß es sich um die Ergebnisse mit meinen Rechnern handelt. Andere Systeme können völlig andere Werte liefern. Betrachten Sie also alle diese Ergebnisse mit entsprechender Vorsicht. Falls Sie diese Tests auf Ihren Rechnern nachvollziehen, wäre ich sehr interessiert, Ihre Ergebnisse zu wissen, daher dürfen Sie mich hierfür gerne kontaktieren. (k.merington@gmail.com)
Fazit
Ich vermute daß die abschließende Frage ist, ob sich die Aufrüstung gelohnt hat und sich die dafür ausgegebenen 115 Euro rentiert haben. Zwar brachte es mir nicht die erhoffte zehnfache Übertragungsrate in meinem Netzwerk, aber der Zugriff auf Dateien über mein Netzwerk ist jetzt definitiv schneller und kürzer. Da ich meine regelmäßige Datensicherung auch über das Netzwerk mache — und einige der Dateien sehr groß sind, Fotos, etc. — konnte ich die dafür nötige Zeit drastisch senken. Als Antwort auf meine soeben gestellte Frage kann ich also sagen - ja, ich denke das Geld war gut investiert. Und da fast jeder neue PC (respektive die Mainboards) mittlerweile mit Gigabit-Netzwerkkarten ausgeliefert werden, wäre es die Überlegung wert, auch den Rest meines Netzwerks entsprechend aufzurüsten, um von diesem Leistungsschub Gebrauch zu machen, aber das ist eine Entscheidung, die letzten Endes jeder selber treffen muß.