Error Message

[Kenneth Brody]

Quoting Fairlight (Fri, 30 Nov 2007 11:58:21 -0500):

> On Fri, Nov 30, 2007 at 11:26:29AM -0500, Jay Ashworth may or may not have
[... Windows' "ping -t" ...]
>> For our purposes, which are mostly "what percentage of packets are
>> being dropped on this link", what do you need the seq numbers for,
>> Mark?
>
> Because that's not how I'd be utilising it, were it me.
>
> When I have a question about correlative events in networking, if I'm
> testing connectivity with ping, I'll let it run continuously from *nix.
> If there are gaps in realtime in the sequence numbers -while- a "network
> event" (ie., problem) is occurring, I can see immediately that it's not
> just a general loss, it's a direct correlation at that particular point in
> time; there is a direct and immediate correlative match.
>
> If you just let Windows' ping run endlessly, have an event, and break ping
> later for your report, there's no guarantee of direct correlation because
> you've not observed one at the same time (due to inability through lack of
> SEQ), unless you get lucky and get a variance in latency that happens to
> show up during the outage and lets you know that the thing is still alive.
>
> Breaking it at the end and seeing "some" loss doesn't tell you -when- the
> loss occurred.  Hence, no correlation, and far less substantial proof that
> there's a connection (or not) to the event being diagnosed.  All it tells
> you is that there was an issue at some point, but not that there was an
> issue -during that event-.

(Sorry, not much really that could be snipped.)

But, the way that Window's "ping -t" works, it will show you which
packets went missing, in-line.  Unfortunately, I don't have any
intermittent lost packets at the moment, but what you would see is,
within the "reply from ..." series, some "request timed out" messages.

So, you might have something like:

Reply from 192.168.1.101: bytes=32 time=2ms TTL=63
Reply from 192.168.1.101: bytes=32 time=<1ms TTL=63
Reply from 192.168.1.101: bytes=32 time=2ms TTL=63
Reply from 192.168.1.101: bytes=32 time=2ms TTL=63
Reply from 192.168.1.101: bytes=32 time=143ms TTL=63
Request timed out.
Request timed out.
Request timed out.
Reply from 192.168.1.101: bytes=32 time=75ms TTL=63
Reply from 192.168.1.101: bytes=32 time=2ms TTL=63
Reply from 192.168.1.101: bytes=32 time=<1ms TTL=63
Reply from 192.168.1.101: bytes=32 time=2ms TTL=63

You can see exactly when the problem occurred -- about 20-25 seconds
ago, lasting about 15-20 seconds.

-- 
KenBrody at BestWeb dot net        spamtrap: <g8ymh8uf001 at sneakemail.com>
http://www.hvcomputer.com
http://www.fileProPlus.com