Responsetijd bij aantal hops erg traag

[Verwijderd]

Hallo lezers,


Ik had een vraagje mbt de responsetijden van een bepaalde tracerouting.
Ik heb voor mijn beroep snelle responsetijden nodig ivm met data die gelezen moet worden.
Dit is een standalone programma wat vrij licht is en weinig bandbreedte gebruikt op piekmomenten.
(lees: 50kb/s ) Mijn internet provider is UPC.

Nu is het zo adhv een visualtracerouting en in de CMD prompt de tracing/ping van mijn routing naar peter.yorkba.com het volgende resultaat geeft:

http://imageshack.us/photo/my-images/691/traceroutet.png/

Wat zou ik hieraan kunnen doen?
Flagtel op de hoogte brengen van dit euvel lijkt me voor de hand. Misschien nog meer tips?

Bedankt alvast voor de reacties

ps. Is deze routing standaard voor elke provider? Of je nu bij KPN (DSL lijn) of via glasvezel (UPC) of bij een andere provider zit? Wordt elk signaal dat naar de USA gaat via deze route geleidt buiten Nederland?

Kunnen jullie mij meer vertellen hoe ik dit kan oplossen?


Gr

[remco_k]

Zou het niet kunnen zijn dat er een satelliet link tussen zit die, door de grote afstanden, voor een natuurlijke vertraging zorgt die verder niet valt te optimaliseren?

Ik pak zomaar wat getallen, alles afgerond:
Snelheid van het licht (=snelheid van data transport naar satelliet): 300.000 km/s
Afstand satelliet<->aarde: 30.000 km.
Data verkeer gaat up en down, dus afgelegde afstand is 60.000 km.
Dat duurt dan precies 200 msec voordat je met je data pakketje weer aan land staat en duurt het vanuit jouw optiek minimaal het dubbele van die tijd (400 msec) voordat je antwoord krijgt.
Dan heb ik alleen niet extra vertragingen meegerekend in de systemen die ertussen zitten voordat het wordt verstuurd.

Wellicht hangt de satelliet lager, waardoor je onder de 200 msec uitkomt.
Maar optimaliseren in deze, gaat je niet zo snel lukken.

Kan ook zijn dat het allemaal via landlijnen gaat. Indirect kan je daarvoor dezelfde berekening pakken, alleen zijn de afstanden wat korter.

[ Voor 13% gewijzigd door remco_k op 12-09-2011 16:34 ]

[Verwijderd]

remco_k schreef op maandag 12 september 2011 @ 16:32:
Zou het niet kunnen zijn dat er een satelliet link tussen zit die, door de grote afstanden, voor een natuurlijke vertraging zorgt die verder niet valt te optimaliseren?

Ik pak zomaar wat getallen, alles afgerond:
Snelheid van het licht (=snelheid van data transport naar satelliet): 300.000 km/s
Afstand satelliet<->aarde: 30.000 km.
Data verkeer gaat up en down, dus afgelegde afstand is 60.000 km.
Dat duurt dan precies 200 msec voordat je met je data pakketje weer aan land staat en duurt het vanuit jouw optiek minimaal het dubbele van die tijd (400 msec) voordat je antwoord krijgt.
Dan heb ik alleen niet extra vertragingen meegerekend in de systemen die ertussen zitten voordat het wordt verstuurd.

Wellicht hangt de satelliet lager, waardoor je onder de 200 msec uitkomt.
Maar optimaliseren in deze, gaat je niet zo snel lukken.

Kan ook zijn dat het allemaal via landlijnen gaat. Indirect kan je daarvoor dezelfde berekening pakken, alleen zijn de afstanden wat korter.

Volgens mij gaat het via landlijnen en niet via satelliet.
Het gekke is dat de vertraging al begint in Engeland en volgens mij gaan zowiezo de lijnen daar naartoe via land.

[CyBeR]

Een satellietverbinding geeft je een round-trip latency van ruwweg 2000ms.

Dit gaat gewoon over transatlantische glasvezel. 200ms van hier naar de andere kant van de VS is een prima tijd. De rtt over de atlantische oceaan is al 100ms, en dan moet je nog naar de andere kant van de VS ook, wat een soortgelijke afstand is.

[M2M]

Een ping van minder dan 200 van / naar de US is vrij normaal. Maar misschien is het een idee om die amerikaanse server naar europa te trekken?

[Verwijderd]

CyBeR schreef op maandag 12 september 2011 @ 18:33:
Een satellietverbinding geeft je een round-trip latency van ruwweg 2000ms.

Dit gaat gewoon over transatlantische glasvezel. 200ms van hier naar de andere kant van de VS is een prima tijd. De rtt over de atlantische oceaan is al 100ms, en dan moet je nog naar de andere kant van de VS ook, wat een soortgelijke afstand is.

Hoi Cyber en M2M,

Zou jij eens een traceroute willen doen naar peter.yorkba.com?
En eens kijken of deze ook bij het knelpunt dezelfde waardes geeft als bij mij?

Even ter aanvulling van mijn vorige post van een jaar geleden.
http://gathering.tweakers...30780///beurs%2Chandelaar


Bedankt

[ Voor 11% gewijzigd door Verwijderd op 12-09-2011 19:50 ]

[CyBeR]

Ik heb 't geprobeerd vanuit vier verschillende netwerken en alles komt uiteindelijk via FLAG telecom in de VS terecht.

