[Bloat] monitoring bufferbloat at the DC using ntp?

[Dave Täht]

d at taht.net (Dave Täht) writes:

> I may have had a wacking good idea this morning.
>
> See ongoing thread on comp.protocols.time.ntp at:
>
> http://lists.ntp.org/pipermail/questions/2011-February/028577.html

The discussion over there continues. Encouraging news is that it is not
only possible to track the originating timestamp on ntp servers, but
that there are snmp mibs available for queue lengths.

(More details over on that thread) 

It's not clear to me what percentage of hosts are local timestamping
their origination, I'm under the impression this is a relatively new
feature. 

Also in my experiments thus far today:

the version of ntp I have always uses 123 as it's originating port
number on the client, rather than an ephemeral port.

I am curious as to whether other versions of ntp (mac, windows, other
platforms, other versions) also originate on 123. If so, this leads to
an easy way to distinguish between natted and non-natted origination of
requests. If members of this list could take a look at their own
platforms with something like wireshark, and trace a few ntp packets
going by, that would be helpful.

Repeating the same capture while performing a latency under load test
would also be good. You will have to run the test a fairly long time
(1024+ seconds) in order to get enough ntp packets going by.

There is a great deal more data we could derive from ntp server side
data sets, but I'm unwilling to speculate further without talking to an
ntp expert. 

There may be many flaws in this methodology, including the jitter
already in the network before bufferbloat was diagnosed client side.

But I'm really looking forward to flamage, criticism, or confirmation in
the morning.

-- 
Dave Taht
http://nex-6.taht.net