TCP Previous segment lost nur bei pop3???
Richard Lechner
ich habe ein Problem dass ich schon länger vor mir herschiebe.
Hatte erst dovecot im Verdacht aber nach dem Dump sehe ich den erstmal als
unschuldig an. Nachdem es früher (hmmm, voriges Jahr?) ganz normal ging und
ich nichts geändert habe könnte der Fehler wo liegen?
Symptom:
Beim Server geht der POP3-Verkehr total lansgsam, teilweise steht das ganze
sekundenlang und macht dann irgendwann weiter.
Beim abholen der Mails springt gkrellm am Client von
4 KB bis zu 20 KB und wieder zurück, dazwischen gibts wieder eine Pause von
X Sekunden. Beim senden via SMTP gehts mit 90 - 100 KB/s relativ normal und
annehmbar. Provider sagt es sind keine Filter am Switch aktiv.
Ich habe jetzt einen TCP-Dump gemacht und sehe dort beim POP3 die Fehler-
meldung: [TCP Previous segment lost]. Danach macht er ein [TCP Retransmission]
und arbeitet weiter [Continuation] und läuft meist in der selben Sekunde ins
nächste [TCP Previous segment lost].
Beim senden sehe ich im Dump ein paar [TCP Retransmission] wo er schreibt:
Checksum: 0xd2c7 [incorrect, should be 0x666b (maybe caused by checksum off-
loading?)]
Mich wundert dass POP3 nur mit wenigen KB geht während SMTP und WEB relativ
normal funktionieren? Server hat keine grosse Last um diese Zeit, iostat
zeigt kaum was an. Am Server schreibt er keine Fehler im Interfacestatus.
eth1 Link encap:Ethernet HWaddr 00:16:17:B4:57:3A
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:993928251 errors:0 dropped:0 overruns:0 frame:0
TX packets:1624020313 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:437201494 (416.9 MiB) TX bytes:2894404560 (2.6 GiB)
Interrupt:145
Achtung Überlänge! netstat zeigt:
TcpExt: SyncookiesSent SyncookiesRecv SyncookiesFailed EmbryonicRsts PruneCalled RcvPruned OfoPruned OutOfWindowIcmps LockDroppedIcmps ArpFilter TW TWRecycled TWKilled PAWSPassive PAWSActive PAWSEstab DelayedACKs DelayedACKLocked DelayedACKLost ListenOverflows ListenDrops TCPPrequeued TCPDirectCopyFromBacklog TCPDirectCopyFromPrequeue TCPPrequeueDropped TCPHPHits TCPHPHitsToUser TCPPureAcks TCPHPAcks TCPRenoRecovery TCPSackRecovery TCPSACKReneging TCPFACKReorder TCPSACKReorder TCPRenoReorder TCPTSReorder TCPFullUndo TCPPartialUndo TCPDSACKUndo TCPLossUndo TCPLoss TCPLostRetransmit TCPRenoFailures TCPSackFailures TCPLossFailures TCPFastRetrans TCPForwardRetrans TCPSlowStartRetrans TCPTimeouts TCPRenoRecoveryFail TCPSackRecoveryFail TCPSchedulerFailed TCPRcvCollapsed TCPDSACKOldSent TCPDSACKOfoSent TCPDSACKRecv TCPDSACKOfoRecv TCPAbortOnSyn TCPAbortOnData TCPAbortOnClose TCPAbortOnMemory TCPAbortOnTimeout TCPAbortOnLinger TCPAbortFailed TCPMemoryPressures
TcpExt: 0 0 0 128587 3093 0 0 208 0 0 10357977 1028 0 0 0 23346 5756432 6082 622900 4890185 4890185 698014149 3009679289 4208771962 0 95287565 12268052 242918056 1720056684 9802 9447462 95 1220 515 1123 1504 1691 10367 11380 82585 30840671 1543 3847 162341 105157 35719081 281787 1821544 686311 908 278523 22889 334375 617878 2902 97076 358 0 196733 14888 0 9370 0 109 0
Kann jemand mit diesen Daten etwas anfangen und mich in die richtige Richtung
schubsen? Könnte der Provider am Switchport mehr erkennen als ich?
Achja, POP3 geht bei verschiedensten Kunden so langsam, kann also nicht am Netz
hier liegen.
Danke.
Florian Weimer
> Mich wundert dass POP3 nur mit wenigen KB geht während SMTP und WEB relativ
> normal funktionieren? Server hat keine grosse Last um diese Zeit, iostat
> zeigt kaum was an. Am Server schreibt er keine Fehler im Interfacestatus.
Schau mal mit mii-tool und ethtool nach.
Roman Racine
> Beim senden sehe ich im Dump ein paar [TCP Retransmission] wo er schreibt:
> Checksum: 0xd2c7 [incorrect, should be 0x666b (maybe caused by checksum
> off- loading?)]
> Mich wundert dass POP3 nur mit wenigen KB geht während SMTP und WEB
> relativ normal funktionieren? Server hat keine grosse Last um diese Zeit,
> iostat zeigt kaum was an. Am Server schreibt er keine Fehler im
> Interfacestatus.
Ich habe zwar auch keine plausible Erklärung, wieso das nur bei POP3
auftritt, ich würde an deiner Stelle aber trotzdem mit ethtool überprüfen,
ob deine Karte Offloading eingeschaltet hat und dieses ggf. ausschalten und
nachsehen, ob der Fehler immer noch auftritt.
Gruss
Roman°
--
IRC: Freenode, #usenet-friends
Richard Lechner
obelix:~# mii-tool eth1
SIOCGMIIPHY on 'eth1' failed: Operation not supported
Diagnostics
SIOCGMIIPHY on 'eth?' failed: Operation not permitted
Most kernels restrict access to root.
Hmmm. Manchmal fühl ich mich bei Linux auch schon richtig unwohl.Kann ich mir
das Wochenende wieder mit Google um die Ohren schlagen.
Danke erstmal.
Ralph Angenendt
> Florian Weimer writes:
>> Schau mal mit mii-tool und ethtool nach.
>
> obelix:~# mii-tool eth1
> SIOCGMIIPHY on 'eth1' failed: Operation not supported
mii-tool *UND* ethtool, bitte. Einige alte Karten funktionieren nur mit
mii-tool, neuere Karten lassen sich nur mit ethtool ansprechen.
Ralph
--
Von Bismarck stammt der Satz, dass die Leute ruhiger schlafen könnten, wenn
sie nicht wissen, wie Gesetze und Würste gemacht werden. Wer heute diesen Satz
zitiert, beleidigt Würste. -- Heribert Prantl zum geplanten BKA-Gesetz
Nicht schreiben können: http://lestighaniker.de/
Richard Lechner
obelix:~# apt-get install ethtool
Err http://ftp.de.debian.org sarge/main ethtool 2-1
404 Not Found
Grrr, immer dieser Updatewahn! So schnell wie die wechseln kann ich meine
Server nicht nachziehen! Kacke das! Mal sehen wos Packete für Sarge noch gibt.
Danke vorerst!
Richard Lechner
>> obelix:~# mii-tool eth1
>> SIOCGMIIPHY on 'eth1' failed: Operation not supported
>
> mii-tool *UND* ethtool, bitte. Einige alte Karten funktionieren nur mit
> mii-tool, neuere Karten lassen sich nur mit ethtool ansprechen.
Zu ethtool siehe anderes Posting.
Habe gestern vor dem Dump noch schnell wondershaper installiert und heute
mal nachgesehen. Er teilt auf die drei Queues auf, keine dropped und keine
overlimits. Würde meinen eine zu hohe Last kann es auch nicht sein?
obelix:~# wondershaper eth1
qdisc cbq 1: rate 100000Kbit (bounded,isolated) prio no-transmit
Sent 42156948885 bytes 29054978 pkts (dropped 0, overlimits 0)
borrowed 0 overactions 0 avgidle 80 undertime 0
qdisc sfq 10: parent 1:10 limit 128p quantum 1514b perturb 10sec
Sent 66590461 bytes 1009034 pkts (dropped 0, overlimits 0)
qdisc sfq 20: parent 1:20 limit 128p quantum 1514b perturb 10sec
Sent 41180001915 bytes 27364352 pkts (dropped 0, overlimits 0)
qdisc sfq 30: parent 1:30 limit 128p quantum 1514b perturb 10sec
Sent 910352046 bytes 681490 pkts (dropped 0, overlimits 0)
qdisc ingress ffff: ----------------
Sent 2435805759 bytes 19713799 pkts (dropped 0, overlimits 0)
class cbq 1: root rate 100000Kbit (bounded,isolated) prio no-transmit
Sent 4463 bytes 102 pkts (dropped 0, overlimits 0)
borrowed 0 overactions 0 avgidle 80 undertime 0
class cbq 1:10 parent 1:1 leaf 10: rate 1000Mbit prio 1
Sent 66590461 bytes 1009034 pkts (dropped 0, overlimits 0)
borrowed 0 overactions 0 avgidle 80 undertime 0
class cbq 1:1 parent 1: rate 1000Mbit (bounded,isolated) prio 5
Sent 42156944422 bytes 29054876 pkts (dropped 0, overlimits 0)
borrowed 0 overactions 0 avgidle 80 undertime 0
class cbq 1:20 parent 1:1 leaf 20: rate 900000Kbit prio 2
Sent 41180001915 bytes 27364352 pkts (dropped 0, overlimits 0)
borrowed 0 overactions 0 avgidle 80 undertime 0
class cbq 1:30 parent 1:1 leaf 30: rate 800000Kbit prio 2
Sent 910352046 bytes 681490 pkts (dropped 0, overlimits 0)
borrowed 0 overactions 0 avgidle 80 undertime 0
Danke erstmal, hier scheint die Sonne und ich sitze im Büro und quäle mich mit
Computer rum. :-(
Richard Lechner
deb http://archive.debian.org/debian/ sarge main
Na wer sagts den! :-) Erstmal ein ethtool besorgt und freudigst gestartet:
obelix:~# ethtool eth1
Settings for eth1:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000033 (51)
Link detected: yes
Hmmm, sieht normal aus? Manual gelesen:
obelix:~# ethtool -acg eth1
ethtool: bad command line argument(s)
Ok, ein Versuch wars wert.
obelix:~# ethtool -a eth1
Pause parameters for eth1:
Cannot get device pause settings: Operation not supported
Pffffff.
obelix:~# ethtool -c eth1
Coalesce parameters for eth1:
Cannot get device coalesce settings: Operation not supported
Tssssss.?
obelix:~# ethtool -g eth1
Ring parameters for eth1:
Cannot get device ring settings: Operation not supported
Gfrast depperts!!
obelix:~# ethtool -i eth1
driver: r8169
version: 2.2LK
firmware-version:
bus-info: 0000:00:0d.0
Na wenigsten ein paar Daten!
Was wolltest du eigentlich wissen? Ah, Offloading!
Nochmal das Manual lesen:
obelix:~# ethtool -k eth1
Offload parameters for eth1:
rx-checksumming: on
tx-checksumming: off
scatter-gather: off
tcp segmentation offload: off
Offload ist off aber die Checksummbildung differiert!? Soll ich da mal drehen?
Danke erstmal!
Richard Lechner
> Äh, Debian Sarge <http://www.debian.org/releases/sarge/> ist *uralt*.
> Es gibt nicht einmal Security-Updates mehr, IIRC.
>
>> Kacke das! Mal sehen wos Packete für Sarge noch gibt.
>
> Quellcode besorgen (<http://packages.debian.org/ethtool>) ein
> '.deb'-Paket bauen.
Sarge funktioniert, das Upgrade nicht.
Danke, archiv.debian.org gefunden.
Simon Krahnke
> obelix:~# apt-get install ethtool
>
> Err http://ftp.de.debian.org sarge/main ethtool 2-1
> 404 Not Found
>
> Grrr, immer dieser Updatewahn! So schnell wie die wechseln kann ich meine
> Server nicht nachziehen! Kacke das! Mal sehen wos Packete für Sarge noch gibt.
Ich würde einfach mal apt-get update probieren, das sieht eher so aus,
als ob deine Paketliste für sarge veraltet wäre.
mfg, simon .... l
Richard Lechner
>> obelix:~# apt-get install ethtool
>>
>> Err http://ftp.de.debian.org sarge/main ethtool 2-1
>> 404 Not Found
>>
>> Grrr, immer dieser Updatewahn! So schnell wie die wechseln kann ich meine
>> Server nicht nachziehen! Kacke das! Mal sehen wos Packete für Sarge noch gib
>
> Ich würde einfach mal apt-get update probieren, das sieht eher so aus,
> als ob deine Paketliste für sarge veraltet wäre.
Danke, archive.debian.org gefunden.
Richard Lechner
...viel ethtoll-spezifisches.
Antworte mir selbst weil es egal ist ob ich das oben tue oder hier, die
Statistik gehört noch zur oberen Antwort also hier:
obelix:~# ethtool -S eth1
NIC statistics:
tx_packets: 1653065773
rx_packets: 1013669301
tx_errors: 0
rx_errors: 0
rx_missed: 0
align_errors: 0
tx_single_collisions: 0
tx_multi_collisions: 0
unicast: 1013191191
broadcast: 478110
multicast: 98
tx_aborted: 0
tx_underrun: 0
Sieht eigentlich gut aus?
Naja, seit einer Stunde kommen Mails mit Fotos aus Brasilien hier an die
zwischen 5 und 8 MB groß sind. Nun ist schon die dritte Mail doppelt da,
irgendwie braucht er für manche Mails so lange dass ers gleichzeitig? nochmal
abholt und dann doppelt hier einsortiert. Messageheader sind gleich, Mails
wurden jeweils nur einmal empfangen.
Also irgendwas fällt da auseinander, aber warum gibts keine errors im Treiber
oder wo immer?!
Ratlos im Büro....
Richard Lechner
Test mit wget gestartet:
obelix:~# wget ftp://ftp.inode.at/speedtest
--16:23:00-- ftp://ftp.inode.at/speedtest
=> `speedtest'
Resolving ftp.inode.at... 195.58.170.125
Connecting to ftp.inode.at[195.58.170.125]:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done. ==> PWD ... done.
==> TYPE I ... done. ==> CWD not needed.
==> PASV ... done. ==> RETR speedtest ... done.
Length: 19,605,381 (unauthoritative)
100%[==================================================>] 19,605,381 7.53M/s
16:23:03 (7.52 MB/s) - `speedtest' saved [19605381]
Also 3 Sekunden für fast 20 MB mit FTP, irgendwie schliesse ich Frameprobleme
da aus! Kann der Fehler durch das POP3 Protokol verursacht werden?
Erscheint mir seltsam, kann es sein dass jemand lauscht und die Kapazität nicht
hat? Die mit ihrem Überwachungswahn? Haben die Jungs das "Können" oder nur die
Mittel? Hat jemand einen Kontakt und könnte mal nach fragen?
Inoffiziell, natürlich.
Bin ratlos.
Dominique Görsch
Richard Lechner schrieb:
> Danke, archive.debian.org gefunden.
was nichts daran ändert, dass dein Sarge total veraltet ist, aus dem
Support ist und nicht einmal mehr mit Security-Updates versorgt wird. So
etwas auf einem öffentlich erreichbaren Server ist schon grob fahrlässig.
Gruß
Dominique Görsch
Florian Weimer
> Also irgendwas fällt da auseinander, aber warum gibts keine errors im Treiber
> oder wo immer?!
Die Fehler könnten bei der Gegenstelle stehen. Wenn aber GE
ausgehandelt wurde, sind typische Fehler wie Duplex Mismatches aber
recht ungewöhnlich. Möglicherweise liegt's am RX Checksum Offloading,
aber das ist sehr spekulativ. An Bugs in den sarge-Kerneln erinnere
ich mich nicht mehr. 8-/
Marc Haber
>Heiko Schlenker writes:
>> Äh, Debian Sarge <http://www.debian.org/releases/sarge/> ist *uralt*.
>> Es gibt nicht einmal Security-Updates mehr, IIRC.
>>
>>> Kacke das! Mal sehen wos Packete für Sarge noch gibt.
>>
>> Quellcode besorgen (<http://packages.debian.org/ethtool>) ein
>> '.deb'-Paket bauen.
>
>Sarge funktioniert,
Nack. Es gibt keinen Security-Support mehr. Sowas am öffentlichen
Internet zu betreiben ist mindestens fahrlässig.
>das Upgrade nicht.
Gut, dass das mein Serverpark nicht weiß.
Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Richard Lechner
Laut Provider sind keine Fehler am Switchport ersichtlich.
Habe auch das rx-checksumming auf Off gestellt, leider keine Änderung.
Jetzt habe ich noch über verschlüsselte IMAP-Verbindungen getestet und die
Geschwindigkeit ist da nicht höher. Also das Mithören auf der Leitung würde
bei IMAPS ja keinen Sinn ergeben.
Provider meint jetzt es könnte die Netzwerkkarte sein und ich soll "rescue"
starten und dann testen. Damit wären wir aber länger Offline, sehr dumm das.
Ausserdem geht mir nicht ein wieso das bei einem wget nicht auftritt?
Auf der anderen Seite verstehe ich nicht wieso eine Anwendung zu Segment-
verlusten im TCP/IP führen kann?
Danke.
Detlef
> Ausserdem geht mir nicht ein wieso das bei einem wget nicht auftritt?
Mir auch nicht.
Falls 9/tcp (discard) auf einem Zielrechner geht:
dd if=/dev/zero | netcat -p 9 adresse o
> Auf der anderen Seite verstehe ich nicht wieso eine Anwendung zu Segment-
> verlusten im TCP/IP führen kann?
Ich auch nicht.
Die Anwendung liegt _deutlich_ höher.
Mach erstmal nen netcat auf discard, mach das mit dd um den Durchsatz
zu sehen und dann zieh mal nen wireshark trace.
Darauf kann man aufbauen.
Alles andere ist Spekulation.
Roman Racine
> Laut Provider sind keine Fehler am Switchport ersichtlich.
> Habe auch das rx-checksumming auf Off gestellt, leider keine Änderung.
> Jetzt habe ich noch über verschlüsselte IMAP-Verbindungen getestet und die
> Geschwindigkeit ist da nicht höher. Also das Mithören auf der Leitung
> würde bei IMAPS ja keinen Sinn ergeben.
>
> Provider meint jetzt es könnte die Netzwerkkarte sein und ich soll
> "rescue" starten und dann testen. Damit wären wir aber länger Offline,
> sehr dumm das.
>
> Ausserdem geht mir nicht ein wieso das bei einem wget nicht auftritt?
> Auf der anderen Seite verstehe ich nicht wieso eine Anwendung zu Segment-
> verlusten im TCP/IP führen kann?
Wie gross sind die Dateien, die du vom Webserver herunterlädst?
Wenn du SMTP machst, sind die Antwortpakete des Servers in der Regel sehr
klein, da die Payload vom Client zum Server läuft. Wenn du Mails via POP3
herunterlädst, ist es genau umgekehrt, d.h. die TCP-Pakete schöpfen den
maximalen Rahmen in der Regel aus. Wenn das herunterladen grosser Dateien
über den Webserver gehen sollte, ist das allerdings keine Erklärung für
deine Probleme.
- Kannst du ein clientseitiges Problem ausschliessen?
- Hat dein Server möglicherweise mehrere Netzwerkinterfaces, so dass du
probeweise auch ein anderes benützen könntest?
Gruss
Roman°
Detlef
> Wie gross sind die Dateien, die du vom Webserver herunterlädst?
Falls Du bitte mal ein Lehrbuch zu Rate ziehst (sowas existiert, u.a.
bei Deinem Arbeitgeber in der Universtitätsbücherei) solltest Du
wissen, daß das irrelevant ist.
Punkt.
Eine TCP Verbindung geht oder sie geht nicht.
Pakete werden in Festnetzen heil übertragen oder nicht.
Und bevor wir hier noch mehr im Nebel rumstochern und rumschwallen,
täte Richard gut daran, etwa mit einem Netcat einen banalen Bytestrom
auf eine TCP Verbindung zu jagen und diese mitzuschneiden.
Und entweder treten dann da Fehler auf, dann kann man dem auch
nachgehen. Oder es treten da _keine_ Fehler auf, dann ist der
naheliegende Schritt, die Anwendungsschicht mal näher anzuschauen.
Richard hat im übrigen in dem von Dir zitierten (und offenbar nicht
gelesenen) Posting expressis verbis darauf hingewiesen, daß wget
fehlerfrei läuft.
Sofern Du wget verstanden hättest (das ist offenbar nicht der Fall),
wüsstest Du, daß die von Dir ins Feld geführte Asymmetrie von
Paketlängen bei POP und wget durchaus ähnlich ist.
O.k., ich habe einen konkreten Vorschlag zur Analyse gemacht.
Was war bitte _Dein_ Beitrag?
Es tut mir leid, aber Richard hat um Hilfe gebeten. Ich denke nicht,
daß ihm Laiengeschwafel weiterhilft.
Detlef
>
> - Kannst du ein clientseitiges Problem ausschliessen?
Noch was: Auch bei POP3 kann man wireshark mitlaufen lassen.
Wenn man das Fehlverhalten nur mit POP3 sicher reproduzieren kann,
ist das ja nun die denkbar leichteste Übung.
Da laufen ja nun keine MByte drüber, und daß ich mal einen TCP Traces
von einigen hundert Paketen durchflöhen mußte, ist zwar nun nicht
gerade jede Stunde vorgekommen, aber hin und wieder durchaus.
Und da kann man nun reden wie man will, fehlerhafte Conversations
lassen sich nun am zuverlässigsten durch Traces analysieren. Alles
andere kostet sehr viel Zeit (ich sehe diesen Thread jetzt schon den
fünften Tag, im Ernstfall würde ein Chef da mal ganz langsam nervös)
und ist nicht wirklich zielführend.
Richard Lechner
>> Ausserdem geht mir nicht ein wieso das bei einem wget nicht auftritt?
>
> Mir auch nicht.
>
> Falls 9/tcp (discard) auf einem Zielrechner geht:
>
> dd if=/dev/zero | netcat -p 9 adresse o
so ähnlich :-)
dd if=/dev/zero | netcat adresse 9
vom DSL:
835584 Bytes (836 kB) kopiert, 7,10401 Sekunden, 118 kB/s
von einem RZ:
33136640 Bytes (33 MB) kopiert, 3,5602 Sekunden, 9,3 MB/s
von hier [DSL] den Dump raufcopiert mit scp:
discard 100% 1306KB 100.5KB/s 00:13
Also beim senden mit SMTP gehts auch mit 90 - 100 KB/s. Damit könnten wir gut
leben.
>> Auf der anderen Seite verstehe ich nicht wieso eine Anwendung zu Segment-
>> verlusten im TCP/IP führen kann?
>
> Ich auch nicht.
>
> Die Anwendung liegt _deutlich_ höher.
>
> Mach erstmal nen netcat auf discard, mach das mit dd um den Durchsatz
> zu sehen und dann zieh mal nen wireshark trace.
>
> Darauf kann man aufbauen.
>
> Alles andere ist Spekulation.
Der Dump:
http://www.netprojects.at/fileadmin/discard
Da hat er auch viele Checksum incorrect und macht auch einige Retransmissions
aber er bricht weit nicht so ein wie mit dem dovecot.
Danke.
Detlef
> Der Dump:
>
> http://www.netprojects.at/fileadmin/discard
>
> Da hat er auch viele Checksum incorrect und macht auch einige Retransmissions
Puh, ich bin zwar zugegebenermaßen etwas aus der Übung, aber ich
stolpere gerade arg über die multiple ACKs mit ACK 163251 ab Paket
136.
Vor allem haben da die Pakete serienweise die Länge 0. Also reine ACKs
ohne Daten.
Ist da der Dupackthreshold auf der Clientseite irgendwo jenseits von
gut und böse?
Was ich so handelsüblich von TCP/Reno kenne, ist der meist 3.
Da sollte doch der Client nach 3 gleichen ACKs mal langsam mit ner
Sendewiederholung /Go Back N starten? Wartet da irgendwer ernstlich
auf nen Timeout?
Hast Du mal nen Client mit anderem Betriebssystem / anderer Socket-
Implementierung? Nur mal so als Bauchgefühl.
Richard Lechner
>> Wie gross sind die Dateien, die du vom Webserver herunterlädst?
....
> Sofern Du wget verstanden hättest (das ist offenbar nicht der Fall),
> wüsstest Du, daß die von Dir ins Feld geführte Asymmetrie von
> Paketlängen bei POP und wget durchaus ähnlich ist.
Um die Asymmetrie zu testen habe ich mal von einem anderen Server eine
Datei runter geladen und vice versa.
Erst runter:
monster:~# wget http://www.netprojects.at/fileadmin/ACCESSRT.CAB
--21:44:58-- http://www.netprojects.at/fileadmin/ACCESSRT.CAB
=> `ACCESSRT.CAB'
Auflösen des Hostnamen »www.netprojects.at«.... 88.198.180.21
Verbindungsaufbau zu www.netprojects.at|88.198.180.21|:80... verbunden.
HTTP Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 35.258.476 (34M) [text/plain]
100%[================================>] 35.258.476 6.21M/s ETA 00:00
21:45:03 (6.38 MB/s) - »ACCESSRT.CAB« gespeichert [35258476/35258476]
Dann quasi rauf:
obelix:~# wget http://www.maridelli.at/getit/ACCESSRT.CAB
--21:35:35-- http://www.maridelli.at/getit/ACCESSRT.CAB
=> `ACCESSRT.CAB.1'
Resolving www.maridelli.at... 78.46.68.139
Connecting to www.maridelli.at[78.46.68.139]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 35,258,476 [application/x-cab]
100%[=================================>] 35,258,476 9.66M/s ETA 00:00
21:35:39 (9.68 MB/s) - `ACCESSRT.CAB.1' saved [35258476/35258476]
Ich bin jetzt noch auf das gestoßen:
Linux: Window Scaling on the Internet
http://kerneltrap.org/node/6723
Mein Kernel:
2.6.17.11-vs2.0.2
Aber das ziehe ich mir morgen rein, heute habe ich genug von dem Zeuch.
Ich gehe jetzt auf ein Weißbier oder auch zwei.
Prost und vielen Dank!
Richard Lechner
>> Da hat er auch viele Checksum incorrect und macht auch einige Retransmissions
>
> Puh, ich bin zwar zugegebenermaßen etwas aus der Übung, aber ich
> stolpere gerade arg über die multiple ACKs mit ACK 163251 ab Paket
> 136.
>
> Vor allem haben da die Pakete serienweise die Länge 0. Also reine ACKs
> ohne Daten.
>
> Ist da der Dupackthreshold auf der Clientseite irgendwo jenseits von
> gut und böse?
>
> Was ich so handelsüblich von TCP/Reno kenne, ist der meist 3.
> Da sollte doch der Client nach 3 gleichen ACKs mal langsam mit ner
> Sendewiederholung /Go Back N starten? Wartet da irgendwer ernstlich
> auf nen Timeout?
>
> Hast Du mal nen Client mit anderem Betriebssystem / anderer Socket-
> Implementierung? Nur mal so als Bauchgefühl.
Client hier ist: 2.6.28.7 und hinter einem NAT-Router.
Aber damit dürfte es nicht zu tun haben weil die Probleme auch bei den Kunden
mit vorwiegend Windwos auftreten. Teilweise meldet Outlook bei manchen in
letzter Zeit einen Timeout beim abholen.
Und auch hinter Linuxfirewalls das selbe Problem, liegt definitiv am Server
weil z.B. GMX mit 400 KB/s downloadet.
Geht aber schon länger so, kann nicht mehr genau sagen wann es mir das erste
Mal aufgefallen ist, nur die Timeouts sind neu und darum muss ich mich darum
kümmern.
Dupackthreshold? Da steige ich jetzt langsam aus, das google ich morgen, jetzt
reichts mir für heute und ich geh ein oder zwei Weißbier(e) drinken.
Danke.
Detlef
> On 31 Mrz., 21:14, Richard Lechner <r.lech...@gmx.net> wrote:
>
> > Der Dump:
>
> >http://www.netprojects.at/fileadmin/discard
>
> > Da hat er auch viele Checksum incorrect und macht auch einige Retransmissions
>
> Puh, ich bin zwar zugegebenermaßen etwas aus der Übung, aber ich
> stolpere gerade arg über die multiple ACKs mit ACK 163251 ab Paket
> 136.
>
> Vor allem haben da die Pakete serienweise die Länge 0. Also reine ACKs
> ohne Daten.
>
> Ist da der Dupackthreshold auf der Clientseite irgendwo jenseits von
> gut und böse?
>
> Was ich so handelsüblich von TCP/Reno kenne, ist der meist 3.
> Da sollte doch der Client nach 3 gleichen ACKs mal langsam mit ner
> Sendewiederholung /Go Back N starten? Wartet da irgendwer ernstlich
> auf nen Timeout?
>
Habe Paket 140 übersehen. Läuft also korrekt, wie sich das gehört.
Aber was ist 204 bis 208? Wieso orgelt da ein Server fünfmal dasselbe
ACK Paket raus? Könnte jetzt aber ein normales Reno-Verhalten sein.
(Fast Recovery, da bleibt ACK kurz "stehen".)
Also _der_ Trace sieht noch ganz manierlich aus.
Hast Du mal zum Vergleich einen Mitschnitt von POP3?
Detlef
> Detlef writes:
> >> Wie gross sind die Dateien, die du vom Webserver herunterlädst?
>
> ....
>
> > Sofern Du wget verstanden hättest (das ist offenbar nicht der Fall),
> > wüsstest Du, daß die von Dir ins Feld geführte Asymmetrie von
> > Paketlängen bei POP und wget durchaus ähnlich ist.
>
> Um die Asymmetrie zu testen habe ich mal von einem anderen Server eine
> Datei runter geladen und vice versa.
>
> Erst runter:
>
> --21:44:58-- http://www.netprojects.at/fileadmin/ACCESSRT.CAB
> => `ACCESSRT.CAB'
> Auflösen des Hostnamen »www.netprojects.at«.... 88.198.180.21
> HTTP Anforderung gesendet, warte auf Antwort... 200 OK
> Länge: 35.258.476 (34M) [text/plain]
>
> 100%[================================>] 35.258.476 6.21M/s ETA 00:00
>
> 21:45:03 (6.38 MB/s) - »ACCESSRT.CAB« gespeichert [35258476/35258476]
>
> Dann quasi rauf:
>
> --21:35:35-- http://www.maridelli.at/getit/ACCESSRT.CAB
> => `ACCESSRT.CAB.1'
> Resolvingwww.maridelli.at... 78.46.68.139
> HTTP request sent, awaiting response... 200 OK
> Length: 35,258,476 [application/x-cab]
>
> 100%[=================================>] 35,258,476 9.66M/s ETA 00:00
>
> 21:35:39 (9.68 MB/s) - `ACCESSRT.CAB.1' saved [35258476/35258476]
>
> Ich bin jetzt noch auf das gestoßen:
>
> Linux: Window Scaling on the Internethttp://kerneltrap.org/node/6723
>
> Mein Kernel:
> 2.6.17.11-vs2.0.2
Oh, das wird der schönste Flamewar der letzten 10 Jahre ;-)
Meine Meinung: Window Scaling solltest Du sein lassen.
Es mag Dir was bringen - aber der Rest der Welt wird's Dir danken ;-)
>
> Aber das ziehe ich mir morgen rein, heute habe ich genug von dem Zeuch.
> Ich gehe jetzt auf ein Weißbier oder auch zwei.
Wie jetzt ;-)
Aber gut, ich bin hier seit 6.00 Uhr am Wirbeln, und so ganz langsam
werde ich auch etwas fahrig. (Wie man am übersehenen Reno-Verhalten
eben sieht. Gute Güte.)
Kurz zum Dupackthreshold: TCP erkennt Paketverluste sinnvollerweise
nicht am Timeout sondern an Mehrfachbestätigungen des letzten
erfolgreich zugestellten Pakets.
Man hat lange darüber gestritten, warum TCP gerade bei 3 Bestätigungen
einen Verlust feststellt, dann hat man definiert, daß eben ein Verlust
bei _genau_ 3 Bestätigungen entdeckt wird, aber der Wert von 3 sollte
zweckmäßigerweise flexibel gehandhabt werden ;-)
RFC 3517
RFC 3782
wenn ich es richtig sehe. Bin da etwas raus.
>
> Prost und vielen Dank!
Marc Haber
>On 31 Mrz., 20:11, Roman Racine <roman.rac...@gmx.de> wrote:
>> - Kannst du ein clientseitiges Problem ausschliessen?
>
>Noch was: Auch bei POP3 kann man wireshark mitlaufen lassen.
... dann möchte man den Dump aber nicht publizieren.
Detlef
> Detlef <detlef.bo...@web.de> wrote:
> >On 31 Mrz., 20:11, Roman Racine <roman.rac...@gmx.de> wrote:
> >> - Kannst du ein clientseitiges Problem ausschliessen?
>
> >Noch was: Auch bei POP3 kann man wireshark mitlaufen lassen.
>
> ... dann möchte man den Dump aber nicht publizieren.
Um der Wahrheit die Ehre zu geben: Ich habe mich schon gestern abend
gefragt, warum dieser Deppenkommentar nicht gekommen ist. Egal von wem
auch immer.
man tcpdump
Insbesondere möchte man verstehen, daß die Header von Interesse ist
und nicht die Payload.
Im übrigen gilt auch hier der Spruch: Wasch mir den Pelz aber mach
mich nicht naß.
Marc Haber
>On 1 Apr., 14:04, Marc Haber <mh+usenetspam0...@zugschl.us> wrote:
>> Detlef <detlef.bo...@web.de> wrote:
>> >On 31 Mrz., 20:11, Roman Racine <roman.rac...@gmx.de> wrote:
>> >> - Kannst du ein clientseitiges Problem ausschliessen?
>>
>> >Noch was: Auch bei POP3 kann man wireshark mitlaufen lassen.
>>
>> ... dann möchte man den Dump aber nicht publizieren.
>
>Um der Wahrheit die Ehre zu geben: Ich habe mich schon gestern abend
>gefragt, warum dieser Deppenkommentar nicht gekommen ist. Egal von wem
>auch immer.
Du bist Dir aber schon bewusst, dass sowohl das von tcpdump -w als
auch das von tshark -w ohne Beeinflussung der snaplen geschriebene
File bei POP3 im Regelfall eben doch Usernamen und Passwort enthält,
und dass Du Dich mal wieder nur aufplusterst?
Grüße
Marc, der im Gegensatz zu Dir nicht nur manpages gelesen sondern
wirklich binaries aufgerufen hat
Detlef
Marc Haber schrieb:
> Detlef <detlef...@web.de> wrote:
> >On 1 Apr., 14:04, Marc Haber <mh+usenetspam0...@zugschl.us> wrote:
> >> Detlef <detlef.bo...@web.de> wrote:
> >> >On 31 Mrz., 20:11, Roman Racine <roman.rac...@gmx.de> wrote:
> >> >> - Kannst du ein clientseitiges Problem ausschliessen?
> >>
> >> >Noch was: Auch bei POP3 kann man wireshark mitlaufen lassen.
> >>
> >> ... dann möchte man den Dump aber nicht publizieren.
> >
> >Um der Wahrheit die Ehre zu geben: Ich habe mich schon gestern abend
> >gefragt, warum dieser Deppenkommentar nicht gekommen ist. Egal von wem
> >auch immer.
>
> Du bist Dir aber schon bewusst, dass sowohl das von tcpdump -w als
> auch das von tshark -w ohne Beeinflussung der snaplen geschriebene
> File bei POP3 im Regelfall eben doch Usernamen und Passwort enthält,
> und dass Du Dich mal wieder nur aufplusterst?
Ich sehe nur einen, der sich hier gerade aufplustert.
Wenn Du meinst, das Problem ohne Trace lösen zu können, dann tue es
einfach und hör auf hier anzugeben.
Es ist nun wirklich kein Thema, in einem Trace Passwörter und
Benutzernamen zu verblenden.
Und wenn Du soviel professionelle Erfahrung hast, wie Du immer
behauptest, weißt Du genauso gut wie ich, daß ohne vernünftie Traces
und Analysen einem Problem nicht beizukommen ist.
Aber wenn Du nicht den Anspruch hast $OP zu helfen, dann kannst Du
hier natürlich bequem den lauten machen.
Richard Lechner
Ich war unterwegs und hatte keine Zeit. Das Problem brennt nicht aber es
sollte sich halt jemand (ich) darum kümmern. :-(
> Hast Du mal zum Vergleich einen Mitschnitt von POP3?
http://www.netprojects.at/fileadmin/pop3
Die Mail hat 2,8 MB und er hat über 2 Minuten für den Download gebraucht.
Den Dump habe ich mit scp auf den Server gestellt und dafür hat der Client
bei 3 MB rund 34 Sekunden gebraucht. Also am ADSL kanns kaum liegen.
pop3 100% 3100KB 91.2KB/s 00:34
Danke.
Detlef
> Detlef writes:
>
> Ich war unterwegs und hatte keine Zeit. Das Problem brennt nicht aber es
> sollte sich halt jemand (ich) darum kümmern. :-(
>
> > Hast Du mal zum Vergleich einen Mitschnitt von POP3?
>
> http://www.netprojects.at/fileadmin/pop3
>
In dem sehe ich jetzt aber keine Auffälligkeiten. (Was nicht heißt,
daß da keine sind. Ich schaue mir das auch morgen und am Wochenende
nochmal
in Ruhe an.)
Insbesondere sehe ich jetzt im Sequenznummernplot keine großen Lücken
oder Sprünge sondern einen gleichmäßigen Anstieg. Wenn auch eben mit
200 kBit/s oder weniger.
Die "previous segment lost" scheinen mir normale Stauverluste vom Reno-
Probing zu sein.
Was mich jetzt aber doch etwas wundert, ist die Zahl der Dupacks.
Das muß ich mir jetzt mal am Tag und in Ruhe durchsehen, aber wie ich
gestern schon schrieb: Reno macht normalerweise nach 3 ACKs go back n.
Im Trace sieht es so aus, als ließe sich das Ding zum Teil "ganz schön
bitten", ich meine da vier ACKs und mehr gesehen zu haben, bis der
Server endlich mit Sendewiederholugen anfing.
Ich will mir mal anschauen, aber da muß ich mal ins Manual von
tcptrace sehen, damit habe ich nur mal ganz kurz gearbeitet, ob ich
mal sehen kann, wie groß Dein Sendefenster auf dem Server jeweils ist.
Ich möchte verstehen, aber dazu bin ich jetzt zu müde, wie weit Dein
Server beim
Paketausfall jeweils "nach hinten springt". Wenn der Server da ne
Echternacher Springprozession veranstaltet, also bei jedem
Paketausfall gleich die letzten 100 Pakete neu sendet, geht der
Durchsatz natürlich in die Knie.
Aber dazu brauche ich etwas Zeit, um das durchzusehen.