#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.