Re: Consistent asymetric latency on monitoring?

[Rick Ernst <nanog () shreddedmail com>]

Resent, since I responded from the wrong address:
---
The basic operation of IP SLA is as surmised; payload with timestamps
and other telemetry data is sent to a 'responder' which manipulates
the payload, including adding its own timestamps, and returns the
altered payload.

I had to do a mental walk-through, but I think I see how drift can
cause this. I'm going to generate some artificial data, graph it, and
see if it matches the general waveshape I'm seeing.

I purposefully have the traffic generators ntp syncing against the
responders. I thought that would keep the clocks more closely in sync.
I don't necessarily care if the time is 'right', just that it's the
same. What kind of difference should I expect if I sync both
generators and responders against the same source, or not sync the
responder? I'm thinking that having one source with constant drift may
be better than both devices trying to walk/correct the time.

Thanks for the input!


On Wed, Oct 21, 2009 at 8:01 PM, Rick Ernst <ernst () shreddedmail com> wrote:

> Resent, since I responded from the wrong address:
> ---
> The basic operation of IP SLA is as surmised; payload with timestamps
> and other telemetry data is sent to a 'responder' which manipulates
> the payload, including adding its own timestamps, and returns the
> altered payload.
>
> I had to do a mental walk-through, but I think I see how drift can
> cause this. I'm going to generate some artificial data, graph it, and
> see if it matches the general waveshape I'm seeing.
>
> I purposefully have the traffic generators ntp syncing against the
> responders. I thought that would keep the clocks more closely in sync.
> I don't necessarily care if the time is 'right', just that it's the
> same. What kind of difference should I expect if I sync both
> generators and responders against the same source, or not sync the
> responder? I'm thinking that having one source with constant drift may
> be better than both devices trying to walk/correct the time.
>
> Thanks for the input!
>
>
> On Wed, Oct 21, 2009 at 7:55 PM, Rick Ernst <ernst () shreddedmail com>wrote:
>
> > The basic operation of IP SLA is as surmised; payload with timestamps
> > and other telemetry data is sent to a 'responder' which manipulates
> > the payload, including adding its own timestamps, and returns the
> > altered payload.
> >
> > I had to do a mental walk-through, but I think I see how drift can
> > cause this. I'm going to generate some artificial data, graph it, and
> > see if it matches the general waveshape I'm seeing.
> >
> > I purposefully have the traffic generators ntp syncing against the
> > responders. I thought that would keep the clocks more closely in sync.
> > I don't necessarily care if the time is 'right', just that it's the
> > same. What kind of difference should I expect if I sync both
> > generators and responders against the same source, or not sync the
> > responder? I'm thinking that having one source with constant drift may
> > be better than both devices trying to walk/correct the time.
> >
> > Thanks for the input!
> >
> >
> > On Wednesday, October 21, 2009, Nathan Ward <nanog () daork net> wrote:
> > > On 22/10/2009, at 2:31 PM, Perry Lorier wrote:
> > >
> > >
> > > I assume this product works by having a packet with a timestamp sent
> > from the source to the destination where it is timestamped again and either
> > sent back, or another packet is sent in the other direction.  The difference
> > between the two timestamps gives you the latency in that direction.
> > > I believe a packet is sent, and the target router responds with a
> > timestamp.
> > > But yeah, timestamps are being compared.
> > >
> > > I'm with Perry though - sounds like your clocks are drifting.
> > >
> > > --
> > > Nathan Ward