Re: [LTSP] boot 15 min. , wenn Bandbreitenübergang im Ethernet
Daniel Musketa [EMAIL PROTECTED] schrieb am Thu, Jun 01, 2006 at 04:43:23PM +0200: Am Donnerstag, 1. Juni 2006 14:44 schrieb Paul Puschmann: Daniel Musketa schrieb am Thu, Jun 01, 2006 at 01:58:13PM +0200: Der Client FAILED rechts unten bekommt nach dem Starten sofort seine IP-Adresse vom DHCP-Server, lädt das pximage per tftp, dann den Kernel, macht ein bißchen Hardwareerkennung und bleibt dann -- vermutlich beim NFS-Mounten des Root-FS -- ewig hängen. Ganz laaangsaaam tut sich dann was ... und schließlich startet irgendwann (bis zu 20 min.) auch Xorg und ich kann mich einloggen. Das Arbeiten selbst ist flüssig, die von X ausgetauschten TCP-Pakete finden also ihren Weg. Nebenbei: Auch sonst gibt es keine Netzwerkprobleme in dem durch ältere Leitungen nur mit 10 Mbit angebundenen Gebäudeteil. Ich vermute, das NFS-Protokoll (UDP???) kommt nicht damit klar, daß die von ihm mit 100 Mbit/s versandten Pakete nicht alle/prompt beantwortet werden. Hi, vielleicht hat du dem rechten Switch (oder evtl. auch auf dem Hub) eine Option Broadcast Storm Control oder aehnlich gesetzt? Das behindert dann die Broadcasts/Multicasts, die durchs Netz flitzen. Auf der 10MBit-Leitung koennte das ja gewunscht sein. Die Switches (es sind genau genommen jeweils zwei auf jeder Seite des 10er Hubs) sind einfache 5er/8er Switche aus der 30-EUR-Klasse. Nicht konfigurierbar. Der Hub (ein 3Com-Office-Teil, ich wüßte auch nicht von einer Konfigurierbarkeit) dient mir nur als Bremse, weil die eben nicht konfigurierbaren Switche links und rechts der schlechten Kabelstrecke sonst versuchen würden, 100 Mbit miteinander zu sprechen, was schief geht. So war es bisher eigentlich unproblematisch. Ist diese Broadcast Storm Control ein Standard-Feature in SOHO-Geräten? Was macht die? Ach so, bei Broadcast fällt mir ein: Wie gesagt, DHCP klappt sofort ... Broadcast Storm Control ist ein Feature bei managebaren 3Com Switches. Du kannst damit einstellen wieviele Broadcasts maximal pro Zeitfenster uebertragen werden sollen. Asl wir bei eine Anwendung mit extremer Multicast-Nutzung eingefuehrt hatten mussten wir dass auf den Switches deaktivieren, da sonst die Anwendung super schnarch-langsam war. Als ich gerade beim letzten Switch das OK zum deaktivieren des BSC gesetzt hatte, flitzte die Anwendung schon los. Hubs haben selten eine Managementfunktion, denke ich. Deine einfachen Switches, die du ja auch nicht konfigurieren kannst, sollten die auch einwandfrei laufen. Kannst du den Hub gegen einen anderen austauschen? Ich weiss leider auch nicht, ob es (unter Linux) ein Tool zum Testen von Broadcast/Multicast gibt. Gruss, Paul signature.asc Description: Digital signature
Re: [LTSP] boot 15 min., wenn Bandbreitenübergang im Ethernet
Am Freitag, 2. Juni 2006 01:02 schrieb Daniel Musketa: Am Donnerstag 01 Juni 2006 23:13 schrieb Reinhold Plew: Daniel Musketa wrote: Am Donnerstag 01 Juni 2006 19:12 schrieb Reinhold Plew: Daniel Musketa wrote: Ist hier im Netz irgendwas extrem faul oder ist dieses Verhalten zu erwarten/normal? Wenn letzteres, gibt es die Möglichkeit, das NFS-Mounten stabiler zu machen (über TCP, angehängte Optionen oder sowas)? Läuft die 10MBit Verbindung evt. im HalfDuplex Mode? Mmh, kann ich grad nicht so genau sagen ... Am Donnerstag 01 Juni 2006 16:43 schrieb Daniel Musketa: Der Hub (ein 3Com-Office-Teil, ich wüßte auch nicht von einer Konfigurierbarkeit) dient mir nur als Bremse, weil die eben nicht konfigurierbaren Switche links und rechts der schlechten Kabelstrecke sonst versuchen würden, 100 Mbit miteinander zu sprechen, was schief geht. Da muß ich morgen mal an den Schrank gehen und nachschauen, ob der das kann. Wie kriege ich das raus? Kann ich mich auf die Ausgabe von ethtool eines direkt angeschlossenen Linux' verlassen? sollten Dir eigentlich die Netzwerkkarten sagen. [...] Habe gerade mal einen ganz groben Test mit Samba gemacht, weiß nicht, ob der was aussagt: Wenn ich eine Datei über den 10er Flaschenhals kopiere, ist der Datendurchsatz ca. 900 kB TX zu 35 kB RX (netto), starte ich gleichzeitig eine Kopie in die Gegenrichtung, 600 kB TX zu 375 kB RX. Sieht also schon sehr nach Half Duplex aus, wenn ich das richtig verstanden habe. Was aber könnte das mit dem scheiternden NFS-Mount zu tun haben? TCP-Verbindungen laufen absolut zuverlässig über diese Strecke und auch OpenVPN, das über UDP läuft hat keine Probleme (895 kB über eth0 = 850 kB über tun0). So, ein direkt an den Hub angeschlossenes Linux mit ethtool bestätigt mir: Speed: 10 Mb/s Duplex: Half! (Gibt es überhaupt Hubs mit Full Duplex? Wäre das dann nicht automatisch ein Switch?) An dem Hub (3Com Hub TP4 Combo) gibt es einen kleinen Schalter MDI/X für Port 4. Ich nehme nicht an, daß das irgeneine Rolle spielt, oder? Grüße Daniel
Re: [LTSP] boot 15 min. , wenn Bandbreitenübergang im Ethernet
Daniel Musketa [EMAIL PROTECTED] schrieb am Fri, Jun 02, 2006 at 10:23:49AM +0200: Am Freitag, 2. Juni 2006 01:02 schrieb Daniel Musketa: Am Donnerstag 01 Juni 2006 23:13 schrieb Reinhold Plew: Daniel Musketa wrote: Am Donnerstag 01 Juni 2006 19:12 schrieb Reinhold Plew: Daniel Musketa wrote: Ist hier im Netz irgendwas extrem faul oder ist dieses Verhalten zu erwarten/normal? Wenn letzteres, gibt es die Möglichkeit, das NFS-Mounten stabiler zu machen (über TCP, angehängte Optionen oder sowas)? Läuft die 10MBit Verbindung evt. im HalfDuplex Mode? Mmh, kann ich grad nicht so genau sagen ... Am Donnerstag 01 Juni 2006 16:43 schrieb Daniel Musketa: Der Hub (ein 3Com-Office-Teil, ich wüßte auch nicht von einer Konfigurierbarkeit) dient mir nur als Bremse, weil die eben nicht konfigurierbaren Switche links und rechts der schlechten Kabelstrecke sonst versuchen würden, 100 Mbit miteinander zu sprechen, was schief geht. Da muß ich morgen mal an den Schrank gehen und nachschauen, ob der das kann. Wie kriege ich das raus? Kann ich mich auf die Ausgabe von ethtool eines direkt angeschlossenen Linux' verlassen? sollten Dir eigentlich die Netzwerkkarten sagen. [...] Habe gerade mal einen ganz groben Test mit Samba gemacht, weiß nicht, ob der was aussagt: Wenn ich eine Datei über den 10er Flaschenhals kopiere, ist der Datendurchsatz ca. 900 kB TX zu 35 kB RX (netto), starte ich gleichzeitig eine Kopie in die Gegenrichtung, 600 kB TX zu 375 kB RX. Sieht also schon sehr nach Half Duplex aus, wenn ich das richtig verstanden habe. Was aber könnte das mit dem scheiternden NFS-Mount zu tun haben? TCP-Verbindungen laufen absolut zuverlässig über diese Strecke und auch OpenVPN, das über UDP läuft hat keine Probleme (895 kB über eth0 = 850 kB über tun0). So, ein direkt an den Hub angeschlossenes Linux mit ethtool bestätigt mir: Speed: 10 Mb/s Duplex: Half! (Gibt es überhaupt Hubs mit Full Duplex? Wäre das dann nicht automatisch ein Switch?) An dem Hub (3Com Hub TP4 Combo) gibt es einen kleinen Schalter MDI/X für Port 4. Ich nehme nicht an, daß das irgeneine Rolle spielt, oder? Dieser Schalter kann die Belegung von dem Port 4 aenders, so dass dieser gekreuzt ist. Dann kannst du zu z.B. einen anderen Switch/Hub direkt mit einem normalen Kabel anschliessen. Aktuelle Switche koennen das oft automatisch erkennen, weswegen die auch meist dann keinen Schalter mehr haben. Gruss, Paul signature.asc Description: Digital signature
Re: [LTSP] boot 15 min., wenn Bandbreitenübergang im Ethernet
Daniel Musketa schrieb am Freitag, 02. Juni 2006 um 10:23:49 +0200: Am Freitag, 2. Juni 2006 01:02 schrieb Daniel Musketa: Am Donnerstag 01 Juni 2006 23:13 schrieb Reinhold Plew: Daniel Musketa wrote: Am Donnerstag 01 Juni 2006 19:12 schrieb Reinhold Plew: Daniel Musketa wrote: Ist hier im Netz irgendwas extrem faul oder ist dieses Verhalten zu erwarten/normal? Wenn letzteres, gibt es die Möglichkeit, das NFS-Mounten stabiler zu machen (über TCP, angehängte Optionen oder sowas)? Läuft die 10MBit Verbindung evt. im HalfDuplex Mode? Mmh, kann ich grad nicht so genau sagen ... Am Donnerstag 01 Juni 2006 16:43 schrieb Daniel Musketa: Der Hub (ein 3Com-Office-Teil, ich wüßte auch nicht von einer Konfigurierbarkeit) dient mir nur als Bremse, weil die eben nicht konfigurierbaren Switche links und rechts der schlechten Kabelstrecke sonst versuchen würden, 100 Mbit miteinander zu sprechen, was schief geht. Da muß ich morgen mal an den Schrank gehen und nachschauen, ob der das kann. Wie kriege ich das raus? Kann ich mich auf die Ausgabe von ethtool eines direkt angeschlossenen Linux' verlassen? sollten Dir eigentlich die Netzwerkkarten sagen. [...] Habe gerade mal einen ganz groben Test mit Samba gemacht, weiß nicht, ob der was aussagt: Wenn ich eine Datei über den 10er Flaschenhals kopiere, ist der Datendurchsatz ca. 900 kB TX zu 35 kB RX (netto), starte ich gleichzeitig eine Kopie in die Gegenrichtung, 600 kB TX zu 375 kB RX. Sieht also schon sehr nach Half Duplex aus, wenn ich das richtig verstanden habe. Was aber könnte das mit dem scheiternden NFS-Mount zu tun haben? TCP-Verbindungen laufen absolut zuverlässig über diese Strecke und auch OpenVPN, das über UDP läuft hat keine Probleme (895 kB über eth0 = 850 kB über tun0). So, ein direkt an den Hub angeschlossenes Linux mit ethtool bestätigt mir: Speed: 10 Mb/s Duplex: Half! (Gibt es überhaupt Hubs mit Full Duplex? Wäre das dann nicht automatisch ein Switch?) Ja, gibts/gabs, allerdings nur ganz selten, funktioniert das noch schlechter (nach meiner Erfahrung). Nein es wäre kein switch. Hub (gebräuchliche Bezeichnung für einen Multi-Port-Repeater): Ein Netzwerkpaket kommt auf einem Port rein und wird auf allen anderen wieder rausgeschickt. Switch: Ein Switch lernt welche Netzwerkgeräte an welchem Port hängen und verschickt ein eingehendes Paket nur auf den Port, an dem der Empfänger hängt. Vorteil, die Geräte 'stören' sich nicht gegenseitig. Kollisionen. An dem Hub (3Com Hub TP4 Combo) gibt es einen kleinen Schalter MDI/X für Port 4. Ich nehme nicht an, daß das irgeneine Rolle spielt, oder? der vertauscht die RX und TX Leitung an diesem Port, Vorteil, Du brauchst kein gekreuztes Kabel, wenn Du diese Port mit einem Hub oder Switch verbindest. Da Dein Netz auch so funktioniert, scheinen die Switche ein autosensing zu machen und die Einstellung an diesem Port kann Dir egal sein. Zu Deinem Problem: Können Kollisionen der Grund sein? Hat Dein Hub einen LED die Dir Kollisionen anzeigt, wenn ja, gibt es vielleicht sehr viele Kollisionen? -- Jörg Friedrich There are only 10 types of people: Those who understand binary and those who don't. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: [LTSP] boot 15 min., wenn Bandbreitenübergang im Ethernet
Am Freitag, 2. Juni 2006 10:43 schrieb Joerg Friedrich: Daniel Musketa schrieb am Freitag, 02. Juni 2006 um 10:23:49 +0200: Am Freitag, 2. Juni 2006 01:02 schrieb Daniel Musketa: Am Donnerstag 01 Juni 2006 23:13 schrieb Reinhold Plew: Daniel Musketa wrote: Am Donnerstag 01 Juni 2006 19:12 schrieb Reinhold Plew: Daniel Musketa wrote: Ist hier im Netz irgendwas extrem faul oder ist dieses Verhalten zu erwarten/normal? Wenn letzteres, gibt es die Möglichkeit, das NFS-Mounten stabiler zu machen (über TCP, angehängte Optionen oder sowas)? Läuft die 10MBit Verbindung evt. im HalfDuplex Mode? [...] Am Donnerstag 01 Juni 2006 16:43 schrieb Daniel Musketa: Der Hub (ein 3Com-Office-Teil, ich wüßte auch nicht von einer Konfigurierbarkeit) dient mir nur als Bremse, weil die eben nicht konfigurierbaren Switche links und rechts der schlechten Kabelstrecke sonst versuchen würden, 100 Mbit miteinander zu sprechen, was schief geht. [...] Habe gerade mal einen ganz groben Test mit Samba gemacht, weiß nicht, ob der was aussagt: Wenn ich eine Datei über den 10er Flaschenhals kopiere, ist der Datendurchsatz ca. 900 kB TX zu 35 kB RX (netto), starte ich gleichzeitig eine Kopie in die Gegenrichtung, 600 kB TX zu 375 kB RX. Sieht also schon sehr nach Half Duplex aus, wenn ich das richtig verstanden habe. Was aber könnte das mit dem scheiternden NFS-Mount zu tun haben? TCP-Verbindungen laufen absolut zuverlässig über diese Strecke und auch OpenVPN, das über UDP läuft hat keine Probleme (895 kB über eth0 = 850 kB über tun0). So, ein direkt an den Hub angeschlossenes Linux mit ethtool bestätigt mir: Speed: 10 Mb/s Duplex: Half! [...] Zu Deinem Problem: Können Kollisionen der Grund sein? Hat Dein Hub einen LED die Dir Kollisionen anzeigt, wenn ja, gibt es vielleicht sehr viele Kollisionen? Der Hub hat eine LED für Kollisionen und eine 8er LED-Kette für die Netzauslastung. Unabhängig von den Bootversuchen mit LTSP leuchtet die COLL-LED relativ häufig kurz auf, eigentlich immer, wenn mal etwas mehr als nur ein paar Byte übertragen werden, also beispielsweise bei VNC-Anwendungen oder auch _etwas_ größeren HTTP-Übertragungen. Ein Dauerleuchten sowohl der COLL-LED als auch der Auslastungskette entsteht immer dann, wenn ich größere Datenmengen z. B. per smb übertrage (obwohl, wie gesagt, nur zwei Geräte/Switche an dem Hub hängen). Vielleicht könnte ich generell mal versuchen, den Brems-Hub gegen einen 10er FullDuplex-Switch auszutauschen, wenn ich irgendwo her einen bekomme ... Aber vielleicht wäre ein anderer Ansatz ja besser, denn allein LTSPs Bootvorgang macht hier Probleme, sonst nichts. Finden den an der offensichtlichen Schwachstelle NFS-Mount irgendwelche Broad-/Multicasts statt, die man dekativieren könnte? Oder kann ich nicht irgendwo in den Start-Skripten den auf den Client geladenen Kernel anweisen, sein Root-FS über TCP zu mounten? Daniel
Re: [LTSP] boot 15 min ., wenn Bandbreitenübergang im Ethernet
Hallo Daniel, Daniel Musketa, 02.06.2006 (d.m.y): So, ein direkt an den Hub angeschlossenes Linux mit ethtool bestätigt mir: Speed: 10 Mb/s Duplex: Half! (Gibt es überhaupt Hubs mit Full Duplex? Wäre das dann nicht automatisch ein Switch?) Hubs beherrschen prinzipiell nur Hallf Duplex, weil immer nur ein angeschlossener Rechner zur Zeit senden kann. An dem Hub (3Com Hub TP4 Combo) gibt es einen kleinen Schalter MDI/X für Port 4. Ich nehme nicht an, daß das irgeneine Rolle spielt, oder? Nein, damit schaltet man den Port zwischen den Modi Normal und Uplink um. Hat den gleichen Effekt wie die Verwendung eines gekreuzten statt eines normalen Netzwerkkabels. Gruss, Christian Schmidt -- Jeder Mensch trägt einen Zauber im Gesicht: Irgendeinem gefällt er. -- Christian Friedrich Hebbel signature.asc Description: Digital signature
[LTSP] boot 15 min., wenn Bandbreitenübergang im Ethernet
Hallo, ich baue gerade eine LTSP-Struktur auf und stoße auf folgendes Problem: ... oder erst mal das Positive: Das Booten klappt grundsätzlich, egal ob PXE oder Etherboot von Floppy, und das von verschiedensten i386-Clients. Probleme gibt es (reproduzierbar), wenn im Ethernet ein Geschwindigkeitsübergang stattfindet: ++ | LTSP- | | Server | ++ | 100 Mbit TP | +---+ | Switch 10/100 | +---+ | | +-+ | +--- 10 Mbit TP ---| Hub 10 Mbit | | +-+ 100 Mbit TP | | 10 Mbit TP +---+ | | Client OK | +---+ +---+ | Switch 10/100 | +---+ | 100 Mbit TP | +---+ | Client FAILED | +---+ Der Client FAILED rechts unten bekommt nach dem Starten sofort seine IP-Adresse vom DHCP-Server, lädt das pximage per tftp, dann den Kernel, macht ein bißchen Hardwareerkennung und bleibt dann -- vermutlich beim NFS-Mounten des Root-FS -- ewig hängen. Ganz laaangsaaam tut sich dann was ... und schließlich startet irgendwann (bis zu 20 min.) auch Xorg und ich kann mich einloggen. Das Arbeiten selbst ist flüssig, die von X ausgetauschten TCP-Pakete finden also ihren Weg. Nebenbei: Auch sonst gibt es keine Netzwerkprobleme in dem durch ältere Leitungen nur mit 10 Mbit angebundenen Gebäudeteil. Ich vermute, das NFS-Protokoll (UDP???) kommt nicht damit klar, daß die von ihm mit 100 Mbit/s versandten Pakete nicht alle/prompt beantwortet werden. Ein dmesg auf dem Client führt mich zu dieser Vermutung (die Ausgabe von dmesg gibt es hier[1] -- wohin postet man denn hier auf der Mailingliste solche längeren Auszüge?) Ist hier im Netz irgendwas extrem faul oder ist dieses Verhalten zu erwarten/normal? Wenn letzteres, gibt es die Möglichkeit, das NFS-Mounten stabiler zu machen (über TCP, angehängte Optionen oder sowas)? Liebe Grüße Daniel [1] http://www.daniel.musketa.de/links/20060601-dmesg.log
Re: [LTSP] boot 15 min., wenn Bandbreitenübergang im Ethernet
Nachtrag: Im Syslog auf dem LTSP-Server sieht das so aus: 11:43:53 dhcpd: DHCPDISCOVER from 00:e0:7d:c0:38:65 via eth0 11:43:54 dhcpd: DHCPOFFER on 192.168.1.246 to 00:e0:7d:c0:38:65 via eth0 11:43:54 dhcpd: DHCPREQUEST for 192.168.1.246 (192.168.1.128) from 00:e0:7d:c0:38:65 via eth0 11:43:54 dhcpd: DHCPACK on 192.168.1.246 to 00:e0:7d:c0:38:65 via eth0 11:44:01 dhcpd: DHCPDISCOVER from 00:e0:7d:c0:38:65 via eth0 11:44:01 dhcpd: DHCPOFFER on 192.168.1.246 to 00:e0:7d:c0:38:65 via eth0 11:44:01 dhcpd: DHCPREQUEST for 192.168.1.246 (192.168.1.128) from 00:e0:7d:c0:38:65 via eth0 11:44:01 dhcpd: DHCPACK on 192.168.1.246 to 00:e0:7d:c0:38:65 via eth0 11:44:02 dhcpd: DHCPREQUEST for 192.168.1.246 (192.168.1.128) from 00:e0:7d:c0:38:65 via eth0 11:44:02 dhcpd: DHCPACK on 192.168.1.246 to 00:e0:7d:c0:38:65 via eth0 11:44:04 mountd[4126]: authenticated mount request from 192.168.1.246:1002 for /opt/ltsp/i386 (/opt/ltsp) 12:07:46 mountd[4126]: authenticated unmount request from 192.168.1.246:712 for /opt/ltsp/i386 (/opt/ltsp) Das Mounten findet laut syslog also unmittelbar nach Laden des Kernels erfolgreich statt ... Daniel -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: [LTSP] boot 15 min. , wenn Bandbreitenübergang im Ethernet
Daniel Musketa [EMAIL PROTECTED] schrieb am Thu, Jun 01, 2006 at 01:58:13PM +0200: Hallo, ich baue gerade eine LTSP-Struktur auf und stoße auf folgendes Problem: ... oder erst mal das Positive: Das Booten klappt grundsätzlich, egal ob PXE oder Etherboot von Floppy, und das von verschiedensten i386-Clients. Probleme gibt es (reproduzierbar), wenn im Ethernet ein Geschwindigkeitsübergang stattfindet: ++ | LTSP- | | Server | ++ | 100 Mbit TP | +---+ | Switch 10/100 | +---+ | | +-+ | +--- 10 Mbit TP ---| Hub 10 Mbit | | +-+ 100 Mbit TP | | 10 Mbit TP +---+ | | Client OK | +---+ +---+ | Switch 10/100 | +---+ | 100 Mbit TP | +---+ | Client FAILED | +---+ Der Client FAILED rechts unten bekommt nach dem Starten sofort seine IP-Adresse vom DHCP-Server, lädt das pximage per tftp, dann den Kernel, macht ein bißchen Hardwareerkennung und bleibt dann -- vermutlich beim NFS-Mounten des Root-FS -- ewig hängen. Ganz laaangsaaam tut sich dann was ... und schließlich startet irgendwann (bis zu 20 min.) auch Xorg und ich kann mich einloggen. Das Arbeiten selbst ist flüssig, die von X ausgetauschten TCP-Pakete finden also ihren Weg. Nebenbei: Auch sonst gibt es keine Netzwerkprobleme in dem durch ältere Leitungen nur mit 10 Mbit angebundenen Gebäudeteil. Ich vermute, das NFS-Protokoll (UDP???) kommt nicht damit klar, daß die von ihm mit 100 Mbit/s versandten Pakete nicht alle/prompt beantwortet werden. Hi, vielleicht hat du dem rechten Switch (oder evtl. auch auf dem Hub) eine Option Broadcast Storm Control oder aehnlich gesetzt? Das behindert dann die Broadcasts/Multicasts, die durchs Netz flitzen. Auf der 10MBit-Leitung koennte das ja gewunscht sein. Gruss, Paul signature.asc Description: Digital signature
Re: [LTSP] boot 15 min., wenn Bandbreitenübergang im Ethernet
Hallo Paul, Am Donnerstag, 1. Juni 2006 14:44 schrieb Paul Puschmann: Daniel Musketa schrieb am Thu, Jun 01, 2006 at 01:58:13PM +0200: Hallo, ich baue gerade eine LTSP-Struktur auf und stoße auf folgendes Problem: ... oder erst mal das Positive: Das Booten klappt grundsätzlich, egal ob PXE oder Etherboot von Floppy, und das von verschiedensten i386-Clients. Probleme gibt es (reproduzierbar), wenn im Ethernet ein Geschwindigkeitsübergang stattfindet: ++ | LTSP- | | Server | ++ 100 Mbit TP +---+ | Switch 10/100 | +---+ | | +-+ | | +--- 10 Mbit TP ---| Hub 10 Mbit | | +-+ 100 Mbit TP | | 10 Mbit TP +---+ | | Client OK | +---+ +---+ | Switch 10/100 | +---+ 100 Mbit TP +---+ | Client FAILED | +---+ Der Client FAILED rechts unten bekommt nach dem Starten sofort seine IP-Adresse vom DHCP-Server, lädt das pximage per tftp, dann den Kernel, macht ein bißchen Hardwareerkennung und bleibt dann -- vermutlich beim NFS-Mounten des Root-FS -- ewig hängen. Ganz laaangsaaam tut sich dann was ... und schließlich startet irgendwann (bis zu 20 min.) auch Xorg und ich kann mich einloggen. Das Arbeiten selbst ist flüssig, die von X ausgetauschten TCP-Pakete finden also ihren Weg. Nebenbei: Auch sonst gibt es keine Netzwerkprobleme in dem durch ältere Leitungen nur mit 10 Mbit angebundenen Gebäudeteil. Ich vermute, das NFS-Protokoll (UDP???) kommt nicht damit klar, daß die von ihm mit 100 Mbit/s versandten Pakete nicht alle/prompt beantwortet werden. Hi, vielleicht hat du dem rechten Switch (oder evtl. auch auf dem Hub) eine Option Broadcast Storm Control oder aehnlich gesetzt? Das behindert dann die Broadcasts/Multicasts, die durchs Netz flitzen. Auf der 10MBit-Leitung koennte das ja gewunscht sein. Die Switches (es sind genau genommen jeweils zwei auf jeder Seite des 10er Hubs) sind einfache 5er/8er Switche aus der 30-EUR-Klasse. Nicht konfigurierbar. Der Hub (ein 3Com-Office-Teil, ich wüßte auch nicht von einer Konfigurierbarkeit) dient mir nur als Bremse, weil die eben nicht konfigurierbaren Switche links und rechts der schlechten Kabelstrecke sonst versuchen würden, 100 Mbit miteinander zu sprechen, was schief geht. So war es bisher eigentlich unproblematisch. Ist diese Broadcast Storm Control ein Standard-Feature in SOHO-Geräten? Was macht die? Ach so, bei Broadcast fällt mir ein: Wie gesagt, DHCP klappt sofort ... Gruss, Paul Gruß, Daniel
Re: [LTSP] boot 15 min., wenn Bandbreitenübergang im Ethernet
Hallo, Reinhold, Am Donnerstag 01 Juni 2006 19:12 schrieb Reinhold Plew: Daniel Musketa wrote: Ist hier im Netz irgendwas extrem faul oder ist dieses Verhalten zu erwarten/normal? Wenn letzteres, gibt es die Möglichkeit, das NFS-Mounten stabiler zu machen (über TCP, angehängte Optionen oder sowas)? Läuft die 10MBit Verbindung evt. im HalfDuplex Mode? Mmh, kann ich grad nicht so genau sagen ... Am Donnerstag 01 Juni 2006 16:43 schrieb Daniel Musketa: Der Hub (ein 3Com-Office-Teil, ich wüßte auch nicht von einer Konfigurierbarkeit) dient mir nur als Bremse, weil die eben nicht konfigurierbaren Switche links und rechts der schlechten Kabelstrecke sonst versuchen würden, 100 Mbit miteinander zu sprechen, was schief geht. Da muß ich morgen mal an den Schrank gehen und nachschauen, ob der das kann. Wie kriege ich das raus? Kann ich mich auf die Ausgabe von ethtool eines direkt angeschlossenen Linux' verlassen? Was wäre an Half Duplex eigentlich schlimm? (Es stecken übrigens nur zwei Kabel in diesem 10er Hub, jeweils zu einem 10/100er Switch.) Liebe Grüße Daniel
Re: [LTSP] boot 15 min., wenn Bandbreitenübergang im Ethernet
Am Donnerstag 01 Juni 2006 23:13 schrieb Reinhold Plew: Daniel Musketa wrote: Am Donnerstag 01 Juni 2006 19:12 schrieb Reinhold Plew: Daniel Musketa wrote: Ist hier im Netz irgendwas extrem faul oder ist dieses Verhalten zu erwarten/normal? Wenn letzteres, gibt es die Möglichkeit, das NFS-Mounten stabiler zu machen (über TCP, angehängte Optionen oder sowas)? Läuft die 10MBit Verbindung evt. im HalfDuplex Mode? Mmh, kann ich grad nicht so genau sagen ... Am Donnerstag 01 Juni 2006 16:43 schrieb Daniel Musketa: Der Hub (ein 3Com-Office-Teil, ich wüßte auch nicht von einer Konfigurierbarkeit) dient mir nur als Bremse, weil die eben nicht konfigurierbaren Switche links und rechts der schlechten Kabelstrecke sonst versuchen würden, 100 Mbit miteinander zu sprechen, was schief geht. Da muß ich morgen mal an den Schrank gehen und nachschauen, ob der das kann. Wie kriege ich das raus? Kann ich mich auf die Ausgabe von ethtool eines direkt angeschlossenen Linux' verlassen? sollten Dir eigentlich die Netzwerkkarten sagen. Was wäre an Half Duplex eigentlich schlimm? (Es stecken übrigens nur zwei Kabel in diesem 10er Hub, jeweils zu einem 10/100er Switch.) Hatte auch mal so einen Effekt mit einem Billig-Switch. Beim Ping alles ok, aber beim Datentransfer war Kaffekochen angesagt. Half-Duplex heisst ganz einfach, das beide Seiten nicht gleichzeitig senden und empfangen können. Alles schön nacheinander. Habe gerade mal einen ganz groben Test mit Samba gemacht, weiß nicht, ob der was aussagt: Wenn ich eine Datei über den 10er Flaschenhals kopiere, ist der Datendurchsatz ca. 900 kB TX zu 35 kB RX (netto), starte ich gleichzeitig eine Kopie in die Gegenrichtung, 600 kB TX zu 375 kB RX. Sieht also schon sehr nach Half Duplex aus, wenn ich das richtig verstanden habe. Was aber könnte das mit dem scheiternden NFS-Mount zu tun haben? TCP-Verbindungen laufen absolut zuverlässig über diese Strecke und auch OpenVPN, das über UDP läuft hat keine Probleme (895 kB über eth0 = 850 kB über tun0). Grüße Daniel
