PPPoE laeuft, aber nicht richtig
Hallo Linux'er! Ich habe ein Problem, und zwar bin ich mit meinem SuSE 7.3 Kernel 2.4.10-4GB von RP-PPPoE zum Kernel PPPoE umgesiedelt, da mit RP-PPPoE zu langsam war. Die Installation klappte auch ganz gut und in's Netz komme ich auch mit ner gehörigen Geschwindigkeit. Was allerdings noch nicht klappt (vorher aber geklappt hat) ist SMTP (Mails aus Outlook gehen nicht mehr raus, wegen Timeout) oder das action.cfn von freemail.web.de. Mails lesen geht noch wunderbar. Bei GMX geht garnix mehr. Da sich an den Clients garnix verändert hat, und am Server nur der PPPoE wird's wohl daran liegen. Hatte jemand schonmal ein ähnliches Problem? Hilft ein Kernel-Update? Oder hab ich in meine /etc/ppp/options einen falschen/fehlenden Eintrag? Irgendwie klappt da auch was mit der MTR und MRU nicht so richtig. Kann es daran vielleicht liegen? Viele Dank im Voraus Moritz Esser P.S. Hier noch meine options: # /etc/ppp/options plugin /usr/lib/pppd/2.4.1/pppoe.so connect /bin/true disconnect /bin/true defaultroute idle 1200 ipcp-accept-local ipcp-accept-remote lcp-echo-interval 10 lcp-max-failure 3 local lock mru 1492 mtu 1492 noauth nocrtscts noipdefault user "x@y.z" hide-password -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net
Moritz Esser
Irgendwie klappt da auch was mit der MTR und MRU nicht so richtig. Kann es daran vielleicht liegen? Viele Dank im Voraus Moritz Esser
Dann geh nach SuSE und such in der Support-Datenbank mach MTU. Da findest Du dann etwas und das kontrollierst Du erst einmal. Ich will Dir ja nicht die Spannung nehmen, aber ich verrate einfach einmal etwas mehr: http://sdb.suse.de/de/sdb/html/cg_pmtu2.html mtu und mru müssen in mehreren Dateien richtig eingestellt werden: /etc/ppp/options /etc/ppp/peers/pppoe In der von dir geposteten Datei war es richtig, daher nehme ich erst einmal an, dass es in der anderen falsch drinnen ist. Mit den besten Grüßen, Konrad Neitzel -- SoftMediaTec GmbH Tel: 0172 / 689 31 45 Fax: 069 / 90 50 99 53
Hallo, On Tue, 26 Feb 2002, Moritz Esser wrote:
P.S. Hier noch meine options: # /etc/ppp/options
plugin /usr/lib/pppd/2.4.1/pppoe.so
connect /bin/true disconnect /bin/true
defaultroute
idle 1200 ipcp-accept-local ipcp-accept-remote
lcp-echo-interval 10 lcp-max-failure 3 local lock
mru 1492 mtu 1492
noauth nocrtscts noipdefault
user "x@y.z" hide-password
Ich (ebenfalls Kernel-2.4.16-pppoe, pppd 2.4.1) habe hier noch folgende Eintraege: usepeerdns linkname eth0 Ich denke, der letztere ist wichtig. Achso: du machst vorher schon ein "route del default; ifconfig eth0 DUMMY_IP up"? (DUMMY_IP ist bei mir 10.0.0.1). -dnh -- Never put off till tomorrow what you can avoid all together. -- fortune file
Hallo Liste!
Thomas Schürmann
Ist der RP-PPPoE tatsächlich langsamer als der Kernel-PPPoE? Subjektives Empfinden oder objektive Vergleichswerte? Kann das jemand bestätigen? Gründe?
Hmm - ich habe subjektiv keinen Unterschied festgestellt und auch die Übertragungsraten waren ähnlich (Zuerst Debian mit rp-pppoe und dann später SuSE mit Kernel-pppoe) Exakt kann ich es aber nicht sagen, da ich weder die Übertragungsraten peinlich genau notiert habe (Da sind ja ehh einige Schwankungen!) noch die Last des Rechners beobachtet habe. Ein Prozess im Kernel selbst ist natürlich deutlich zu beschleunigen und zu optimieren. Ich denke da nur an den "Kernel-httpd". Aber hier habe ich für mein Empfinden keinen Unterschied feststellen können. Mit den besten Grüßen, Konrad Neitzel -- SoftMediaTec GmbH Tel: 0172 / 689 31 45 Fax: 069 / 90 50 99 53
Hallo Moritz, Moritz Esser wrote:
Hallo Linux'er!
Ich habe ein Problem, und zwar bin ich mit meinem SuSE 7.3 Kernel 2.4.10-4GB von RP-PPPoE zum Kernel PPPoE umgesiedelt, da mit RP-PPPoE zu langsam war.
Ist der RP-PPPoE tatsächlich langsamer als der Kernel-PPPoE? Subjektives Empfinden oder objektive Vergleichswerte? Kann das jemand bestätigen? Gründe? Gruß Thomas -- ./no_signature
Ist der RP-PPPoE tatsächlich langsamer als der Kernel-PPPoE? Subjektives Empfinden oder objektive Vergleichswerte? Kann das jemand bestätigen? Gründe?
Hmm - ich habe subjektiv keinen Unterschied festgestellt und auch die Übertragungsraten waren ähnlich (Zuerst Debian mit rp-pppoe und dann später SuSE mit Kernel-pppoe) Exakt kann ich es aber nicht sagen, da ich weder die Übertragungsraten peinlich genau notiert habe (Da sind ja ehh einige Schwankungen!) noch die Last des Rechners beobachtet habe.
Ein Prozess im Kernel selbst ist natürlich deutlich zu beschleunigen und zu optimieren. Ich denke da nur an den "Kernel-httpd". Aber hier habe ich für
mein Empfinden keinen Unterschied feststellen können.
Beweisen kann ich das leider auch nicht, aber getestet habe ich es schon. Und zwar mit einem Tool, das indirekt bis zu 5000 Verbindungen aufbaut und auf ca. 10% permanent Informationen austauscht. So entstehen Datenraten um die 60Kb up und down. Meine Bandbreite liegt jedoch bei 1MBit up und down und trotzdem war es kaum noch möglich mit anderen Klienten zu surfen. Der Rechner wurde einfach langsamer. Ich weiß, daß ist auch subjektiv, vor allem, weil ich den Namen des Tools nicht nennen möchte, aber es ist meine Erfahrung die ich vor kurzem mit dem RP-PPPoE gemacht habe, und mit dem Kernel-PPPoE zuvor nicht. Mit freundlichen Grüßen Moritz -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net
Irgendwie klappt da auch was mit der MTR und MRU nicht so richtig. Kann es daran vielleicht liegen? Viele Dank im Voraus Moritz Esser
mtu und mru müssen in mehreren Dateien richtig eingestellt werden: /etc/ppp/options /etc/ppp/peers/pppoe
In der von dir geposteten Datei war es richtig, daher nehme ich erst einmal an, dass es in der anderen falsch drinnen ist.
Hallo Konrad! Wie ich anhand der SuSE-SDB feststellen konnte liegt mein Problem wirklich an der MTU/MRU. Ich habe allerdings meine Konfig-Dateien durchgeschaut, und keinen Fehler gefunden. Beide standen auf 1492. Trotzdem sagt mir der pppd "couldn't increase 'MTR/MRU' to 1500". ifconfig bestätigt mir allerdings, daß die MTU bei 1192 liegt. Soll ich die (Fehler-)Meldung irgnorieren? Das Problem besteht allerdings fpr die clients (Windoof) noch immer. Und zwar haben die ja eine voreingestellt MTU von 1500. Deswegen kommen die auch nicht in's Netz. Die SDB schlägt einen Firewall-Eintrag vor. Diesen habe ich allerdings schon in meiner Firewall drinne. Und zwar ganz oben, direkt nach den default-policies. Ich poste einfach noch den Anfang meines Firewall-Skriptes mit, dann kannst Du ja mal gucken ob daran was falsch. Vielen Dank im Voraus Moritz #!/bin/sh echo "<----Starting Firewall---->" INTERN="eth0" EXTERN="eth1" SMB="137:139" HIGHPORTS="1024:65535" # Löscht alle existierenden Regeln. iptables -F iptables -F -t nat # Löscht alle existierenden "Chains". iptables -X # Kette zum loggen und verwerfen ungewollter Anfragen. iptables -N drop_n_log iptables -A drop_n_log -p ICMP -j LOG --log-prefix "[DROP-ICMP]" iptables -A drop_n_log -p UDP -j LOG --log-prefix "[DROP-UDP]" iptables -A drop_n_log -p TCP -j LOG --log-prefix "[DROP-TCP]" iptables -A drop_n_log -j DROP # Kette zum Überprüfen auf bestehende Verbindungen iptables -N check iptables -A check -m state --state ESTABLISHED -j ACCEPT iptables -A check -m state --state RELATED -j ACCEPT iptables -A check -m state --state NEW -i ! $EXTERN -j ACCEPT iptables -A check -m state --state INVALID -j drop_n_log # Die Grundeinstellung verbietet alles. iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP # Alle Verbindungen nach Extern werden maskiert. iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN \ -j TCPMSS --clamp-mss-to-pmtu iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net
Hallo, On Wed, 27 Feb 2002, Moritz Esser wrote:
Ist der RP-PPPoE tatsächlich langsamer als der Kernel-PPPoE? Subjektives Empfinden oder objektive Vergleichswerte? Kann das jemand bestätigen? Gründe?
Hmm - ich habe subjektiv keinen Unterschied festgestellt und auch die Übertragungsraten waren ähnlich (Zuerst Debian mit rp-pppoe und dann später SuSE mit Kernel-pppoe) Exakt kann ich es aber nicht sagen, da ich weder die Übertragungsraten peinlich genau notiert habe (Da sind ja ehh einige Schwankungen!) noch die Last des Rechners beobachtet habe.
IMO ist die CPU-Last der wichtigste Unterschied... "man Kontextwechsel"... Das ist auch das, was TUX/den Kernel-httpd so schnell macht...
Beweisen kann ich das leider auch nicht, aber getestet habe ich es schon. Und zwar mit einem Tool, das indirekt bis zu 5000 Verbindungen aufbaut und auf ca. 10% permanent Informationen austauscht. So entstehen Datenraten um die 60Kb up und down. Meine Bandbreite liegt jedoch bei 1MBit up und down und trotzdem war es kaum noch möglich mit anderen Klienten zu surfen. Der Rechner wurde einfach langsamer.
Hast du da mal die CPU-Last beobachtet? -dnh -- "We're sysadmins. Sanity happens to other people." -- Chris King
Hast du da mal die CPU-Last beobachtet?
Nicht wirklich, da meine CPU-Last eh starken Schwankungen unterlegen ist. Im Verhältnis zu jetzt war sie aber deutlich höher. Mit welchem befehl lässt Du Dir die CPU-Last anzeigen? Vielleicht liegen meine Schwankungen am Tool. MfG Moritz -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net
Hallo David, hallo Moritz, hallo Liste, David Haller wrote:
Hallo,
On Wed, 27 Feb 2002, Moritz Esser wrote:
Ist der RP-PPPoE tatsächlich langsamer als der Kernel-PPPoE? Subjektives Empfinden oder objektive Vergleichswerte? Kann das jemand bestätigen? Gründe?
Hmm - ich habe subjektiv keinen Unterschied festgestellt und auch die Übertragungsraten waren ähnlich (Zuerst Debian mit rp-pppoe und dann später SuSE mit Kernel-pppoe) Exakt kann ich es aber nicht sagen, da ich weder die Übertragungsraten peinlich genau notiert habe (Da sind ja ehh einige Schwankungen!) noch die Last des Rechners beobachtet habe.
IMO ist die CPU-Last der wichtigste Unterschied... "man Kontextwechsel"... Das ist auch das, was TUX/den Kernel-httpd so schnell macht...
Beweisen kann ich das leider auch nicht, aber getestet habe ich es schon. Und zwar mit einem Tool, das indirekt bis zu 5000 Verbindungen aufbaut und auf ca. 10% permanent Informationen austauscht. So entstehen Datenraten um die 60Kb up und down. Meine Bandbreite liegt jedoch bei 1MBit up und down und trotzdem war es kaum noch möglich mit anderen Klienten zu surfen. Der Rechner wurde einfach langsamer.
Hast du da mal die CPU-Last beobachtet?
Wie gehe ich am besten vor, um Veränderungen durch den Wechsel von RP-PPPoE auf Kernel-PPPoE festzustellen? Ich fahre z.Zt. auf meiner A-DSL (nicht S-DSL wie Moritz) eine eigene iptables-FW mit RP-PPPoE (orig. Paket von SuSE 7.3). Dort ist auch der SuSE-Kernel 2.4.10-4GB installiert. Zusätzlich sämtliche Security-Updates von SuSE (für installierte Pakete) gemacht. Kein X usw. vorhanden. Chaintech 5AGM-MoBo mit AMD K6-2 450 MHz und 196 MB RAM. - aktuellen RP-PPPoE (selbst übersetzen) und Vanilla-Kernel 2.4.17 installieren? - Messung z.B. anhand von ftp.gwdg.de-downloads? 2 Dauer-Sauger und 1 Online-Gamer sind vorhanden (3 PC, evtl. auch 4, an DSL-Router). - Womit logge / protokolliere ich das? - Andere Vorschläge / Vorgehensweisen? - Irgendwelche Mitstreiter ;-) bzw. Interessenten? Gruß Thomas -- ./no_signature
Hallo, On Wed, 27 Feb 2002, Moritz Esser wrote:
Hast du da mal die CPU-Last beobachtet?
Nicht wirklich, da meine CPU-Last eh starken Schwankungen unterlegen ist. Im Verhältnis zu jetzt war sie aber deutlich höher. Mit welchem befehl lässt Du Dir die CPU-Last anzeigen? Vielleicht liegen meine Schwankungen am Tool.
Meist mit 'top'... bzw. indirekt daran, wieviel 'seti' noch abbekommt ;) Ich habe hier[1] jedenfalls _keine_ feststellbare CPU-Last durch PPPoE... -dnh [1] AMD K7-500 ("Ur-Athlon"), 320 MB RAM, Kernel 2.4.16 (vanilla, was sonst! ;) -- Im Himmel ist Radau der Petrus ist nicht froh Die Engel sind Blau Und der Himmel so wieso [WoKo in dag°]
Hallo, On Wed, 27 Feb 2002, Thomas Schürmann wrote:
David Haller wrote:
IMO ist die CPU-Last der wichtigste Unterschied... "man Kontextwechsel"... Das ist auch das, was TUX/den Kernel-httpd so schnell macht... [..] Hast du da mal die CPU-Last beobachtet?
Wie gehe ich am besten vor, um Veränderungen durch den Wechsel von RP-PPPoE auf Kernel-PPPoE festzustellen?
Hm. Zuerst wuerde ich mal versuchen, die Belastung mit dem rp-ppoed festzustellen...
Ich fahre z.Zt. auf meiner A-DSL (nicht S-DSL wie Moritz) eine eigene iptables-FW mit RP-PPPoE (orig. Paket von SuSE 7.3). Dort ist auch der SuSE-Kernel 2.4.10-4GB installiert. Zusätzlich sämtliche Security-Updates von SuSE (für installierte Pakete) gemacht. Kein X usw. vorhanden. Chaintech 5AGM-MoBo mit AMD K6-2 450 MHz und 196 MB RAM. - aktuellen RP-PPPoE (selbst übersetzen) und Vanilla-Kernel 2.4.17 installieren?
Noe. Es geht doch um den Kernel-Treiber: Also aktuellen Kernel saugen, mit Unterstuetzung fuer PPPoE uebersetzen (Modul oder fest ist egal, sind dann die Module pppoe und pppox), dann noch den pppd ggfs. aktualisieren (muss halt pppoe koennen, z.B. 2.4.1 mit patch, siehe z.B. die Anleitung fuer T-DSL auf adsl4linux.de, ggfs. kannste von mir auch ne gepatchte Version bekommen), dann eben noch konfigurieren, startscript schreiben/anpassen/z.B. von mir gemailt bekommen... Ich bekomm hier i.d.R. bis zu 93 KB/s ohne bemerkbare CPU-Last...
- Messung z.B. anhand von ftp.gwdg.de-downloads? 2 Dauer-Sauger und 1 Online-Gamer sind vorhanden (3 PC, evtl. auch 4, an DSL-Router).
zum Beispiel ;)
- Womit logge / protokolliere ich das?
top? Ne, tut mir leid, keine Ahnung eigentlich... Ich hab mir als ich DSL bekam halt gesagt, ok, der Kerneltreiber soll schneller (weniger CPU-Last) sein, also teste doch den mal zuerst, und da dann alles auf Anhieb klappte... Achso, die CPU-Last koenntest du auch noch insofern testen, indem du nebenher ein "gieriges" Programm laufen laesst, und beobachtest, ob davon der Durchsatz betroffen ist... Hm. z.B. Seti schrittweise in top runter "renice"en, bis das auf den Durchsatz "durchschlaegt", diese "nice" Einstellung merken und dann mit dem Kernel-Treiber gegen- testen... -dnh --
Like the man said: "Nothing good ever goes in /opt." -- T. W. Foreman s/\/opt/\// -- P. L. Basilisk
participants (4)
-
David Haller -
Konrad Neitzel -
Moritz Esser -
Thomas Schürmann