#1063 closed Defekt (erledigt)
Flowcontrol der Switche deaktivieren
| Reported by: | Rüdiger Kupper | Owned by: | bau |
|---|---|---|---|
| Priority: | schnell erledigen | Milestone: | Sommerferien 2013 |
| Component: | Hardware: Netzwerktechnik | Severity: | beeinträchtigt den Unterricht einiger Lehrer |
| Keywords: | Cc: |
Description
eben bin ich zufällig hierauf gestoßen:
https://help.ubuntu.com/community/UbuntuLTSP/FlowControl
http://sourceforge.net/mailarchive/forum.php?thread_name=49A85E28.7090006%40dm.org&forum_name=ltsp-discuss
http://virtualthreads.blogspot.de/2006/02/beware-ethernet-flow-control.html
Ist das für uns relevant?
ja unbedingt!
Wir haben gemischte Switche mit Serveranbingung 1GB und Clients an 100MBit!
Change History (13)
comment:1 by , 13 years ago
comment:2 by , 13 years ago
| Milestone: | Schuljahr 2012/13 → Sommerferien 2013 |
|---|
comment:4 by , 13 years ago
comment:6 by , 13 years ago
Test heute nachmittag (Boot meines Clients im LZ nacheinander von allen Servern, zwischen 15:45 mein 16:15):
- ltsp1: alles okay
- ltsp2: alles okay
- ltsp3: komisch: Booten geht normal schnell, An- und Abmelden ist dann aber eine Katastrophe! (Habe es mehrfach wiederholt, jedesmal Boot schnell, anmelden langsam.)
- ltsp4: nix geht (Boot lang, An-/Abmelden lang)
- ltsp5,6,7: alles okay
So. Das Flow-Control hat also wenn, dann nicht überall was gebracht.
Frage: Was sagt Dir das Schema oben? Was zeichnet ltsp3,4 gegenüber ltsp1,2 aus?
comment:7 by , 13 years ago
Ich habe diesen Test um 18.30 Uhr ebenfalls durchgeführt - allerdings ltsp3 und 4 jeweils vor Ort:
- ltsp1,2 im LZ, jeweils wie bei dir alles OK heute morgen habe ich eine GFS gerettet indem ich einen Client im U3 von ltsp1 gebootet habe - alles OK
- ltsp3 und 4 vor Ort: booten schnell, Login dauert 1,5 Minuten mindestens
- bootte ich jeweils im U3/U4 von ltsp1 geht alles flott
Testszenario:
- Kernelmodul für Realtek-NIC 8111 wieder deaktivieren (siehe #692), anschließend Test
- Switch mit einem GBit-Kupfer-Modul ausstatten anstelle des GBit-Glasfaser, anschließend Test
- Supervisorengine im Hauptswitch austauschen, anschließend Test
comment:8 by , 13 years ago
Es fand sich, dass die Switche in U3 und U4 "hingen" (vielleicht waren sie mit sich selbst beschäftigt, oder mussten nach dem Abschalten des Flow-Controls einmal neu gestartet werden).
Das schien sogar den lokalen Login a#direkt am Server als linadmin zu beeinflussen. (Vermutung: pam_mount hat versucht, einen CIFS-Share namens ///paedml/linadmin zu mounten.)
Nach einmal Stecker ziehen an den beiden Switchen liefen Boot und Login an den Clients problemlos.
Heute auch am Client in der NwT absolut flüssiger Login und flüssiges Arbeiten. Juhu! :-]
follow-up: 10 comment:9 by , 13 years ago
Ich glaub's nicht: Mein Emacs hatte seit den Sommerferien immer Grafikprobleme (beim Scrollen blieben Teile der alten Schrift stehen), die sind jetzt weg. Sollte das auch daran gelegen haben?
comment:10 by , 13 years ago
Interessant: Ich sehe die Grafik-Rendering-Probleme im Emacs noch immer, wenn ich von ltsp1 boote. Boote ich von ltsp4, sind sie weg.
comment:11 by , 13 years ago
????
In beiden Switchen ist das FlowControl ausgeschaltet
Einziger Unterschied: U3/4 sind per Glasfaser am Netz, U1 per Kupferleitung
comment:12 by , 13 years ago
Hat sich auch schon wieder geändert: Einige Minuten später traten auch hier die Renderingprobleme wieder auf. Sie könnten aber durchaus damit zusammenhängen, dass das X nicht hinterherkommt.
comment:13 by , 13 years ago
Bestätigt sich insofern: Jetzt habe ich den gleichen Client von ltsp5 gebootet und arbeite schon geraume Zeit ohne Renderfehler.
Sieht aus, als ob diese Rendering-Artefakte ein weiterer Indikator für Netzwerkschwierigkeiten sind (neben dem fehlenden Ton).
Dann sollte in den Sitchen das Flowcontrol deaktiviert werden -- wenn das nicht ohnehin schon so ist.