[ntp:questions] Visualization of clock control

2012-01-04 Thread Miroslav Lichvar
Hi,

I wrote a tool to visualize the data generated by the clknetsim
simulator and I thought some of you might find it interesting. The
goal was to show how a clock is controlled by NTP client and at the
same time see its offset from true time and the NTP measurements (the
actual offset and delay seen by the client).

Here are some example runs of the tool captured to animated gifs:
http://mlichvar.fedorapeople.org/clknetsim/chrony_ntp/vis/visclocks_10us.gif
http://mlichvar.fedorapeople.org/clknetsim/chrony_ntp/vis/visclocks_100us.gif
http://mlichvar.fedorapeople.org/clknetsim/chrony_ntp/vis/visclocks_1000us.gif

The simulations were done with a clock wandering at 1 ppb/s,
10/100/1000us network jitter with exponential distribution and the NTP
clients were configured to use 64s polling interval.

The white line is the reference clock. The red line is the clock
controlled by ntp and green is chrony. The blue lines are the NTP
measurements made by chrony. Both clients were getting the same data,
but the polling intervals were not exactly the same so the frequency
changes in the red line don't match exactly with the blue lines.

The tool is included in the clknetsim git as visclocks.py. It also has
a game mode, where you control the frequency and phase of the clock by
mouse and you can try to beat the other clients. :)

-- 
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions


Re: [ntp:questions] Visualization of clock control

2012-01-04 Thread Dennis Ferguson

On 4 Jan, 2012, at 22:54 , Miroslav Lichvar wrote:
> Here are some example runs of the tool captured to animated gifs:
> http://mlichvar.fedorapeople.org/clknetsim/chrony_ntp/vis/visclocks_10us.gif
> http://mlichvar.fedorapeople.org/clknetsim/chrony_ntp/vis/visclocks_100us.gif
> http://mlichvar.fedorapeople.org/clknetsim/chrony_ntp/vis/visclocks_1000us.gif
> 
> The simulations were done with a clock wandering at 1 ppb/s,
> 10/100/1000us network jitter with exponential distribution and the NTP
> clients were configured to use 64s polling interval.

That's pretty neat.  I think, however, that the clock wander of 1 ppb/s
is about an order of magnitude too large for real life, at least for machines
kept in an air conditioned room (and the behavior of clocks in machines
subject to environmental variations probably can't be modeled by "wander" at
all).  My measurements against precise hardware tended towards a value of
1ppb/10s, which is also consistent with the 10^-8/1000s which sometimes shows
up on Allan variance plots (I think there's a square root relationship in there
if the wander is a truly random walk).

The other difficulty with respect to real life may be modeling network jitter
as exponential, since I believe the probability distribution for network delays
is heavy-tailed (i.e. with extreme values way over-represented; this is a 
problem
when using statistics which assume the underlying error distribution is 
gaussian).
I don't know how to fix that, though.

Dennis Ferguson
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions


Re: [ntp:questions] Visualization of clock control

2012-01-05 Thread Miroslav Lichvar
On Thu, Jan 05, 2012 at 11:40:25AM +0800, Dennis Ferguson wrote:
> On 4 Jan, 2012, at 22:54 , Miroslav Lichvar wrote:
> > The simulations were done with a clock wandering at 1 ppb/s,
> > 10/100/1000us network jitter with exponential distribution and the NTP
> > clients were configured to use 64s polling interval.
> 
> That's pretty neat.  I think, however, that the clock wander of 1 ppb/s
> is about an order of magnitude too large for real life, at least for machines
> kept in an air conditioned room (and the behavior of clocks in machines
> subject to environmental variations probably can't be modeled by "wander" at
> all).  My measurements against precise hardware tended towards a value of
> 1ppb/10s, which is also consistent with the 10^-8/1000s which sometimes shows
> up on Allan variance plots (I think there's a square root relationship in 
> there
> if the wander is a truly random walk).

I think the 1ppb/10s random walk wander corresponds to ~0.32ppb/1s.
The +0.5 slope in the variance plot intersecting 10^-8 at 1000s would
be ~0.6ppb/s wander.

I tried to model some thermal effects by adding a sine, triangle or
pulse wave to the clock frequency, but it seemed to me the effect it
had on the overall RMS time error was similar to just increasing the
wander. So instead of three or more parameters of the clock I set only
one. Sometimes I use even 10ppb/s wander, to simulate a machine with
varying CPU load and I think the results are not that different from
what I see on my desktop.

BTW, the simulator can be configured to read the clock frequency from
a file. If you have real data from a PPS refclock, you can use that
and see at what random walk wander will ntpd give similar results.

> The other difficulty with respect to real life may be modeling network jitter
> as exponential, since I believe the probability distribution for network 
> delays
> is heavy-tailed (i.e. with extreme values way over-represented; this is a 
> problem
> when using statistics which assume the underlying error distribution is 
> gaussian).
> I don't know how to fix that, though.

I'd definitely be interested in a better model for network delays. I
guess we could try to make a collection of the ntp rawstats logs from
various network environments and see how the distribution looks like.

-- 
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions


Re: [ntp:questions] Visualization of clock control

2012-01-12 Thread David Lord

Hal Murray wrote:

In article <20120105125942.GA15654@localhost>,
 Miroslav Lichvar  writes:


The other difficulty with respect to real life may be modeling network jitter
as exponential, since I believe the probability distribution for network delays
is heavy-tailed (i.e. with extreme values way over-represented; this is a 
problem
when using statistics which assume the underlying error distribution is 
gaussian).
I don't know how to fix that, though.



I'd definitely be interested in a better model for network delays. I
guess we could try to make a collection of the ntp rawstats logs from
various network environments and see how the distribution looks like.


My 2 cents...

I have a 384K DSL line.  I'd say it runs in one of 3 modes.

1) Mostly idle.  There is a little background traffic: NTP,
  fetchmail checks and occasional fetches.  yum checks at 3 AM...

2) Big download.  Occasionally, I download something like a CD.
That puts a consistent load on the download direction.  The queueing
delays go up to ballpark of 1 second.  ntpd doesn't like that.
After a while it sometimes to a bogus offset.  huffpuff helps,
but a big download can take a long long time.

3) Flurry of web downloads.  If I'm browsing the web, I occasionally
hit a page with lots of pictures and such.  Mozilla opens lots of 
TCP connections.  The round trip time goes over 3.5 seconds.


I don't think any of that fits an exponential tail.

I've got lots of log files.  Maybe I should make a histogram...



I'm on 2Mbit adsl with maximum upload of 288 kbit. Actual
uploads were topping out at only about 130kbit until I enabled
altq traffic shaping with a cap at about 250kbit. I now hit
250kbit on upload. Certain traffic also gets priority including
ntp. Apart from when my servers are being hammered by abuse
this has worked very well.


David

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions


Re: [ntp:questions] Visualization of clock control

2012-02-08 Thread Carl Byington
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, 12 Jan 2012 04:37:41 -0600, Hal Murray wrote:

> 3) Flurry of web downloads.  If I'm browsing the web, I occasionally
> hit
> a page with lots of pictures and such.  Mozilla opens lots of TCP
> connections.  The round trip time goes over 3.5 seconds.

Sounds like you have a buffer bloat issue.

http://queue.acm.org/detail.cfm?id=2076798
and related articles from google for buffer bloat.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEARECAAYFAk8SSiUACgkQL6j7milTFsGaYACfXDgLHo91HHRBaRMRVIxnLidZ
0BsAnjiQdOJZi53s/6UHgrGB9AKmvpMu
=GK5R
-END PGP SIGNATURE-

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions