Kermit21 Geschrieben 6. November 2009 Melden Share Geschrieben 6. November 2009 Hallo, ich habe mir einen teuren 8-Port Switch gegönnt, um meine VOIP-Telefone direkt mit POE betreiben zu können (und nicht für jedes Telefon je ein Netzteil und Steckdose mehr brauche). Es handelt sich um einen Allnet ALL8084. Bisher habe ich immer einen uralten NONAME 8Port Switch genutzt. Problem: Auf der D-Box geht jetzt NFS-Server mäßig nicht mehr viel. Wenn ich im Audioplayer ein mp3-File zur Playlist hinzufügen will (das Browsen in den Verzeichnissen geht noch flüssig wie immer), dauert das ewig (die Box scheint zu hängen). Nach ~1 Minute sehe ich dann das File in der Playlist und kann es wie gewohnt abspielen. Wenn ich aber im Movieplayer ein TS abspielen will, so klappt das gar nicht: Minutenlang schwarzes Bild, dann höchstens mal kurz ein paar Sekunden des Videos (irgendwo mitten drin), dann "Puffern", usw. Wie kann das sein, dass so ein moderner, teurer Switch offenbar nicht mehr vernünftig mit 10BaseT Halfduplex umgehen kann? Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
merkwuerden Geschrieben 6. November 2009 Melden Share Geschrieben 6. November 2009 Wie kann das sein, dass so ein moderner, teurer Switch offenbar nicht mehr vernünftig mit 10BaseT Halfduplex umgehen kann? Keine Ahnung. Bei Deinen umfangreichen Informationen zum Aufbau Deines Netzwerkes, verwendeter NFS-Server (auf welcher Hardware der läuft, Software-Version), Konfiguration der NFS-Hardware (Geschwindigkeit/Duplex-Mode) Konfiguration der NFS-Optionen auf der dBox2 usw. erklärt Dir das höchstens der Hellseher Deines Vertrauens. Ich behaupte aber mal einfach so, dass es nicht am Switch liegt. Führe den Netzwerk Geschwindigkeitstest NFS durch und poste das Ergebnis hier. Und mache entsprechende Angaben zu Deinem Netzwerk, dann sehen wir weiter. Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
Kermit21 Geschrieben 7. November 2009 Autor Melden Share Geschrieben 7. November 2009 Ich behaupte aber mal einfach so, dass es nicht am Switch liegt. Führe den Netzwerk Geschwindigkeitstest NFS durch und poste das Ergebnis hier. Und mache entsprechende Angaben zu Deinem Netzwerk, dann sehen wir weiter. Es liegt definitiv am Switch! Ich habe hier beide parallel laufen und kann "on-the-fly" die Patchkabel umstecken. Bei meinem alten Switch geht es und bei dem neuen eben definitiv nicht mehr. Allerdings habe ich den neuen Switch nun auch zum Laufen bekommen: Ich habe die NFS-Blockgröße (wsize,rsize mount optionen) runtergesetzt: Bei meinem alten Switch lief alles mit 32K problemlos. Bei dem neuen treten o.g. Probleme auf, die eine sinnvolle Nutzung unmöglich machen. Stelle ich die Blockgröße auf 8K zurück (was beim KW-Image ja default ist), kann ich wieder problemlos meine TS-Files ansehen und ohne Verzögerung mp3-Files im Audioplayer hinzufügen. Trotzdem verstehe ich nicht, warum so ein moderner Switch nicht mehr mit 32K-Blocks umgehen kann. Beide Switche nutzen Store&Forward. Hat der neue Switch eventuell höhere Latenzzeiten? Wenn ich die Blockgröße hinabsetze, habe ich ja mehr Protokoll Overhead und folglich eine etwas niedrigere Netto-Übertragungsrate. Kann man also sagen, dass der teure, neue Switch schlechter ist als der billige alte? Ich werde mir gleich mal den genannten Speedtest vornehmen. Vielen Dank, Kermit NACHTRAG: So, habe den Speedtest mal laufen lassen. Die Zwischenschritte (wie 6144, 9216, 10240 usw.) machen keinen Sinn, weil bei der Mount-Anzeige immer der niedrigere "gerade" Wert angezeigt wird und die Werte auch diesem entsprechen. Also habe ich die Werte dann aus dem Script rausgeworfen. Hier das erschreckende Ergebnis: alter Switch: Noname 4096, 4096 6481 6481 8192, 8192 7757 6918 16384, 16384 8258 7314 32768, 32768 8677 7211 neuer Switch: Allnet ALL8084 4096, 4096 6481 6095 8192, 8192 7641 5446 16384, 16384 8126 723 32768, 32768 8533 nach ~30min abgebrochen Einzeltest mit rsize=32768,wsize=4096 8533 5953 Mit der Einstellung muss ich wohl erst mal leben. Bis jetzt kann ich scheinbar alle meiner aufgenommen TS-Streams problemlos abspielen. Habe bisher aber auch keine mit mehreren Audio-Spuren oder gar 5.1 AC3-Spur. Spielfilme nehme ich eh so gut wie nie auf, sondern nur Dokus und wenn ich nicht zu Hause bin auch manchmal die Folge einer TV-Serien. Und die Schreibwerte sind ja ganz ordentlich. So sollte das Aufnehmen zumindest relativ sicher klappen (bisher noch nicht getestet mit dem neuen Switch) Trotzdem verstehe ich nicht, wie die Lesegeschwindigkeit bei einem so modernen Switch so rapide einbrechen kann. Der collision counter des Interfaces (den man mit ifconfig betrachten kann) steigt bei höheren rsize-Werten langsam an! Wie kann das sein? Wie kann es bei einem Switch mit Store&Forward und strenger Sterntopologie überhaut zu Kollisionen kommen? Das DARF doch gar nicht mehr passieren? Ich vermute fast, dass es mit dieser MDI/MDIX-Scheiße zusammenhängt, die der neue Switch macht. Vielleicht würde tcpdump auf Box und Server Aufschluss bringen, aber der Zeitaufwand ist mir das jetzt nicht wert. Ich hoffe, dass in den nächsten 1-2 Jahren die D-Boxen bei mir eh ausgedient haben und durch eine moderne Settopbox mit 100BaseT Fullduplex-Interface ersetzt werden. Auf eine solche Box mit Neutrino, bzw. ein Neutrino für die Dreamboxen warte ich immer noch. Die Coolstream HD1 könnte mir fast schon gefallen, aber solange es keine Sourcen gibt, lasse ich erst mal die Finger davon. Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
merkwuerden Geschrieben 7. November 2009 Melden Share Geschrieben 7. November 2009 Diese Information NFS-Hardware (Geschwindigkeit/Duplex-Mode) fehlt noch immer. Ich weise nicht zum Spaß darauf hin. Nach Deinen Werten zu urteilen läuft die NIC des NFS-Servers im FullDuplex Mode. Die dBox2 kann ohne Hardwaremodifikation und managebaren Switch kein FullDuplex. Und den Mischbetrieb Half/Full im UDP-Protokoll mit der dBox2 können sehr viele Switches nicht ab, brechen dann bei höheren Blocksizes in der Richtung Server -> Box komplett zusammen und bringen keine oder nur noch tröpfchenweise Daten durch. In der Richtung Box -> Server dagegen spielt das keine Rolle. Haben meine Switches auch ihre Probleme, noName-Digitus und Linksys EZXS88W, letzterer ist kein Billigteil. Wobei der Digitus da erst bei rsize ab 8192 einbricht, der Linksys dagegen bricht schon bei 4096 zusammen und lässt nur noch ca. 700 durch. Bei NIC des Servers fest auf HalfDuplex dagegen laufen 8200 bei beiden Switches durch. Jeder Switch reagiert da allgemein anders. auf Mischbetrieb. Stelle die NIC des Servers fest auf 100 HalfDuplex, dann ist das Problem normal beseitigt. Hilft das nicht, taugt der Switch wohl doch nicht viel. Dann kannst Du aber zumindest noch eines machen: zum Lesen vom NFS auf die Box einen separaten Mount anlegen mit Protokoll TCP. Achtung: keinesfalls den selben Mountpunkt auf der Box doppelt mounten, das geht nach hinten los! Also entweder getrennte Mountpunkte für UDP und TCP verwenden oder den protokollmäßig nicht benötigten Mount erst unmounten, bevor Du das andere Protokoll mountest. Andernfalls bekommst Du Scherereien. TCP ist des Problems bezüglich unempfindlich, allerdings im Durchsatz langsamer wegen erheblich höherem Protokolloverhead, was dann bei der auf 10Mbit begrenzten Schnittstelle der dBox2 hinten und vorne fehlt, wenn hohe Bitraten ins Spiel kommen. Trotzdem solltest Du mit rsize=32768 und TCP höheren Durchsatz erreichen als mit 8192 bzw. 4096 und UDP. Ich erreiche damit über meinen Linksys Lesewerte von ca. 7600. Für ARD/ZDF-Aufnahmen dürfte das allerdings zu wenig zum Abspielen sein. Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
Kermit21 Geschrieben 7. November 2009 Autor Melden Share Geschrieben 7. November 2009 Ich erreiche damit über meinen Linksys Lesewerte von ca. 7600. Für ARD/ZDF-Aufnahmen dürfte das allerdings zu wenig zum Abspielen sein. Du hast leider recht . Habe versucht mit einige ARD/ZDF Sendungen abzuspielen. Es kommt immer mal wieder ein "Puffern" (Haben die Transponder auf Hotbird eigentlich die gleichen Datenrate? Sonst nehme ich in Zukunft von da auf). Also meine UDP Lesewerte von 5500-6000 reichen folglich tatsächlich nicht aus zum Abspielen Zwei separate Mountpoints mit UDP und TCP sollten ja kein Problem sein: Der UDP-Mount nur zum Aufnehmen und der TCP-Mount zum Abspielen. Mal schauen, ob dann meine ARD Sendungen laufen. Meine NFS Hardware ist mein Homeserver: Ein P3 500MHz mit zwei Intel Corporation 8255X Ethernet Pro 100. NFS-SW ist der gängige Kernel Space Server (Version 1.1.2) An einer Karte hängt nur das DSL-Modem. An der anderen Karte eben der Switch mit 3 VOIP-Telefonen, bis zu 3 weiteren Rechnern (davon ein Notebook indirekt am integrieten Switch eines VOIP-Telefons) und 2 Dboxen. Würde die Karte deshalb ungern auf Halbduplex kastrieren. Werde es aber gleich mal testweise probieren, insbesondere ob sich das eventuell negativ auf VOIP-Gespräche auswirkt. Nicht dass ich dann die gleiche Scheiße umgekehrt habe: VOIP-Telefone laufen in Vollduplex und der Server nur noch in Halbduplex über den Switch... NACHTRAG: Also mit TCP und rsize=32768 kriege ich Lesewerte von ~6500. Viel schneller ist das auch nicht. Aber meine ARD-Aufnahme lief nun zumindest einige Minuten ohne zu puffern (habe aus Zeitgründen den Test abgebrochen). Befriedigend ist das nicht wirklich. Habe die NIC nun auch mal probeweise auf 100MBit Halbduplex umgestellt und mit 32768 UDP gemountet => Auch nur ~5000 Lesewert. Das bringt es also leider auch nicht NACHTRAG2: Habe nun den NIC testweise auf nur 10MBit Halbduplex gesetzt. Lesewert: 8258 Aber 10MBit ist absolut unzumutbar! Ich befürchte, dass der Switch wohl einfach teurer Schrott ist! NACHTRAG3: Würde es eventuell etwas bringen, die Box auf Fullduplex umzubauen? http://wiki.tuxbox.org/wiki/index.php/FullDuplexUmbau Wie ich das sehe, ist dazu nur eine Lötbrücke gegen Masse notwendig. Andererseits scheint das Problem weniger am Fullduplex, sondern an den unterschiedlichen Datenraten zu liegen? Die Daten zur Box kommen wahrscheinlich zu schnell und der Switch verwirft die Pakete einfache, die nicht mehr in seinem Buffer passen? Da bringt Fullduplex wohl auch nicht viel? Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
merkwuerden Geschrieben 7. November 2009 Melden Share Geschrieben 7. November 2009 Würde die Karte deshalb ungern auf Halbduplex kastrieren. Du hast aber keine andere Chance. Entweder HalfDuplex, dann kriegst Du zwischen Server und Box auch ordentliche Datenraten, oder eben FullDuplex mit Deinen mistigen Leseraten. Billigste Möglichkeit: noch eine Netzwerkkarte für die dBox einbauen (ich empfehle Dir da eine Realtek 100Mbit, z.B. die RTL8139C oder D), diese auf HalfDuplex und die Box da ran, Deinen alten Switch dazwischen, damit Du die NIC mit 100 Half fahren kannst, bringt erfahrungsgemäß mehr als 10 Half per Crossover. Teuerste Möglichkeit: einen managebaren Switch anschaffen, der erstens sich für den dBox-Port fest auf 10 FullDuplex einstellen lässt (Box muss dazu aber auch umgebaut werden) und zweitens die Eigenschaften hat, die Du für Dein VOIP benötigst. Ob's das wert ist... Habe die NIC nun auch mal probeweise auf 100MBit Halbduplex umgestellt und mit 32768 UDP gemountet => Auch nur ~5000 Lesewert. Das bringt es also leider auch nicht Sollte der Allnet-Switch wirklich so mistig sein? Gut, wenn ich mir überlege, was die z.B. mit ihrem All6200 NAS für Schrott gebaut haben, wundert mich das fast nicht. Wenn Du ordentliche Netzwerktechnik haben willst: investiere in Cisco (Linksys). Das ist wirklich Qualität, da bezahlt man nicht nur den Namen (und bekommt dann Schrott dafür). Habe nun den NIC testweise auf nur 10MBit Halbduplex gesetzt. Lesewert: 8258 Aber 10MBit ist absolut unzumutbar! Ich befürchte, dass der Switch wohl einfach teurer Schrott ist! Sehe ich jetzt genau so. 10Mbit funktioniert, 100 nicht brauchbar - schau zu, dass Du das Scheißteil wieder los wirst. Empfehlung für Ersatz hab ich Dir grade gegeben. Weiß jetzt allerdings nicht, ob die auch irgendwas für Dein POE haben, mit solchem Zeugs kenne ich mich leider nicht aus. Würde es eventuell etwas bringen, die Box auf Fullduplex umzubauen? Wie ich das sehe, ist dazu nur eine Lötbrücke gegen Masse notwendig. Und ein passendes Image, das die Box auf FullDuplex beim Booten einstellt (aktuelles KW-Image kann das auf jeden Fall, ich weiß aber nicht ab welcher Version die älteren Images das unterstützen). Das allein reicht aber nicht! Da der Netzwerkchip der dBox kein Autonegotiation kann, würde der Switch weiterhin auf HalfDuplex bleiben, die Box aber auf Full laufen - dann geht überhaupt nichts mehr. Wie oben schon geschrieben: Du bräuchtest dann zwingend einen managebaren Switch, wo sich die einzelnen Ports separat konfigurieren lassen - den dBox-Port fest auf 10 Full setzen. So ein managebarer Switch ist nicht billig. Oder eine separate Netzwerkkarte im Server, die fest auf 10 Full gesetzt wird, die Box dann direkt da ran. Letzteres die deutlich billigere Lösung. Muß halt der Server laufen, wenn die Box sich mit dem Rest des Netzwerkes unterhalten soll. Andererseits scheint das Problem weniger am Fullduplex, sondern an den unterschiedlichen Datenraten zu liegen? Eher nicht. Wäre das die Regel, würde der Mischbetrieb 10/100 wohl überhaupt nicht funktionieren - auch nicht in "normalen" Netzwerken ohne dBox2. Die Daten zur Box kommen wahrscheinlich zu schnell und der Switch verwirft die Pakete einfache, die nicht mehr in seinem Buffer passen? Sowas kann eigentlich nur passieren, wenn der Switch zu dämlich ist, seine Arbeit vorschriftsmäßig zu machen. Normalvorgang ist Daten vom Server entgegen nehmen - der Box sagen "ich hab was für Dich" - Box holt Daten ab (oder auch nicht) - Switch wartet auf jeden Fall, bis die Box sagt "fertig, kannst die nächsten Daten bringen" - Switch sagt dann erst dem Server Bescheid, dass er die nächsten Daten bringen kann. Beim HalfDuplex muss halt da gewartet werden, da die Leitung entweder senden oder empfangen kann, bei FullDuplex stehen Senden und Empfang gleichzeitig zur Verfügung. Aber einfach fleißig Daten abnehmen und im Zweifelsfall blind ins Nirvana schicken (weil der Empfänger zu langsam ist oder gar nicht reagiert) - frei nach dem Motto "hat sich für mich erledigt" ist nicht. Damit würde kein einziges Netzwerk funktionieren... Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
Kermit21 Geschrieben 7. November 2009 Autor Melden Share Geschrieben 7. November 2009 Billigste Möglichkeit: noch eine Netzwerkkarte für die dBox einbauen (ich empfehle Dir da eine Realtek 100Mbit, z.B. die RTL8139C oder D), diese auf HalfDuplex und die Box da ran, Deinen alten Switch dazwischen, damit Du die NIC mit 100 Half fahren kannst, bringt erfahrungsgemäß mehr als 10 Half per Crossover. Dann kann ich wohl den alten Switch einfach zwischen den neuen und den D-Boxen schalten. NACHTRAG: Klappt so nicht: NFS-Server - neuer Switch - alter Switch - D-Box: UDP 32768 -> Schreibwert 8677, Lesewert nach knapp 4 Minuten: 2255. Immerhin! Jetzt geht zumindest etwas, wo vorher nach über 30Minuten noch kein Wert kam Aber umgekehrt geht's! NFS-Server - alter Switch - neuer Switch - D-Box: Schreibwert 8533, Lesewert 7757 Irgendwie seltsam: Die Verbindung zwischen beiden Switches ist 100MBit FD. Die Umsetzung auf 10MBit HD macht also der neue Switch, der alleine nichts taugt. Teuerste Möglichkeit: einen managebaren Switch anschaffen, der erstens sich für den dBox-Port fest auf 10 FullDuplex einstellen lässt (Box muss dazu aber auch umgebaut werden) und zweitens die Eigenschaften hat, die Du für Dein VOIP benötigst. Ob's das wert ist... Ich habe noch einen 3com Superstack III mit 24Port im Keller rum stehen. Aber ich will gar nicht wissen, was der Strom verbraucht. Ausserdem kann der auch kein POE Sollte der Allnet-Switch wirklich so mistig sein? Gut, wenn ich mir überlege, was die z.B. mit ihrem All6200 NAS für Schrott gebaut haben, wundert mich das fast nicht. Wenn Du ordentliche Netzwerktechnik haben willst: investiere in Cisco (Linksys). Das ist wirklich Qualität, da bezahlt man nicht nur den Namen (und bekommt dann Schrott dafür). Wenn es da einen guten und nicht allzu teuren mit POE gäbe, dann würde ich den ja nehmen. Und ein passendes Image, das die Box auf FullDuplex beim Booten einstellt (aktuelles KW-Image kann das auf jeden Fall, ich weiß aber nicht ab welcher Version die älteren Images das unterstützen). Das allein reicht aber nicht! Da der Netzwerkchip der dBox kein Autonegotiation kann, würde der Switch weiterhin auf HalfDuplex bleiben, die Box aber auf Full laufen - dann geht überhaupt nichts mehr. Ja, habe ich gerade festgestellt. Habe die Brücke eingelötet und den Treiber (wohl nur ein Kernelparameter?) eingeschaltet und neugestartet. Schneller ist nichts geworden (weder UDP noch TCP). Nur stürzen offenbar die Testprogramme mitten drin sporadisch ab: dd: /mnt/test: Input/output error Command exited with non-zero status 1 Wie oben schon geschrieben: Du bräuchtest dann zwingend einen managebaren Switch, wo sich die einzelnen Ports separat konfigurieren lassen - den dBox-Port fest auf 10 Full setzen. So ein managebarer Switch ist nicht billig. Oder eine separate Netzwerkkarte im Server, die fest auf 10 Full gesetzt wird, die Box dann direkt da ran. Letzteres die deutlich billigere Lösung. Muß halt der Server laufen, wenn die Box sich mit dem Rest des Netzwerkes unterhalten soll. Das ist alles unbefriedigend. Ich habe 2 Boxen, also müsste ich noch 2 Karten einbauen. Wenn ich meinen alten Switch nehme würde, würde es eventuell schon reichen den zwischen zu schalten ohne zusätzliche Karten. Aber den Stromverbrauch möchte ich gerne vermeiden. Der Neue Switch verbrauch 2W weniger als der alte! Beide zusammen wäre overkill. Und nur bei Bedarf einschalten wäre mir auch zu nervig. Bevor ich in neue Netzwerk-HW inverstiere, denke ich eher über eine neue Settopbox nach. Eher nicht. Wäre das die Regel, würde der Mischbetrieb 10/100 wohl überhaupt nicht funktionieren - auch nicht in "normalen" Netzwerken ohne dBox2. Sowas kann eigentlich nur passieren, wenn der Switch zu dämlich ist, seine Arbeit vorschriftsmäßig zu machen. Normalvorgang ist Daten vom Server entgegen nehmen - der Box sagen "ich hab was für Dich" - Box holt Daten ab (oder auch nicht) - Switch wartet auf jeden Fall, bis die Box sagt "fertig, kannst die nächsten Daten bringen" - Switch sagt dann erst dem Server Bescheid, dass er die nächsten Daten bringen kann. Beim HalfDuplex muss halt da gewartet werden, da die Leitung entweder senden oder empfangen kann, bei FullDuplex stehen Senden und Empfang gleichzeitig zur Verfügung. Aber einfach fleißig Daten abnehmen und im Zweifelsfall blind ins Nirvana schicken (weil der Empfänger zu langsam ist oder gar nicht reagiert) - frei nach dem Motto "hat sich für mich erledigt" ist nicht. Damit würde kein einziges Netzwerk funktionieren... Sicher? Wie kann der Switch auf MAC-Ebene (Layer2) den ein "Warten" an den 100MBit Server zurücksenden? Normalerweise muss der Puffer voll laufen und sich bei UDP der NFS-Client um nachforderung der verlorenen, bzw. fehlerhaften Segmente kümmern. Bei TCP müsste das eben das TCP-Protokoll aus dem TCP/IP-Stack der Box das nachfordern übernehmen (und die Window-Size auf den Switchbuffer optimieren!)? Ich vermute, dass da eher der Fehler liegt: Der Switch kriegt nicht genug UDP-Segmente (in 1500byte große MAC-Frames geteilt) in den Puffer um den 32K-Block vollständig zusammen zu bauen, bzw. der NFS-Client fordert zu viele auf einmal an. TCP fordert die kaputten Segmente ja selbstständig wieder nach und kann das offenbar besser als der NFS-Client bei UDP. Vielleicht hat mein alter Switch einfach ein größeren Framebuffer. NACHTRAG: Auf Layer2 gibt es wohl tatsächlich auch ein Flow Control. In Ethernet ist ein PAUSE frame implementiert. Das scheint in dem neuen Switch dann wohl mangelhaft (wenn überhaupt?) implementiert zu sein: http://en.wikipedia.org/wiki/Ethernet_flow_control Ich lerne auch nach Jahren Netzwerktechnik immer wieder was neues Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
Kermit21 Geschrieben 7. November 2009 Autor Melden Share Geschrieben 7. November 2009 So, hab mal ein Wireshark Log zwischen NFS-Server und den Switchen erstellt im Lesemodus der Dbox mit rsize=32768: Ich vermute, dass der neue Switch tatsächlich gerne mal ein paar Frames "verschluckt" wenn der Buffer voll wird, bzw. die PAUSE-Frames zu spät sendet: Dort gibt es nämlich viel öfter "RPC retransmissions" NFS-Server <=> Switch Alt <=> Dbox No. Time Source Destination Protocol Info 74 5.271925 DBOX NFS-SERVER NFS V3 READ Call (Reply In 98), FH:0x059402ab Offset:45056 Len:32768 75 5.272251 NFS-SERVER DBOX IP Fragmented IP protocol (proto=UDP 0x11, off=0, ID=306a) [Reassembled in #98] 76 5.272610 NFS-SERVER DBOX IP Fragmented IP protocol (proto=UDP 0x11, off=1480, ID=306a) [Reassembled in #98] 77 5.272636 NFS-SERVER DBOX IP Fragmented IP protocol (proto=UDP 0x11, off=2960, ID=306a) [Reassembled in #98] ... ... 94 5.273423 NFS-SERVER DBOX IP Fragmented IP protocol (proto=UDP 0x11, off=28120, ID=306a) [Reassembled in #98] 95 5.273515 NFS-SERVER DBOX IP Fragmented IP protocol (proto=UDP 0x11, off=29600, ID=306a) [Reassembled in #98] 96 5.273537 01:f3:15:12:34:56 Spanning-tree-(for-bridges)_01 CTRL MAC PAUSE: Quanta 65535 97 5.273572 NFS-SERVER DBOX IP Fragmented IP protocol (proto=UDP 0x11, off=31080, ID=306a) [Reassembled in #98] 98 5.273587 NFS-SERVER DBOX NFS V3 READ Reply (Call In 74) Len:32768 99 5.297030 01:f3:15:12:34:56 Spanning-tree-(for-bridges)_01 CTRL MAC PAUSE: Quanta 0 100 5.303732 DBOX NFS-SERVER NFS V3 READ Call (Reply In 124), FH:0x059402ab Offset:77824 Len:32768 101 5.304244 NFS-SERVER DBOX IP Fragmented IP protocol (proto=UDP 0x11, off=0, ID=306b) [Reassembled in #124] 102 5.304277 NFS-SERVER DBOX IP Fragmented IP protocol (proto=UDP 0x11, off=1480, ID=306b) [Reassembled in #124] 103 5.304294 NFS-SERVER DBOX IP Fragmented IP protocol (proto=UDP 0x11, off=2960, ID=306b) [Reassembled in #124] ... ... 123 5.305295 01:f3:15:12:34:56 Spanning-tree-(for-bridges)_01 CTRL MAC PAUSE: Quanta 65535 124 5.305376 NFS-SERVER DBOX NFS V3 READ Reply (Call In 100) Len:32768 125 5.305869 DBOX NFS-SERVER NFS V3 READ Call (Reply In 148), FH:0x059402ab Offset:110592 Len:32768 126 5.306190 NFS-SERVER DBOX IP Fragmented IP protocol (proto=UDP 0x11, off=0, ID=306c) [Reassembled in #148] 127 5.306215 NFS-SERVER DBOX IP Fragmented IP protocol (proto=UDP 0x11, off=1480, ID=306c) [Reassembled in #148] 128 5.306512 NFS-SERVER DBOX IP Fragmented IP protocol (proto=UDP 0x11, off=2960, ID=306c) [Reassembled in #148] ... ... 148 5.307438 NFS-SERVER DBOX NFS V3 READ Reply (Call In 125) Len:32768 149 5.357034 01:f3:15:12:34:56 Spanning-tree-(for-bridges)_01 CTRL MAC PAUSE: Quanta 0 150 5.360167 DBOX NFS-SERVER NFS V3 READ Call (Reply In 175), FH:0x059402ab Offset:143360 Len:32768 151 5.360304 DBOX NFS-SERVER NFS V3 READ Call (Reply In 198), FH:0x059402ab Offset:176128 Len:32768 152 5.360457 NFS-SERVER DBOX IP Fragmented IP protocol (proto=UDP 0x11, off=0, ID=306d) [Reassembled in #175] 153 5.360798 NFS-SERVER DBOX IP Fragmented IP protocol (proto=UDP 0x11, off=1480, ID=306d) [Reassembled in #175] 154 5.360822 NFS-SERVER DBOX IP Fragmented IP protocol (proto=UDP 0x11, off=2960, ID=306d) [Reassembled in #175] ... ... 173 5.361726 01:f3:15:12:34:56 Spanning-tree-(for-bridges)_01 CTRL MAC PAUSE: Quanta 65535 174 5.361760 NFS-SERVER DBOX IP Fragmented IP protocol (proto=UDP 0x11, off=31080, ID=306d) [Reassembled in #175] 175 5.361872 NFS-SERVER DBOX NFS V3 READ Reply (Call In 150) Len:32768 176 5.362046 NFS-SERVER DBOX IP Fragmented IP protocol (proto=UDP 0x11, off=0, ID=306e) [Reassembled in #198] 177 5.362067 NFS-SERVER DBOX IP Fragmented IP protocol (proto=UDP 0x11, off=1480, ID=306e) [Reassembled in #198] 178 5.362084 NFS-SERVER DBOX IP Fragmented IP protocol (proto=UDP 0x11, off=2960, ID=306e) [Reassembled in #198] ... ... 198 5.363146 NFS-SERVER DBOX NFS V3 READ Reply (Call In 151) Len:32768 199 5.413222 01:f3:15:12:34:56 Spanning-tree-(for-bridges)_01 CTRL MAC PAUSE: Quanta 0 200 5.425978 DBOX NFS-SERVER NFS V3 READ Call (Reply In 227), FH:0x059402ab Offset:208896 Len:32768 201 5.426121 DBOX NFS-SERVER NFS V3 READ Call (Reply In 250), FH:0x059402ab Offset:241664 Len:32768 202 5.426246 NFS-SERVER DBOX IP Fragmented IP protocol (proto=UDP 0x11, off=0, ID=306f) [Reassembled in #227] 203 5.426272 DBOX NFS-SERVER NFS V3 READ Call (Reply In 273), FH:0x059402ab Offset:274432 Len:32768 204 5.426426 DBOX NFS-SERVER NFS V3 READ Call (Reply In 296), FH:0x059402ab Offset:307200 Len:32768 205 5.426607 NFS-SERVER DBOX IP Fragmented IP protocol (proto=UDP 0x11, off=1480, ID=306f) [Reassembled in #227] 206 5.426629 NFS-SERVER DBOX IP Fragmented IP protocol (proto=UDP 0x11, off=2960, ID=306f) [Reassembled in #227] 207 5.426648 NFS-SERVER DBOX IP Fragmented IP protocol (proto=UDP 0x11, off=4440, ID=306f) [Reassembled in #227] ... ... 224 5.427527 01:f3:15:12:34:56 Spanning-tree-(for-bridges)_01 CTRL MAC PAUSE: Quanta 65535 225 5.427593 NFS-SERVER DBOX IP Fragmented IP protocol (proto=UDP 0x11, off=29600, ID=306f) [Reassembled in #227] 226 5.427612 NFS-SERVER DBOX IP Fragmented IP protocol (proto=UDP 0x11, off=31080, ID=306f) [Reassembled in #227] 227 5.427626 NFS-SERVER DBOX NFS V3 READ Reply (Call In 200) Len:32768 228 5.427880 NFS-SERVER DBOX IP Fragmented IP protocol (proto=UDP 0x11, off=0, ID=3070) [Reassembled in #250] 229 5.427910 NFS-SERVER DBOX IP Fragmented IP protocol (proto=UDP 0x11, off=1480, ID=3070) [Reassembled in #250] 230 5.427927 NFS-SERVER DBOX IP Fragmented IP protocol (proto=UDP 0x11, off=2960, ID=3070) [Reassembled in #250] ... ... 297 5.533674 01:f3:15:12:34:56 Spanning-tree-(for-bridges)_01 CTRL MAC PAUSE: Quanta 0 298 5.547214 DBOX NFS-SERVER NFS V3 READ Call (Reply In 326), FH:0x059402ab Offset:339968 Len:32768 299 5.547334 DBOX NFS-SERVER NFS V3 READ Call (Reply In 349), FH:0x059402ab Offset:372736 Len:32768 300 5.547485 DBOX NFS-SERVER NFS V3 READ Call (Reply In 372), FH:0x059402ab Offset:405504 Len:32768 301 5.547639 DBOX NFS-SERVER NFS V3 READ Call (Reply In 395), FH:0x059402ab Offset:438272 Len:32768 302 5.547792 DBOX NFS-SERVER NFS V3 READ Call (Reply In 418), FH:0x059402ab Offset:471040 Len:32768 303 5.548068 NFS-SERVER DBOX IP Fragmented IP protocol (proto=UDP 0x11, off=0, ID=3073) [Reassembled in #326] 304 5.548094 NFS-SERVER DBOX IP Fragmented IP protocol (proto=UDP 0x11, off=1480, ID=3073) [Reassembled in #326] 305 5.548111 NFS-SERVER DBOX IP Fragmented IP protocol (proto=UDP 0x11, off=2960, ID=3073) [Reassembled in #326] ... ... 324 5.549116 01:f3:15:12:34:56 Spanning-tree-(for-bridges)_01 CTRL MAC PAUSE: Quanta 65535 NFS-Server <=> Switch neu (ALL8084) <=> Dbox No. Time Source Destination Protocol Info 47 7.489426 DBOX NFS-SERVER NFS V3 READ Call (Reply In 67), FH:0x059402ab Offset:16384 Len:28672 48 7.489650 NFS-SERVER DBOX IP Fragmented IP protocol (proto=UDP 0x11, off=0, ID=1758) [Reassembled in #67] 49 7.489674 NFS-SERVER DBOX IP Fragmented IP protocol (proto=UDP 0x11, off=1480, ID=1758) [Reassembled in #67] 50 7.489693 NFS-SERVER DBOX IP Fragmented IP protocol (proto=UDP 0x11, off=2960, ID=1758) [Reassembled in #67] ... ... 67 7.490207 NFS-SERVER DBOX NFS V3 READ Reply (Call In 47) Len:28672 68 7.492112 Novell20_78:9A:BC Spanning-tree-(for-bridges)_01 CTRL MAC PAUSE: Quanta 65535 69 7.504712 Novell20_78:9A:BC Spanning-tree-(for-bridges)_01 CTRL MAC PAUSE: Quanta 0 70 7.518032 DBOX NFS-SERVER NFS V3 READ Call (Reply In 93), FH:0x059402ab Offset:45056 Len:32768 71 7.518383 NFS-SERVER DBOX IP Fragmented IP protocol (proto=UDP 0x11, off=0, ID=1759) [Reassembled in #93] 72 7.518407 NFS-SERVER DBOX IP Fragmented IP protocol (proto=UDP 0x11, off=1480, ID=1759) [Reassembled in #93] 73 7.518632 NFS-SERVER DBOX IP Fragmented IP protocol (proto=UDP 0x11, off=2960, ID=1759) [Reassembled in #93] ... ... 93 7.519276 NFS-SERVER DBOX NFS V3 READ Reply (Call In 70) Len:32768 94 7.520904 Novell20_78:9A:BC Spanning-tree-(for-bridges)_01 CTRL MAC PAUSE: Quanta 65535 95 7.536514 Novell20_78:9A:BC Spanning-tree-(for-bridges)_01 CTRL MAC PAUSE: Quanta 0 96 8.786623 DBOX NFS-SERVER NFS [RPC retransmission of #70]V3 READ Call (Reply In 93), FH:0x059402ab Offset:45056 Len:32768 97 8.786868 NFS-SERVER DBOX IP Fragmented IP protocol (proto=UDP 0x11, off=0, ID=175a) [Reassembled in #119] 98 8.786891 NFS-SERVER DBOX IP Fragmented IP protocol (proto=UDP 0x11, off=1480, ID=175a) [Reassembled in #119] ... ... 120 8.789385 Novell20_78:9A:BC Spanning-tree-(for-bridges)_01 CTRL MAC PAUSE: Quanta 65535 121 8.804996 Novell20_78:9A:BC Spanning-tree-(for-bridges)_01 CTRL MAC PAUSE: Quanta 0 122 11.328814 DBOX NFS-SERVER NFS [RPC retransmission of #70]V3 READ Call (Reply In 93), FH:0x059402ab Offset:45056 Len:32768 123 11.329035 NFS-SERVER DBOX IP Fragmented IP protocol (proto=UDP 0x11, off=0, ID=175b) [Reassembled in #145] 124 11.329059 NFS-SERVER DBOX IP Fragmented IP protocol (proto=UDP 0x11, off=1480, ID=175b) [Reassembled in #145] 125 11.329078 NFS-SERVER DBOX IP Fragmented IP protocol (proto=UDP 0x11, off=2960, ID=175b) [Reassembled in #145] ... ... 145 11.329619 NFS-SERVER DBOX NFS [RPC duplicate of #93]V3 READ Reply (Call In 70) Len:32768 146 11.331553 Novell20_78:9A:BC Spanning-tree-(for-bridges)_01 CTRL MAC PAUSE: Quanta 65535 147 11.347155 Novell20_78:9A:BC Spanning-tree-(for-bridges)_01 CTRL MAC PAUSE: Quanta 0 148 16.413195 DBOX NFS-SERVER NFS [RPC retransmission of #70]V3 READ Call (Reply In 93), FH:0x059402ab Offset:45056 Len:32768 Überlege nun, ob ich den Switch wieder verkaufen oder damit leben soll. Eigentlich habe ich vor die DBoxen schon noch ein paar Jahre zu nutzen. Wenn aber morgen "die revoltionäre Neutrino-Box" auf dem Markt kommt oder auch nur der Source der Coolstream HD1 veröffentlicht wird, könnte sich das ganz schnell ändern... Habe meinen alten Switch mal auseinander genommen. Dort sind jede Menge Chips drin (vier Stück) und die Platine ist wirklich voll mit SMD Bauteilen im Gegensatz zu dem neuen Switch. Unten an der Platine komme ich aber frei an die Löt-Kontakte der RJ45-Jacks. Da könnte ich eventuell auch einfach eine externe Spannungsquelle für POE anlöten. Bräuchte dann aber natürlich ein zweites Netzteil. Wenn es ein gutes Schaltnetzteil ist, ist das vom Stromverbrauch her vielleicht machbar... Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
Kermit21 Geschrieben 8. November 2009 Autor Melden Share Geschrieben 8. November 2009 Habe jetzt wieder eine Idee, wie man das doch noch hinbekommen kann. Ich fasse mal die Resultate zusammen: - Schalte ich das Interface des NFS-Servers auf 10BaseT HD, so funktioniert es bestens (LeseWert ~8000) über den neuen Switch - Schalte ich den alten Switch zwischen PC und neuen Switch, so funktioniert es auch bestens! Ziel: 1. Alter Switch soll definitiv WEG 2. NFS-Server soll mit 100BaseT FS am Switch laufen, die Frames für die D-Box aber nur so aussenden, als wenn sie im 10BaseT HD Mode gesendet worden wären Meine 1. Idee war: Für Pakete, die an die D-Box IP gesendet werden, einfach eine Bandbreitenbegrenzung festlegen Ergebnis: Siehe da: Wenn ich die Upload-Bandbreite vom PC auf 8000kBit begrenze, so kriege ich mit der Box ein LeseWert von rund 5000! Das ist ein wahnsinns Fortschritt, wenn man bedenkt, dass ohne Bandbreitenbegrenzung über den Switch nahezu nichts bei der Box ankommt (mit rsize=32768 versteht sich!)! Begrenze ich die Bandbreite auf 9000kBit, so kommt da allerdings wieder so gut wie nichts an Meine 2. Idee: Es muss doch ein virtueller Software-Switch oder ähnliches für Linux geben, womit man die Frames aufbereiten kann? Also wie mein alter HW-Switch nur als Software auf meinem Linuxrechner zwischengeschaltet. So dass alle Frames für die DBox (mit dessen DST-MAC) nicht mehr über eth0 raus gehen, sondern z.B. über vir0. vir0 ist ein virtuelles Interfaces, welche mit 10baseT HD arbeiten soll und die 'geswitchten Frames' danach einfach eth0 weitergibt. Dann könnte man auch einfach ein anderes (sub)netz für die DBoxen vergeben und das vir0 Interface entsprechende IP. Z.B. eth0 -> 192.168.1.1/24 und vir0 -> 192.168.2.1/24 Dann bräuchte ich auch keine komplizierten Netfilter sondern alles würde über die Standard-Routing Table erledigt. Nur gibt es so einen virtuellen Software Switch? NACHTRAG: Vielleicht geht es schon damit: Virtual ethernet device (tunnel) Veth stands for Virtual ETHernet. It is a simple tunnel driver that works at the link layer and looks like a pair of ethernet devices interconnected with each other. Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
merkwuerden Geschrieben 8. November 2009 Melden Share Geschrieben 8. November 2009 Ich würde Dir empfehlen, auf irgendwelche Softwareexperimente und Bandbreitenbegrenzungen etc. zu verzichten und besser den Allnet-Switch zum Teufel zu schicken. Ganz offensichtlich taugt das Teil nicht, also weg damit. Da Du geschrieben hattest, dass der neu ist, dürfte es ja kein Problem sein, das Vieh wieder zum Händler zu bringen und dem zu erklären, dass das Teil mit Mischbetrieb 10/100 nur Unsinn veranstaltet. Und hast Du das Teil online geordert und noch nicht länger als 14 Tage, kannste den ja sowieso ohne Angaben von Gründen zurückgeben... Mit Deinen Software-/Bandbreitenbegrenzungsexperimenten beseitigst Du nicht das eigentliche Problem (untaugliche Hardware), sondern bekämpfst damit nur die Auswirkungen mit der Dampfhammer-Methode. Mit allen damit verbundenen Nachteilen. Ich bin zwar nicht der Netzwerkfritze (da hast Du sicher mehr Ahnung als ich), aber wenn ich logisch an die Sache ran gehe, würde ich mal so behaupten, dass jede Software, die Du in das Protokoll zwischenschaltest, zusätzlich Zeit und Bandbreite kostet. Ob's das wert ist? Meine 1. Idee war: Für Pakete, die an die D-Box IP gesendet werden, einfach eine Bandbreitenbegrenzung festlegen Ergebnis: Siehe da: Wenn ich die Upload-Bandbreite vom PC auf 8000kBit begrenze, so kriege ich mit der Box ein LeseWert von rund 5000! Das ist ein wahnsinns Fortschritt, wenn man bedenkt, dass ohne Bandbreitenbegrenzung über den Switch nahezu nichts bei der Box ankommt (mit rsize=32768 versteht sich!)! Begrenze ich die Bandbreite auf 9000kBit, so kommt da allerdings wieder so gut wie nichts an Daran siehst Du eindeutig, dass der Switch Scheiße ist. Begrenzung auf 8000kBit liefert Dir Lesewert von 5000 (3000 Verlust???), bei schon 9000kBit (das packt die Schnittstelle der Box selber immer noch!) geht nichts mehr? Für mich gäbe es eine einzige Lösung (und zwar ohne Alternative): weg mit dem Schrott. Ich fasse mal die Resultate zusammen: - Schalte ich das Interface des NFS-Servers auf 10BaseT HD, so funktioniert es bestens (LeseWert ~8000) über den neuen Switch - Schalte ich den alten Switch zwischen PC und neuen Switch, so funktioniert es auch bestens! Da merzt wohl der alte Switch die Unzulänglichkeiten des neuen bei 10Mbit aus. Mal versucht, den alten Switch zwischen Box und neuen zu hängen, den neuen direkt an den PC? Was kommt dabei raus? Ist aber trotzdem alles nur Firlefanz, der Allnet gehört weg, und gut is. Ich würde nicht krampfhaft versuchen, eine offensichtlich nicht korrekt funktionierende Hardware mit aller Gewalt zum Funktionieren zu überreden. Entweder das Zeug funktioniert wie es soll, dann is gut. Andernfalls weg damit. Hardware, die nicht korrekt funktioniert, ist indiskutabel, fertig ist der Lack. Und da is es mir persönlich auch scheißegal, ob das Zeug nur 5 oder 500 Euro gekostet hat, mit so was muss man sich nicht herum ärgern. Wenn der Krempel neu ist, mache ich Gebrauch von meinem Recht auf Gewährleistung (Nachbesserung, funktionierendes gleichwertiges Ersatzgerät, wenn beides nicht möglich, Rücktritt vom Kauf). Sonst ab in die Tonne damit - ohne Wenn und Aber... Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
Kermit21 Geschrieben 8. November 2009 Autor Melden Share Geschrieben 8. November 2009 Ich würde Dir empfehlen, auf irgendwelche Softwareexperimente und Bandbreitenbegrenzungen etc. zu verzichten und besser den Allnet-Switch zum Teufel zu schicken. Ganz offensichtlich taugt das Teil nicht, also weg damit. Da Du geschrieben hattest, dass der neu ist, dürfte es ja kein Problem sein, das Vieh wieder zum Händler zu bringen und dem zu erklären, dass das Teil mit Mischbetrieb 10/100 nur Unsinn veranstaltet. Und hast Du das Teil online geordert und noch nicht länger als 14 Tage, kannste den ja sowieso ohne Angaben von Gründen zurückgeben... So einfach ist es nicht. Und nur Unsinn stimmt ja nur, wenn die NFS Blockgröße hoch ist. Das ist eine ganz spezifische Anwendung. Ich bin zwar nicht der Netzwerkfritze (da hast Du sicher mehr Ahnung als ich), aber wenn ich logisch an die Sache ran gehe, würde ich mal so behaupten, dass jede Software, die Du in das Protokoll zwischenschaltest, zusätzlich Zeit und Bandbreite kostet. Ob's das wert ist? Die SW dürfte nur mehr CPU-Last auf dem PC machen. Wenn ich den alten Switch zwischenschalte, habe ich ja ein Netzwerk-Segment mehr, aber beste Lesewerte. Da merzt wohl der alte Switch die Unzulänglichkeiten des neuen bei 10Mbit aus. Mal versucht, den alten Switch zwischen Box und neuen zu hängen, den neuen direkt an den PC? Was kommt dabei raus? JA, das habe ich logischerweise zuerst gemacht und das ist ja das Kuriose. Nur auf Grund der Tatsache habe ich ein Wireshark Log gemacht, weil ich mich so gewundert habe: NFS-ServerPC - neuer Switch (ALL8084) - alter Switch - DBox: UDP rsize=32768 -> Schreibwert 8677, Lesewert nach knapp 4 Minuten: 2255. Wenig, aber hier geht zumindest etwas, wo vorher nach über 30Minuten noch kein Wert kam! Und hier noch mal das Kuriose: NFS-ServerPC - alter Switch - neuer Switch (ALL8084) - DBox: Schreibwert 8533, Lesewert 7757 Die Verbindung zwischen beiden Switches ist 100MBit FD!. Die Umsetzung von 100MBit FD auf 10MBit HD macht hier also gerade der neue Switch, der alleine nichts taugt. Und trotzdem Spitzenwerte. Hier noch mal meine Vermutung dazu: Wenn die Daten zu schnell kommen (100MBit -> 10MBit), dann sendet der neue Switch zwar PAUSE Frames, aber verliert/verfälscht trotzdem ein paar aktuelle NFS-Frames. Dadurch fordert der NFS-Client den kompletten 32K Block neu an und die effektive Bandbreite bricht ein. Die Entwickler der Switch-Software haben bei der Implementierung einfach geschlampt! Wenn die Daten zu schnell kommen, müssen ein paar verlorene Pakete halt neu angefordert werden. Bei 100MBit FD ist das ja kein Problem und fällt womöglich nicht mal auf. Anders bei zeitkritischen 10MBit Anwendungen, welche nahezu die komplette Bandbreite benötigt. Hinzu kommen die Kollisionen mit den neuen Switch, der scheinbar nicht schnallt, dass die DBox nur Halbduplex arbeitet. Jede Kollision veranlasst die DBox sicherlich nach CSMA/CD ein Jam-Signal zu senden und einen Waitimer auszulösen, bis sie wieder vernünftig arbeitet. Ist aber trotzdem alles nur Firlefanz, der Allnet gehört weg, und gut is. Ich würde nicht krampfhaft versuchen, eine offensichtlich nicht korrekt funktionierende Hardware mit aller Gewalt zum Funktionieren zu überreden. Entweder das Zeug funktioniert wie es soll, dann is gut. Andernfalls weg damit. Hardware, die nicht korrekt funktioniert, ist indiskutabel, fertig ist der Lack. Und da is es mir persönlich auch scheißegal, ob das Zeug nur 5 oder 500 Euro gekostet hat, mit so was muss man sich nicht herum ärgern. Wenn der Krempel neu ist, mache ich Gebrauch von meinem Recht auf Gewährleistung (Nachbesserung, funktionierendes gleichwertiges Ersatzgerät, wenn beides nicht möglich, Rücktritt vom Kauf). Sonst ab in die Tonne damit - ohne Wenn und Aber... Im Grunde hast Du recht. Jeder Händler wird das umgekehrt sehen: Die DBox Hardware ist eben zu alt für diesen modernen Switch. Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
merkwuerden Geschrieben 8. November 2009 Melden Share Geschrieben 8. November 2009 Ich will mich ja nicht zu weit aus dem Fenster lehnen, Du bist der Netzwerk-Experte. Trotzdem: NFS-ServerPC - neuer Switch (ALL8084) - alter Switch - DBox: UDP rsize=32768 -> Schreibwert 8677, Lesewert nach knapp 4 Minuten: 2255. Wenig, aber hier geht zumindest etwas, wo vorher nach über 30Minuten noch kein Wert kam! Und hier noch mal das Kuriose: NFS-ServerPC - alter Switch - neuer Switch (ALL8084) - DBox: Schreibwert 8533, Lesewert 7757 Da der alte Switch insgesamt ja funktioniert, wie Du weiter oben schriebst: da würde ich mal behaupten, dass der neue Switch mit der PC-Seite nicht klar kommt. Die kritische Richtung ist in jedem Fall PC --> Box, das steht fest. Im ersten Fall (neuer Switch an PC) funktioniert es nicht brauchbar mit dem Lesen. Im zweiten Fall, wo der alte Switch am PC hängt, funktioniert es plötzlich? Höchst merkwürdig... Die Verbindung zwischen beiden Switches ist 100MBit FD!. Das ist zwischen Switches generell so. Beide können FD (wird per Autonegotiation ausgehandelt), also arbeiten sie auch untereinander so. Die kritischen Stellen sind die Endgeräte. Die Umsetzung von 100MBit FD auf 10MBit HD macht hier also gerade der neue Switch, der alleine nichts taugt. Und trotzdem Spitzenwerte. Der neue kommt vielleicht mit dem PC nicht klar, wenn er direkt dort dran hängt und Daten via NFS/UDP verwursteln soll, was der alte Switch kann. Mal einen anderen PC mit einem NFS-Client bestücken und dann via NFS Daten zwischen Server und Client-PC und umgekehrt größere Dateien austauschen (Client auch auf HD stellen!), dabei mal mit den Switches und der Geschwindigkeit des Clienten experimentieren. Und beobachten, was der Netzwerkdurchsatz macht, da sollte es sicher Tools dafür geben. Eventuell liegt es ja auch nicht mal nur am Switch, sondern an der NIC des PC? Hast Du mal versuchsweise eine andere NIC zur Verfügung, die Du mal im PC testen könntest? Realtek 100Mbit laufen eigentlich immer recht zuverlässig, ich hab in meiner Zweitkiste eine RTL8139D drin, tut es einwandfrei. Irgendwas hat der Switch aber so oder so, da der alte ja tadellos mit der Konstellation klar kommt. Widersinnig wäre es, wenn ein altertümlicher Switch toleranter als ein aktueller wäre... Hier noch mal meine Vermutung dazu: Wenn die Daten zu schnell kommen (100MBit -> 10MBit), dann sendet der neue Switch zwar PAUSE Frames, aber verliert/verfälscht trotzdem ein paar aktuelle NFS-Frames. Dadurch fordert der NFS-Client den kompletten 32K Block neu an und die effektive Bandbreite bricht ein. Oder der Server liefert einfach munter Daten weiter und hört nicht auf den Switch. Vielleicht gibt der Switch "unverständliche" Anweisungen? Hinzu kommen die Kollisionen mit den neuen Switch, der scheinbar nicht schnallt, dass die DBox nur Halbduplex arbeitet. Jede Kollision veranlasst die DBox sicherlich nach CSMA/CD ein Jam-Signal zu senden und einen Waitimer auszulösen, bis sie wieder vernünftig arbeitet. Die Kollisionen hab ich hier auch im Netzwerk. Da spielt es keine Rolle, ob das Richtung dBox ist oder zum Zweit-PC oder NAS (WL-HDD). Alle Gerätschaften bis auf den DSL-Router arbeiten hier im HD-Mode, weil die Box auf alle zugreifen können muss. Dass die Kollisionen keine störenden Auswirkungen haben, darum muss sich der Switch kümmern. Jeder Händler wird das umgekehrt sehen: Die DBox Hardware ist eben zu alt für diesen modernen Switch. Was ich dann für eine fadenscheinige Ausrede halten würde. Oder schreibt Allnet selber irgendwas von "nicht abwärtskompatibel mit 10Mbit" oder "nicht für 10 Jahre alte Hardware geeignet"? Ich denke Du verstehst, was ich damit ausdrücken möchte. Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
Kermit21 Geschrieben 9. November 2009 Autor Melden Share Geschrieben 9. November 2009 Da der alte Switch insgesamt ja funktioniert, wie Du weiter oben schriebst: da würde ich mal behaupten, dass der neue Switch mit der PC-Seite nicht klar kommt. Die kritische Richtung ist in jedem Fall PC --> Box, das steht fest. Im ersten Fall (neuer Switch an PC) funktioniert es nicht brauchbar mit dem Lesen. Im zweiten Fall, wo der alte Switch am PC hängt, funktioniert es plötzlich? Höchst merkwürdig... Ja! Das versuche ich ja die ganze Zeit zu sagen Deshalb versuche ich das via SW am PC hinzukriegen Mal einen anderen PC mit einem NFS-Client bestücken und dann via NFS Daten zwischen Server und Client-PC und umgekehrt größere Dateien austauschen (Client auch auf HD stellen!), dabei mal mit den Switches und der Geschwindigkeit des Clienten experimentieren. Und beobachten, was der Netzwerkdurchsatz macht, da sollte es sicher Tools dafür geben. Als tool nutze ich nur das von Dir gelinkte sh-Script hier aus dem Forum für die DBox. Das tut's sehr gut! Ich habe natürlich auch schon meinen Workstation Rechner als NFS-Server für die DBox getestet mit dem gleichen Resultat. Eventuell liegt es ja auch nicht mal nur am Switch, sondern an der NIC des PC? Hast Du mal versuchsweise eine andere NIC zur Verfügung, die Du mal im PC testen könntest? Realtek 100Mbit laufen eigentlich immer recht zuverlässig, ich hab in meiner Zweitkiste eine RTL8139D drin, tut es einwandfrei. Ich setze nur homegen Intel-NICs ein, weil die sich bei mir (im unteren Preissegment) als beste erwiesen haben, was den Durchsatz (zwischen 100MBit Rechnern) und CPU-Last angeht. Mit Realtek-Karten hatte ich immer die schlechtesten Durchsätze. Die habe ich ganz schnell abgeschafft . Aber ich habe hier noch irgendwo eine 3COM NIC rumliegen. Vielleicht werde ich die noch mal testen. Irgendwas hat der Switch aber so oder so, da der alte ja tadellos mit der Konstellation klar kommt. Widersinnig wäre es, wenn ein altertümlicher Switch toleranter als ein aktueller wäre... Oder der Server liefert einfach munter Daten weiter und hört nicht auf den Switch. Vielleicht gibt der Switch "unverständliche" Anweisungen? Ich vermute auch, dass das Senden nach einem PAUSE-Frame nicht schnell genug einstellt wird. Das Wireshark-Log sagt da aber eher was anderes: Da kann ich gerade das bei dem neuen Switch nicht nachvollziehen: Da passiert nach einem PAUSE-Frame mit dem Timerwert 0xFFFF nichts mehr, bis ein zweites PAUSE-Frame mit dem Wert 0x0000 nachkommt. Beim alten Switch ist es offenbar tatsächlich so, dass nach dem PAUSE-Frame noch ein paar NFS-Pakete nachkommen. Was ich dann für eine fadenscheinige Ausrede halten würde. Oder schreibt Allnet selber irgendwas von "nicht abwärtskompatibel mit 10Mbit" oder "nicht für 10 Jahre alte Hardware geeignet"? Ich denke Du verstehst, was ich damit ausdrücken möchte. Ich weiß schon, was Du ausdrücken willst! Der Händler packt mir nach Diskussion den Switch aus, schließt ein 10MBit PC dran an und sagt mir dann "Geht doch!" und verlangt eine Überprüfungsgebühr nach AGB. Eine Bandbreite wird ja bei dem Switch auch nicht garantiert! Ist quasi so wie bei DSL-Anschlüssen Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
hansie77 Geschrieben 9. November 2009 Melden Share Geschrieben 9. November 2009 Als Tip, ohne den ganzen Fred zu lesen, ich stand mal vor ähnlichen Problemen. HP-J4097B 8 Port kann ich empfehlen. Zur Not habe ich solchen auch noch in meinem Portfolio zur Abgabe(PN) Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
Kermit21 Geschrieben 9. November 2009 Autor Melden Share Geschrieben 9. November 2009 Als Tip, ohne den ganzen Fred zu lesen, ich stand mal vor ähnlichen Problemen. HP-J4097B 8 Port kann ich empfehlen. Zur Not habe ich solchen auch noch in meinem Portfolio zur Abgabe(PN) Hat der POE (min. 3 Ports)? Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
Empfohlene Beiträge
Archiviert
Dieses Thema ist jetzt archiviert und für weitere Antworten gesperrt.