Rtt hier thuis (KPN VDSL): ~300ms
Rtt kantoor (KPN FttO): ~240ms
Rtt colo (ReasonNet GbE): ~250ms
Rtt colo (LeaseWeb FE): ~ 230ms


Overigens moet je niet uit die DNS naam afleiden dat de betreffende router in londen staat. Het kan ook de interface zijn die met londen verbonden is van een router in (aannemelijkerwijs) New York.

[ Voor 28% gewijzigd door CyBeR op 12-09-2011 20:25 ]

[M2M]

ongeveer 300ms hier (ziggo). Tot aan londen onder de 20 ms. Daarna rond de 250 - 300.

Ik denk ook niet dat je ping het probleem is. Mij lijkt het plausibeler dat de data ergens in een buffer blijft hangen. Misschien dat je even kunt checken met welk protocol de data verstuurd wordt?

[Bartjezz]

Ik heb even hier gepingd, en kom uit op een gemiddelde van 296ms

[Verwijderd]

M2M schreef op maandag 12 september 2011 @ 20:37:
ongeveer 300ms hier (ziggo). Tot aan londen onder de 20 ms. Daarna rond de 250 - 300.

Ik denk ook niet dat je ping het probleem is. Mij lijkt het plausibeler dat de data ergens in een buffer blijft hangen. Misschien dat je even kunt checken met welk protocol de data verstuurd wordt?

Hmmmm hier zeg je wat M2M.
Wat ik vaak zie is dat soms 1 a 2 seconden 'data' blijft hangen ergens en dan in een keer uitspuwd. MAW hij haalt alles in wat in de buffer is blijven hangen.
Hoe zou ik hier achter kunnen komen?

Hoe kom ik achter de protocol van de data van het programma? Gewoon vragen?

[Verwijderd]

Dus vele hier pingen tussen de 220 en 300 ms en loopt langs een vast aantal punten (oa flagtel).
Bedankt voor de pingtesten vrienden.

[Verwijderd]

Verwijderd schreef op maandag 12 september 2011 @ 20:47:
Wat ik vaak zie is dat soms 1 a 2 seconden 'data' blijft hangen ergens en dan in een keer uitspuwd. MAW hij haalt alles in wat in de buffer is blijven hangen.
Hoe zou ik hier achter kunnen komen?

1 a 2 seconden blijven hangen tijdens je traceroute is 9 van de 10 keer DNS lookup. Die zie je (dus) ook niet terug in je responsetijden.

Als ik naar het kaartje kijk uit de TS, dan zit de grote vertraging in de trans-Atlantische link, volkomen normaal dus.

Hoe kom ik achter de protocol van de data van het programma? Gewoon vragen?

Wireshark, netstat.

[Verwijderd]

Verwijderd schreef op maandag 12 september 2011 @ 20:55:
[...]

1 a 2 seconden blijven hangen tijdens je traceroute is 9 van de 10 keer DNS lookup. Die zie je (dus) ook niet terug in je responsetijden.

Als ik naar het kaartje kijk uit de TS, dan zit de grote vertraging in de trans-Atlantische link, volkomen normaal dus.


[...]

Wireshark, netstat.

Jeroen, heb je misschien enig idee welke commando's ik moet invoeren in de command prompt om een zo duidelijk mogelijk overzicht te krijgen van de statistieken?
~Netstat

[FatalError]

De latencies bij n traceroute (of pingen naar n willekeurig netwerk-component) zeggen erg weinig. Antwoorden op n ping is namelijk iets wat n bijzonder lage prioriteit heeft binnen n switch of router. Bovendien wordt routing in hardware gedaan terwijl n ping normaalgesproken naar de management CPU moet.
Zo is het normaal dat n pakketje dat door de router heen moet n vertraging heeft van minder dan n milliseconde terwijl n ping naar diezelfde router enkele 10-tallen milliseconden kan duren.

[Verwijderd]

FatalError schreef op maandag 12 september 2011 @ 21:46:
De latencies bij n traceroute (of pingen naar n willekeurig netwerk-component) zeggen erg weinig. Antwoorden op n ping is namelijk iets wat n bijzonder lage prioriteit heeft binnen n switch of router. Bovendien wordt routing in hardware gedaan terwijl n ping normaalgesproken naar de management CPU moet.
Zo is het normaal dat n pakketje dat door de router heen moet n vertraging heeft van minder dan n milliseconde terwijl n ping naar diezelfde router enkele 10-tallen milliseconden kan duren.

Heb je misschien suggesties wat ik kan doen om het beter te laten worden?

[CyBeR]

FatalError schreef op maandag 12 september 2011 @ 21:46:
De latencies bij n traceroute (of pingen naar n willekeurig netwerk-component) zeggen erg weinig. Antwoorden op n ping is namelijk iets wat n bijzonder lage prioriteit heeft binnen n switch of router. Bovendien wordt routing in hardware gedaan terwijl n ping normaalgesproken naar de management CPU moet.
Zo is het normaal dat n pakketje dat door de router heen moet n vertraging heeft van minder dan n milliseconde terwijl n ping naar diezelfde router enkele 10-tallen milliseconden kan duren.

Ten eerste, het woord 'een' heeft twee e's erin.

Ten tweede, dat klopt op zich wel maar het effect daarvan is niet supergroot. Belangrijker, de ping tijd naar de destination host wordt er niet door beinvloed.