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 fedora-list mailing list