Hi memed.
( {unwichtig} Hab ich irgendwo "Pinger" geschrieben? sry4that, da muss ich wohl schon mächtig übermüdet gewesen sein
{/unwichtig} )
Aber erstmal BIG THX , dass Du dir die Mühe gemacht und die Zeit genommen hast, um das "Problem" zu betrachten.
Ja, fand ich auch etwas erstaunlich, dass ICM's nach 70 sek. Verzögerung noch nicht verworfen wurden und das Echo zurückkam. Dass ICM's (Pings) im Allgemeinen auf den Routern mit der niedrigsten Priorität abgearbeitet (oder bei hoher Last auch schonmal absichtlich verworfen) werden um die Last zu senken bzw. der Preformance für die Datenpaketen zu Gute kommen zu lassen, ist (mir) bekannt. Dadurch kommt es vor, dass "Pings" manchmal wesentlich höhere laufzeiten als normale Datenpakete haben.
(So ich glaub jetzt hat's auch jeder Andere verstanden, der hier liesst
)
Warum die Ping-Pakete so lange gepuffert werden, da könnte ich selber nur rRaten / vermutungen anstellen.:
Ich könnte mir vorstellen, dass es da irgendwo eine "max-alive" Einstellung gibt, wo etwas schief gelaufen sein könnte. Bei einer momentanen höheren Auslastung stauen sich dann auch mit dei ICM's im Puffer und verstärken diesen Stau noch weiter. ...
Aber das ist nur eine Vermutung/Idee meinerseits. Ich kenn die eingesetzte Technik nicht so genau, dass ich wirklich eine schlüssige, fundierte Analyse durchführen könnte.
Was könnte bei der Fehleranalyse / Suche helfen?
Ich könnte:
- MTR's weiter tonnenweise in Ticket posten ...
(würde aber nicht helfen und die Mitarbeiter wären vermutlich eher generft
als erfreut, weil man mit den normalen MTR's nur das durchschnittliche Ergebis sieht)
- MTR-Serien machen, Beispiel:
*
charlie396 -- 22-09-2006
* (Diese MTR's sind vom letzten jahr und das damals bestehende Problem wurde behoben)
- 3D-Traces machen, mit Zeitachse. Also stundenlang davor sitzenbeiben und die
relevanten Bereiche per Screenshots festhalten. (Kann ich aber leider nur den Hinroute,
da ich ein soches Tool nicht für einen Linux-Server habe)
Beispiel:
http://www.globaltraders.de/3d-trace.jpg
- Ich könnte einen "sniffer" mit bei mir clientseitig ranhängen, einen endlos-ping Ping
auf die Gateway oder WinMTR laufen lassen, und die ICM-Echos mit Zeitstempel
in einer LOG-Datei erfassen. Anhand der stark verzögerten Echos (timestamp)
erkennt man dann die Zeiten wann und wie lange verzögert wurde.
(An einem brauchbaren Auswertungstool wird (glaube) bereits gearbeitet)
Beispiel:
http://wormaus.ath.cx/icm.txt (erfasstes Echon von "charlie396" )
Was davon wäre Brauchbar und was gibt es noch, womit ich unterstützen kann?
Die waren z.Bsp. interessant:
Code:
27. Jan 2007 22.25 - 23.15 Uhr
HOST: charlie396 Loss% Snt Last Avg Best Wrst StDev
1. static-ip-85-25-136-1.inaddr 8.1% 3000 0.6 6.2 0.5 4635. 113.6
2. static-ip-85-25-255-209.inad 49.8% 3000 1.6 18.4 1.4 18073 476.7
3. Intergenia.FRA-1-eth0-143.de 95.0% 3000 3961. 83.8 5.8 3961. 423.4
4. FRA-3-pos100.de.lambdanet.ne 7.8% 3000 0.5 1.7 0.4 2367. 45.9
5. Arcor-FRA.de.lambdanet.net 7.7% 3000 0.5 0.5 0.4 455.3 10.5
6. 145.254.16.181 8.0% 3000 0.7 6.2 0.7 540.9 27.4
7. han-145-254-18-82.arcor-ip.n 94.8% 3000 33703 259.1 9.5 33703 2695.8
8. bln-145-254-19-170.arcor-ip. 94.5% 3000 116.6 49.5 12.8 641.9 75.1
9. 145.254.5.138 94.8% 3000 45606 341.1 12.8 45606 3637.0
10. dslb-088-073-011-110.pools.a 8.1% 3000 16.1 22.8 14.8 19291 367.2
27. Jan 2007 22.55 - 23.45 Uhr
HOST: charlie396 Loss% Snt Last Avg Best Wrst StDev
1. static-ip-85-25-136-1.inaddr 8.0% 3000 0.6 3.0 0.5 1116. 34.1
2. static-ip-85-25-255-209.inad 52.0% 3000 1.6 18.7 1.4 17930 474.7
3. Intergenia.FRA-1-eth0-143.de 93.7% 3000 414.0 56.9 5.6 414.0 83.2
4. DUS-1-pos000.de.lambdanet.ne 93.6% 3000 71106 551.8 8.7 71106 5297.9
5. Intergenia-DUS2.de.lambdanet 8.1% 3000 11.6 6.3 4.4 156.0 6.3
6. static-ip-85-25-95-58.inaddr 7.9% 3000 3.6 6.1 3.5 2560. 56.6
7. root-a.serveftp.net 8.2% 3000 3.3 3.3 3.3 243.8 7.1
Was mir dabei noch auffällt und worauf ich mir momentan garkeinen "reim" machen kann ist, dass der letzte Ping gleich dem Peak ist.
Hat irgendjemand eine Idee dazu? *stutz*
