Checking internet connection without a winbox
Gene Heskett
gene.heskett at verizon.net
Sun Jul 2 23:31:16 UTC 2006
Aaron Konstam wrote:
> On Sun, 2006-07-02 at 20:17 +0300, Dotan Cohen wrote:
>> On 02/07/06, Les Mikesell <lesmikesell at gmail.com> wrote:
>>> Run traceroute to various places and note where the delays or
>>> dropped packets start. Normally you will see a response from
>>> every router in the path and the round trip time for three
>>> packets. Some may block the ports used or the icmp response
>>> so a '*' response isn't necessarily a problem, especially
>>> if it picks up on subsequent hops. Keep in mind that the
>>> time is for the round trip and problems can happen in either
>>> direction. If you see consistent delays or drops happening
>>> somewhere, paste the traceroute into an email to your ISP.
>>>
>> Thanks, Les. I started doing mtr, and discovered that the router is
>> dropping ~2% of the packets, the infrastructure is dropping ~14% of
>> the packets, and the ISP is dropping ~8% of the packets. all the other
>> hops are losing between 2% to 10% as well. What values are considered
>> normal? Thanks.
>>
I'd say its normal, and expected when the mtr utility uses its default
ping interval of 1 second. I controlled that by increaseing the ping
interval to 5 seconds, at which point all the random losses (some as
high as 40%) it reported before went away. 1 second to get all the
responses from a site that may be 30 hops away is a very un-realistic
assumption on the part of the mtr author, it does not match the real
world when it is apparently throwing away any ping return more than 1
second old.
I'd make a SWAG that mtr, when checking the echo's, cuts the time
permissible to recognize a legit echo down to that same second, and if
its not back by then, its a packet loss. By increasing the ping times
to 5 seconds, aka "mtr -i 5 location-to-ping" then all the packets do
get back in time and the losses are then zero across the board. Now if
mtr were to recognize a packet return as a packet from a previous ping,
that would be much more realistic. But from the clues its giving, it is
not checking for any packet thats not the result of the currently issued
icmp ping.
>> Dotan Cohen
>> http://gmail-com.com
> If you google internet transfer speed you should find sites that allow
> you to test your upload and download speeds. I just did that and a site
> with pitstop in its name, for example, provides that free service.
> --
> =======================================================================
> We all agree on the necessity of compromise. We just can't agree on when
> it's necessary to compromise. -- Larry Wall
> =======================================================================
> Aaron Konstam telephone: (210) 656-0355 e-mail: akonstam at sbcglobal.net
>
--
Cheers, Gene
More information about the users
mailing list