Re: [ntp:questions] NTP vs RADclock?

[Ron Frazier (NTP)]

I cannot speak to the advanced structure of clock algorithms, but, regarding 
wifi performance (of ntp), I can testify that it ranges from ok to terrible. 
I've seen machine to machine ping times on my wifi lan range from a few ms to 
almost a second. The worst is when 6 or so devices are all communicating on the 
same wifi channel and my wife's computer is connected to her remote access vpn 
tunnel for work. I have 3 machines acting as ntp clients and synching to a gps 
based server every 8 seconds. Those machines generally maintain accuracy of + / 
- 3 - 10 ms versus the server. That's plenty good for my purposes, but it's 
nowhere near as good as a gigabit hardwired lan running through a good switch. 
I could wire all these things up together, but for my purposes, it's not worth 
the trouble. I prefer the convenience of wifi. However, I'm not sure if it's 
even possible to do meaningful testing on wifi since the performance can be so 
variable.

Sincerely,

Ron


--

Sent from my Android Acer A500 tablet with bluetooth keyboard and K-9 Mail.
Please excuse my potential brevity.

(To whom it may concern. My email address has changed. Replying to former
messages prior to 03/31/12 with my personal address will go to the wrong
address. Please send all personal correspondence to the new address.)

(PS - If you email me and don't get a quick response, don't be concerned.
I get about 300 emails per day from alternate energy mailing lists and such.
I don't always see new email messages very quickly. If you need a reply and
haven't heard from me in 1 - 2 weeks, send your message again.)

Ron Frazier
timekeepingdude AT techstarship.com

Julien Ridoux  wrote:

On Thursday, June 7, 2012 4:19:31 PM UTC+10, unruh wrote:
> On 2012-06-07, skillz...@gmail.com  wrote:
> > On Jun 5, 6:46?pm, Julien Ridoux  wrote:
> >> On Tuesday, June 5, 2012 9:12:42 AM UTC+10, E-Mail Sent to this address 
> >> will be added to the BlackLists wrote:
> >
> > Thanks for response. It would be great to have a simplified
> > description of the algorithm. I've read most of the docs on the
> > synclab site.

That is a very impressive effort :)

> > I'm trying to synchronize several devices to a reference
> > clock of a similar device rather than to a true wall clock time of a
> > real NTP server. I can't use the RADclock code directly because it's
> > GPL so I'd like distill the algorithm down to something I can
> > implement from scratch. I'd like to adapt my current NTP client and
> > server code to use RADclock so I can compare performance. I'm aiming
> 
> Why not just use the reference implimentation of radclock for the tests?

The next version of RADclock is likely to be released under a BSD licence. This 
should save you the trouble of reimplementing the algorithm.


> > for 10 microseconds or less of sync on a wireless LAN with a fast
> 
> Not going to work. 
> 
> > initial sync time (less than 5 seconds, but I can send many packets
> 
> In 5 sec you could set the time, but you cannot get a good estimate of
> the rate. 
> 
> > close together if needed). I haven't been able to get even close to
> > this with my current NTP code (Ethernet is close, but WiFi introduces
> > a lot of variability). Some of the key points seem to be:
> 
> Precisely. And Radclock will not help with that. It uses the same ( or
> perhaps much slower) synchronization algorithm.

I agree with Unruh, you are going to bump into quite a few issues and the much 
noisier characteristic of the WiFi channel makes it much harder for any 
synchronisation algorithm. RADclock however does a pretty good job at filtering 
noise but there is no magic involved. If the overall noise characteristics of 
all packets is bad, then you cannot do much about it.
I have run RADclock over WiFi, but I would not dare quoting any achievable 
clock error value at this stage: we do not have an independent hardware time 
reference over WiFi at this stage so we would have to rely on more convoluted 
setups to do an objective assessment of RADclock there. I'll put this on my 
TODO list.


> > 1. Feed forward: Use raw TSC instead of the time value adjusted by the
> > algorithm. Is there more to this? Should raw TSC values be used for
> > offset sync calculations or should the raw TSC be scaled by the latest
> > adjusted rate (which would seem to be partially feed-back vs fully
> > feed forward)?
> 
> The "time" of the remote clock is measured with the TSC/HPET/ raw
> clock. The packets exchanged are filtered to get the best ones (takes
> time) and the rate and offset of the TSC calculated. If you want a
> difference clock, only the rate is used. to make the transfer from TSC
> differences to time differences. 

Actually, the time of the local clock is measured in counter units (that is Ta 
and Tf in NTP jargon). The RTT of NTP request/reply is measured in counter 
units, and filtering of RTTs is made in counter units. This prevents new inputs 
to the algorithm from being "polluted' by wrong estima

Re: [ntp:questions] Have Pi, have GPS = low powered NTP server?

[E-Mail Sent to this address will be added to the BlackLists]

On 6/7/2012 3:47 PM, Brian Utterback wrote:
> BlackLists wrote:
>> Try something like: ntpq -n -c "lpe" -c "las" -c "rv &0" -c "rv &1" -c
>> "rv &2" -c "rv &3" -c "rv &4" The easily readable parts, and the flash
>> code might give you more insight.
>
> Actually, you can do this a little more efficiently like this:
>
> ntpq -n -c lpe -c las -c "rv &0" -c "mrv &1 &9"

That only works if you know there are 9 (unless it has been changed),
 you get 0 then nothing because there are less than 9,
 however the way I did it, if there were only 1 or 2, or 3,
 it works for the ones that exist, and returns errors for the others,
 as they way you did it, you get nothing if there are less then 9.

-- 
E-Mail Sent to this address 
  will be added to the BlackLists.

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

Re: [ntp:questions] NTP vs RADclock?

[David L. Mills]

Julian,

Thanks for the paper reference. Your ideas on feed-forward are similar 
to the ideas in Greg Troxel's MIT dissertation. These ideas were 
partially implemented in NTPv3 a very long time ago.


There are some minor misinterptretations in the paper. The NTP 
discipline loop is not critically damped; it is purposely underdamped 
with a minor overshoot of a few percent in order to improve the 
transient response. The impulse response was slavishly copied in the 
microkernel and nanokernel code that left here over a decade ago. The 
microkernel survives in Solaris and the nanokernel in most BSD systems 
with varying degrees of fidelity; however, many systems have elected to 
modify the original BSD tickadj semantics, which result in an extra 
pole. The result is a moderate instability at the longer poll intervals, 
especially if the step threshold is increased or eliminated. In any 
case, the response has no serious misbehavior as the paper described. 
Note that in no case are the daemon and kernel algorithms cascaded as 
the paper implies. Either one or the other is used, but not both.


The system behavior with multiple servers is indeed as the paper 
suggests, but there is considerable algorithm horsepower to diminish the 
effects, including the cluster  and combine algorithms, plus the 
anti-clockhop and prefer peer mechanisms. These provisions were first 
implementd in the Internet of twenty years ago when the congestion on 
overseas links frequently reached over one second. Perhaps today these 
algorithms could be more carefully tuned for LANs and even wifi netorks.


As the paper describes, NTP algorithms are designed for traditional 
mathematical analysis, but with both linear and nonlinear components. 
However, the FLL algorithm is based on a model described by Levine as 
predictive. The model  in the documentation describes both the PLL and 
FLL in predictive terms, but that doesn't change the conclusions in the 
paper.


The paper suggests possible improvements in data filtering and analysis. 
The clock filter and popcorn spike suppressor algorithms in NTP 
represent one approach. A persistent observation is that NTP does not 
effectively use offset/delay samples other than at the apex of the 
scattergram. While it does indeed do that for the huff-n'-puff fiilter, 
the possible improvement in other cases is problematic. The paper does 
not mention the implications of roundtrip delay in the maximum error 
statistic, such as in Cristian's model, as used by NTP. It is a natural 
error bound for asymmetric paths such as mentioned in the paper.


In summary, the NTP algorithms have evolved over thiry years in response 
to major changes in Internet service models and surely could use some 
further evolution. I am glad there is continuing interest in improvements.


Dave

Julien Ridoux wrote:


On Thursday, June 7, 2012 4:19:31 PM UTC+10, unruh wrote:
 


On 2012-06-07, skillz...@gmail.com  wrote:
   


On Jun 5, 6:46?pm, Julien Ridoux  wrote:
 


On Tuesday, June 5, 2012 9:12:42 AM UTC+10, E-Mail Sent to this address will be 
added to the BlackLists wrote:
   


Thanks for response. It would be great to have a simplified
description of the algorithm. I've read most of the docs on the
synclab site.
 



That is a very impressive effort :)

 


I'm trying to synchronize several devices to a reference
clock of a similar device rather than to a true wall clock time of a
real NTP server. I can't use the RADclock code directly because it's
GPL so I'd like distill the algorithm down to something I can
implement from scratch. I'd like to adapt my current NTP client and
server code to use RADclock so I can compare performance. I'm aiming
 


Why not just use the reference implimentation of radclock for the tests?
   



The next version of RADclock is likely to be released under a BSD licence. This 
should save you the trouble of reimplementing the algorithm.

 
 


for 10 microseconds or less of sync on a wireless LAN with a fast
 

Not going to work. 

   


initial sync time (less than 5 seconds, but I can send many packets
 


In 5 sec you could set the time, but you cannot get a good estimate of
the rate. 

   


close together if needed). I haven't been able to get even close to
this with my current NTP code (Ethernet is close, but WiFi introduces
a lot of variability). Some of the key points seem to be:
 


Precisely. And Radclock will not help with that. It uses the same ( or
perhaps much slower) synchronization algorithm.
   



I agree with Unruh, you are going to bump into quite a few issues and the much 
noisier characteristic of the WiFi channel makes it much harder for any 
synchronisation algorithm. RADclock however does a pretty good job at filtering 
noise but there is no magic involved. If the overall noise characteristics of 
all packets is bad, then you cannot do much about it.
I have run RADclock over WiFi, but I would not dare quoting any achievable 
clock

Re: [ntp:questions] Have Pi, have GPS = low powered NTP server?

[Dave Hart]

On Fri, Jun 8, 2012 at 12:17 AM, Brian Utterback
 wrote:
> On 6/7/2012 7:35 PM, Dave Hart wrote:
>>
>> On Thu, Jun 7, 2012 at 10:47 PM, Brian Utterback
>>   wrote:
>>>
>>> (Some day it would be nice if "mrv&0&9" worked the way you expected, but
>>>
>>> would you believe "rv 0" and "rv anything-else" call entirely different
>>> functions? )
>>
>> "rv 0" means system variables.
>>
>> "rv&0" is not defined -- ampersand shorthand for association IDs start
>> with&1.
>>
>>
>> FYI, older versions of ntpq require lpeers, lassoc, or similar before
>> &  references work.  Newer ones (including 4.2.6 I believe) always
>> support&  references and will silently first issue lassoc to learn the
>> association IDs if needed.
>
> Quite. I meant "rv 0". My point is that I would really like "mrv &0 &99" to
> pretty much do "rv 0" followed in turn by each of the "rv associd" choices.
> I guess you are just pointing out that they are kind of different?

Right.  "rv" takes an association ID.  0 is reserved special case of
systemwide variables, any other number indicates variables specific to
the given association number.  &0 and 0 are not synonymous here.  &0
would mean the zeroeth association ID known to the server, but &
references count like humans starting at 1.  So IMO &0 should
complain, though one could redefine it to be a long way of writing 0.

Cheers,
Dave Hart
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Have Pi, have GPS = low powered NTP server?

[Brian Utterback]

On 6/7/2012 7:35 PM, Dave Hart wrote:

On Thu, Jun 7, 2012 at 10:47 PM, Brian Utterback
  wrote:

(Some day it would be nice if "mrv&0&9" worked the way you expected, but
would you believe "rv 0" and "rv anything-else" call entirely different
functions? )

"rv 0" means system variables.

"rv&0" is not defined -- ampersand shorthand for association IDs start with&1.

FYI, older versions of ntpq require lpeers, lassoc, or similar before
&  references work.  Newer ones (including 4.2.6 I believe) always
support&  references and will silently first issue lassoc to learn the
association IDs if needed.

Cheers,
Dave Hart


Quite. I meant "rv 0". My point is that I would really like "mrv &0 &99" 
to pretty much do "rv 0" followed in turn by each of the "rv associd" 
choices. I guess you are just pointing out that they are kind of different?


And correct, you need to do the assoc or the like before in older 
versions, but as you can see in this example, there is a "lpe"


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

Re: [ntp:questions] Have Pi, have GPS = low powered NTP server?

[Dave Hart]

On Thu, Jun 7, 2012 at 10:47 PM, Brian Utterback
 wrote:
> (Some day it would be nice if "mrv &0 &9" worked the way you expected, but
> would you believe "rv 0" and "rv anything-else" call entirely different
> functions? )

"rv 0" means system variables.

"rv &0" is not defined -- ampersand shorthand for association IDs start with &1.

FYI, older versions of ntpq require lpeers, lassoc, or similar before
& references work.  Newer ones (including 4.2.6 I believe) always
support & references and will silently first issue lassoc to learn the
association IDs if needed.

Cheers,
Dave Hart
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Have Pi, have GPS = low powered NTP server?

[Brian Utterback]

On 6/7/2012 2:24 PM, E-Mail Sent to this address will be added to the 
BlackLists wrote:
Try something like: ntpq -n -c "lpe" -c "las" -c "rv &0" -c "rv &1" -c 
"rv &2" -c "rv &3" -c "rv &4" The easily readable parts, and the flash 
code might give you more insight. 


Actually, you can do this a little more efficiently like this:

ntpq -n -c lpe -c las -c "rv &0" -c "mrv &1 &9"

(Some day it would be nice if "mrv &0 &9" worked the way you expected, 
but would you believe "rv 0" and "rv anything-else" call entirely 
different functions? )


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

Re: [ntp:questions] Have Pi, have GPS = low powered NTP server?

[E-Mail Sent to this address will be added to the BlackLists]

DaveB wrote:
>> pi@raspberrypi:~$ ntpq -p
>> remote   refid st t when poll reach delay  offset jitter
>> 
>> *ntp.websters-co 193.67.79.202  2 u  11  128  377 37.918  -7.068  20.879
>> +ns1.luns.net.uk 33.117.170.50  2 u  65  128  377 34.099  -5.716 197.916
>> +ns0.luns.net.uk 157.44.176.4   2 u  64  128  377 33.914  -6.204 181.881
>> -time.xilo.net   130.88.212.143 3 u 101  128  377 25.476 -29.662   4.126
>
> Interestingly, it's decided to cease accessing the few external servers
> I told it about (all uk.pool based) just sticking to the local Stratum 1
> box.  Or they have gone offline now...
>
> pi@raspberrypi:~$ ntpq -p
> remote  refid   st t when poll  reach  delay  offset  jitter
> 
> *192.168.42.24  .GPS.1 u  362  1024 3770.563   0.669  0.284
>  time.xilo.net  82.219.4.30  3 -   5h  1024   0   21.571  13.885  0.000
>  dns0.rmplc.co 195.66.241.3  2 -   5h  1024   0 2019.75  -1000.8  0.000
>
> I grabbed that via a remote SSH link, so I know the DSL at home is
> working, else I wouldnt have been able to get this data.  Both the
> external servers were reach=377 when I last looked last night.

Try something like:
ntpq -n -c "lpe" -c "las" -c "rv &0" -c "rv &1" -c "rv &2" -c "rv &3" -c "rv &4"

The easily readable parts, and the flash code might give you more insight.

-- 
E-Mail Sent to this address 
  will be added to the BlackLists.

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

Re: [ntp:questions] NTP vs RADclock?

[unruh]

On 2012-06-07, Julien Ridoux  wrote:
> On Thursday, June 7, 2012 2:26:54 AM UTC+10, unruh wrote:
>> On 2012-06-06, Julien Ridoux  wrote:
>> > On Wednesday, June 6, 2012 4:41:59 PM UTC+10, unruh wrote:
>> >> On 2012-06-06, Harlan Stenn  wrote:
>> > Dear unruh (Dr. William Unruh?),
>> >
>
>> 
>> >
>> > I would encourage you to read the scientific papers we published. I am 
>> > confident you will see the level of hype being much lower. The description 
>> > of the algorithm you are requesting can be found in several papers. 
>> > Repeating myself, the main one being : ""Robust Synchronization of 
>> > Absolute and Difference Clocks over Networks". It does describe the 
>> > algorithm in more details. It may not deliver all the details you are 
>> > after (or be slightly outdated), but the code publicly available is also 
>> > there for you to read. It is the ultimate reference after all.
>> >
>> 
>> It would be nice to have a link to that publication, in particular not
>> not one where you have to buy it. 
>> And asking people to read the code is a cop out. I have tried hard to
>> read the ntpd code for example, and the chrony code. While the latter is
>> slightly (only sightly) better than the former, both are a real pain to
>> figure out what is going on. Reading code is always a case of far fr too
>> many trees for to see the forest. 
>> 
>> For others, I have found a copy at 
>> http://www.cubinlab.ee.unimelb.edu.au/~darryl/Publications/synch_ToN.pdf
>
> Please note that the page http://www.synclab.org/docs/ I mentioned before has 
> links to all publications but the most recent. Please click the "Full text" 
> link to access the one of interest. I have updated most links for convenience 
> and missing ones will be added with the next update to the website.
>
>> > It was not my intention to describe the entire algorithm in my previous 
>> > message (it has been done in publicly available papers), but instead give 
>> > some pointers and general answers to some of the questions raised earlier. 
>> > My message did not intend to sparkle a heated discussion but instead try 
>> > to provide honest answers to this group.
>> 
>> I am very confused by your graph comparing ntpd to radclock. The ntp has
>> huge oscillations while from what I have read it is critically damped
>> while what I see is a pretty high Q (of the order of 10 or so) in the
>> graphs. Things I have not seen in my looks at ntpd. (Ntpd does have
>> problems which I have spent time pointing out in the comparison with
>> chrony) but oscillations like that I have not seen. Is this really ntpd
>> or some stripped down testbed?
>
> I am assuming you are talking about figure 13 in the paper mentioned above. 
> The version of ntpd used in this plot is the stock standard version shipped 
> with FreeBSD 6.1 (this data set has been captured in late 2006). The machine 
> used is a Pentium 3 @600MHz (now long dead), a DELL Optiplex GX1 with an 
> onboard 3Com 100 Mbps NIC. In this experiment, ntpd is configured as a 
> broadcast client only listening to a stratum-1 server on the LAN.
>
> The broadcast configuration may be a cause for the large oscillations? I 
> suppose ntpd experts may have an opinion on this.
>
> Another paper of ours (more recent) shows more comparisons of radclock agains 
> ntpd under a variety of scenarios:
> http://www.synclab.org/pubs/radclock_2012_TON.pdf
> In particular, figures 8 to 11 show ntpd performance that may resemble what 
> you have observed: no erratic behaviour on the LAN if the polling period is 
> small enough.
>
> I would be interested in looking at a performance comparison of ntpd vs. 
> chrony if you have one accessible. I will also try to start a comparison of 
> chrony vs. radclock. It could be valuable to compare our findings. I have a 
> fair few things on my plate these days, and this may get delayed a fair bit.

There is some on my page www.theory.physics.ubc.ca/chrony/chrony.html
(note that there have been changes recently so that the time tracking of
all the machines right now is a mess).

Miroslav Lichvar has also done extensive testing of ntpd vs chrony using
a
synthetic testbed (ie, the data is manufactured data but the algorithm
is the same so that the system can be run at far faster than real time).
I do not have the web references right now, but if you look back over
the
past year or so in this newsgroup for posts from him you will find the
comparisons.

Note, it would be really good if you persuaded your newsposting program
to put in line breaks, instead of sending out huge long lines of text.
Some newsreaders simply throw away the ends of lines that do not fit on
one line, making reading difficult. 

The polling behaviour of ntpd should make no difference to the
"oscillations" since the time scale of the feedback loop is adjusted to
the polling period so as always to keep it roughly critically damped
(modulo the feedback problems introduced by the highly non-linear clock
filtering algorithm) 
. 

Re: [ntp:questions] Have Pi, have GPS = low powered NTP server?

[Dave Hart]

On Thu, Jun 7, 2012 at 10:30 AM, DaveB  wrote:
> pi@raspberrypi:~$ ntpq -p
> remote          refid       st t when poll  reach  delay  offset  jitter
> 
> *192.168.42.24  .GPS.        1 u  362  1024 377    0.563   0.669  0.284
>  time.xilo.net  82.219.4.30  3 -   5h  1024   0   21.571  13.885  0.000
>  dns0.rmplc.co 195.66.241.3  2 -   5h  1024   0 2019.75  -1000.8  0.000
>
> If those delay/offset and jitter figures are in milli seconds (?) could
> that be down to the USB hosted LAN port on the Pi?  The same figures for
> the BSD box at 192.168.42.24 are 0.000 0.004 and 0.002 respectively, I
> just remoted into that and checked.

Yes, having your network behind a USB adapter is going to degrade
performance compared to a PCI-connected NIC.  A half-millisecond delay
is quite high for 100Mbit LAN.  Offset and jitter in the same range
are to be expected.

The output of:

ntpq -c "rv 0 version precision"

would shed a bit more light on which ntpd version and the time to read
the clock on that system.

Cheers,
Dave Hart
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP License Check (Was: Re: NTP vs RADclock?)

[unruh]

On 2012-06-07, Dave Hart  wrote:
> On Thu, Jun 7, 2012 at 6:21 AM, Steve Kostecke  wrote:
>> On 2012-06-07, Dave Hart  wrote:
>>> I am aware of no part of the ntpd tarballs that is solely licensed
>>> under GPL. ?libopts is dual-licensed BSD or GPL at user's choice. ?The
>>> rest of the package is BSD-style, as seen on the pages above. ?If you
>>> are aware of any GPL-only code we're distributing, please speak up so
>>> that we can correct the mistake.
>>
>> List of files containing a GPL License:
>
> Thanks, Steve.  The tool misses a number of exceptions in libopts and
> Bison output (implying they're GPL-only), but it also found libopts
> files licensed under GPL with no obvious exception, though I hope they
> are oversights that can be corrected easily.

I am not at all sure that you can assert copyright on a generated file
(rather than on the originals from which they are generated) since there
is absolutely no creativity in the geenration ( a requirement for
atracting copyright). Any you certainly could not tack on a different
license on the generated file than on the files from which is was
generated (ie, its only copyright might be as a derived work).


>
> Thanks for filing the bug report.  More details for those interested in:
>
> http://bugs.ntp.org/2214
>
> Cheers,
> Dave Hart

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

Re: [ntp:questions] Is it possible to confuse ntpd's freq error measurement procedure?

[David Woolley]

Paul Malishev wrote:

Thanks Dave.

I have some realtime processes on this server and 128ms is too much for
stepping.
But thanks for the hint now I have some start point to investigate



Are you aware that disabling stepping also disables the kernel 
discipline, and therefore makes the algorithm subtly different?


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

Re: [ntp:questions] Have Pi, have GPS = low powered NTP server?

[DaveB]

In article , 
s...@goes.nowhere.com says...
> 
> Hi.
> 
> From the title, you might (maybe) guess this is about the Raspberry Pi, 
> and NTP.
> 
> pi@raspberrypi:~$ ntpq -p
> remote   refid st t when poll reach delay  offset jitter
> 
> *ntp.websters-co 193.67.79.202  2 u  11  128  377 37.918  -7.068  20.879
> +ns1.luns.net.uk 33.117.170.50  2 u  65  128  377 34.099  -5.716 197.916
> +ns0.luns.net.uk 157.44.176.4   2 u  64  128  377 33.914  -6.204 181.881
> -time.xilo.net   130.88.212.143 3 u 101  128  377 25.476 -29.662   4.126
> 
> (A little bit of reformatting to fit here has been done)

Update...

I've sort of temporaraly deployed it on the home LAN (literally hanging 
by it's LAN cable!) sync'ing to the existing BSD based time server.

The stat's are now more encouraging, showing delay, offset and jitter 
arround 0.500 units, when left overnight.  See below.

Interestingly, it's decided to cease accessing the few external servers 
I told it about (all uk.pool based) just sticking to the local Stratum 1 
box.  Or they have gone offline now...

pi@raspberrypi:~$ ntpq -p
remote  refid   st t when poll  reach  delay  offset  jitter

*192.168.42.24  .GPS.1 u  362  1024 3770.563   0.669  0.284
 time.xilo.net  82.219.4.30  3 -   5h  1024   0   21.571  13.885  0.000
 dns0.rmplc.co 195.66.241.3  2 -   5h  1024   0 2019.75  -1000.8  0.000

I grabbed that via a remote SSH link, so I know the DSL at home is 
working, else I wouldnt have been able to get this data.  Both the 
external servers were reach=377 when I last looked last night.

If those delay/offset and jitter figures are in milli seconds (?) could 
that be down to the USB hosted LAN port on the Pi?  The same figures for 
the BSD box at 192.168.42.24 are 0.000 0.004 and 0.002 respectively, I 
just remoted into that and checked.

That is using a GPS with PPS via a real COM port, and has a 10/100LAN 
port.  The LAN between the two, is via a 10/100 full duplex switch, a 
generic Netgear domestic plastic 8 port type, nothing special, except 
I've somehow managed to fill all 8 ports!


The next check, will be to use it as a time source itself for one of the 
beacon monitors.  I'll be using the Faros machine for that, as it can 
show me how well the known time references are behaving relative to each 
other, and the received beacon times..


I'm still on a near vertical learning slope with this RasPi thing, and 
Linux in particular, but I do see that other activity (remote access by 
SSH/VNC etc) does not seem to disturb it that much.

Guess I need to look into using the onboard serial port for a GPS at 
some point, if that's releasable from whatever it might be tied to at 
present.  But that would still leave the USB<>LAN behaviour in the loop 
for the downstream users.

H...

Cheers etc.

Dave B.

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

Re: [ntp:questions] Is it possible to confuse ntpd's freq error measurement procedure?

[Paul Malishev]

Oh. Thanks.

This "true" flag may be the root cause of the problem. Along with slew
adjusting instead of stepping. Thank you, I'll try to investigate his
problem further.

2012/6/7 E-Mail Sent to this address will be added to the BlackLists <
Null@blacklist.anitech-systems.invalid>

> Paul Malishev wrote:
> > I have two ntpd peers which exchange time between
> >  themselves and also receive time from external server.
> > I believe that at some moment connection to external
> >  server was lost and time on these two peers drifted a bit.
> >
> > When connection to external server was restored both ntpd
> >  on both peers logged something like:
> > Jun  5 13:21:09 peer0 ntpd[5052]:
> >  frequency error 18158 PPM exceeds tolerance 500 PPM
> >
> > After that there were a lot of messages with not so big freq error:
> > Jun  5 13:23:18 DIG ntpd[5052]:
> >  frequency error 608 PPM exceeds tolerance 500 PPM
> ...
> > When an operator saw time difference with external server about 30sec
> ...
>
>  They must have been unable to reach the external server,
>  for a really long time?
>
>
> > server 127.127.1.0 noselect
> > fudge  127.127.1.0 stratum 10
>
>
>  If it looses the all other servers, it will likely continue
>   to run away at whatever frequency was last set;
>  If it can still contact the internal peer,
>   they should run off together (or one would chase the other).
>
>  You might try orphan mode instead; e.g.
>
> tos cohort 1 orphan 10
>
>  
>  {Although I'm not certain it would have any significant value,
>when only one other server can be reached.}
>
>
> > restrict 192.168.0.240 mask 255.255.255.240
>
>  If you ever use a server by host name,
>  especially when the name may return multiple A records,
>  (e.g. pool servers) you may need to add a restrict source
>  line; e.g.
>
> restrict source nomodify
>
>
> > tinker step 0
>
>  Remove that if you want it to step, instead of slew always.
>  BTW, step 0 also disables kernel discipline!
>
>
> > tos minclock 1 minsane 1
>
> MinSane defaults to 1 ?
>
>
> > peer 192.168.0.241 burst iburst minpoll 4 maxpoll 6 prefer true
> > server **external-server-ip** burst iburst minpoll 4 maxpoll 6 true
>
>  You should not do "burst" on servers that are not your own.
>  {I have no idea who **external-server-ip** belongs to.}
>   {"iburst" is fine}
>
>  The docs also seem to say to not use burst or iburst with "peer" ?
>  
>  
>
>
>  Are you really intentionally saying to treat both
>  the other internal server and the external server
>  as if they always have valid time, with the true option?
>   {Even if some day they may not be even close.}
>
>   Are you treating them both as true chimers
>because you only have two servers to reference?
>
>
> --
> E-Mail Sent to this address 
>  will be added to the BlackLists.
>
> ___
> questions mailing list
> questions@lists.ntp.org
> http://lists.ntp.org/listinfo/questions
>
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Is it possible to confuse ntpd's freq error measurement procedure?

[Paul Malishev]

Thanks Dave.

I have some realtime processes on this server and 128ms is too much for
stepping.
But thanks for the hint now I have some start point to investigate

2012/6/7 Dave Hart 

> On Wed, Jun 6, 2012 at 6:07 PM, Paul Malishev 
> wrote:
> > Hello.
> >
> > I have two ntpd peers which exchange time between themselves and also
> > receive time from external server.
> > I believe that at some moment connection to external server was lost and
> > time on these two peers drifted a bit.
> >
> > When connection to external server was restored both ntpd on both peers
> > logged something like:
> > Jun  5 13:21:09 peer0 ntpd[5052]: frequency error 18158 PPM exceeds
> > tolerance 500 PPM
> >
> > After that there were a lot of messages with not so big freq error:
> > Jun  5 13:23:18 DIG ntpd[5052]: frequency error 608 PPM exceeds tolerance
> > 500 PPM
> >
> > When an operator saw time difference with external server about 30sec he
> > just restarted ntpd on both nodes and surprisingly freq error messages
> > disappeared. Now difference is about 1ms and stability stays about 0.021
> >
> > So my question is: is it possible to confuse ntpd's freq error
> measurement
> > with some wrong settings?
>
> ntpd measures the frequency error directly only at startup, lacking a
> driftfile.  While it's operating, it's not measuring the frequency
> error, but rather manipulating it to steer the clock offset toward
> zero.  That manipulation is capped at 500 parts per million relative
> to the nominal clock rate.
>
> > My config is:
> > tinker step 0
>
> You've told ntpd to never step the clock to correct it (by default, it
> is stepped when the offset exceeds 128ms).  So instead, ntpd must
> eliminate slowly by running the clock faster or slower (but not more
> than 500 PPM faster or slower).  The large frequency "error" in the
> messages is a direct result of the perceived local clock offset.
>
> Likely restarting ntpd also invoked ntpdate, which stepped the clock
> so it was close enough that after restarting, ntpd's rate adjustments
> were well under 500 PPM.
>
> Cheers,
> Dave Hart
>
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP vs RADclock?

[Julien Ridoux]

On Thursday, June 7, 2012 4:19:31 PM UTC+10, unruh wrote:
> On 2012-06-07, skillz...@gmail.com  wrote:
> > On Jun 5, 6:46?pm, Julien Ridoux  wrote:
> >> On Tuesday, June 5, 2012 9:12:42 AM UTC+10, E-Mail Sent to this address 
> >> will be added to the BlackLists wrote:
> >
> > Thanks for response. It would be great to have a simplified
> > description of the algorithm. I've read most of the docs on the
> > synclab site.

That is a very impressive effort :)

> > I'm trying to synchronize several devices to a reference
> > clock of a similar device rather than to a true wall clock time of a
> > real NTP server. I can't use the RADclock code directly because it's
> > GPL so I'd like distill the algorithm down to something I can
> > implement from scratch. I'd like to adapt my current NTP client and
> > server code to use RADclock so I can compare performance. I'm aiming
> 
> Why not just use the reference implimentation of radclock for the tests?

The next version of RADclock is likely to be released under a BSD licence. This 
should save you the trouble of reimplementing the algorithm.

  
> > for 10 microseconds or less of sync on a wireless LAN with a fast
> 
> Not going to work. 
> 
> > initial sync time (less than 5 seconds, but I can send many packets
> 
> In 5 sec you could set the time, but you cannot get a good estimate of
> the rate. 
> 
> > close together if needed). I haven't been able to get even close to
> > this with my current NTP code (Ethernet is close, but WiFi introduces
> > a lot of variability). Some of the key points seem to be:
> 
> Precisely. And Radclock will not help with that. It uses the same ( or
> perhaps much slower) synchronization algorithm.

I agree with Unruh, you are going to bump into quite a few issues and the much 
noisier characteristic of the WiFi channel makes it much harder for any 
synchronisation algorithm. RADclock however does a pretty good job at filtering 
noise but there is no magic involved. If the overall noise characteristics of 
all packets is bad, then you cannot do much about it.
I have run RADclock over WiFi, but I would not dare quoting any achievable 
clock error value at this stage: we do not have an independent hardware time 
reference over WiFi at this stage so we would have to rely on more convoluted 
setups to do an objective assessment of RADclock there. I'll put this on my 
TODO list.


> > 1. Feed forward: Use raw TSC instead of the time value adjusted by the
> > algorithm. Is there more to this? Should raw TSC values be used for
> > offset sync calculations or should the raw TSC be scaled by the latest
> > adjusted rate (which would seem to be partially feed-back vs fully
> > feed forward)?
> 
> The "time" of the remote clock is measured with the TSC/HPET/ raw
> clock. The packets exchanged are filtered to get the best ones (takes
> time) and the rate and offset of the TSC calculated. If you want a
> difference clock, only the rate is used. to make the transfer from TSC
> differences to time differences. 

Actually, the time of the local clock is measured in counter units (that is Ta 
and Tf in NTP jargon). The RTT of NTP request/reply is measured in counter 
units, and filtering of RTTs is made in counter units. This prevents new inputs 
to the algorithm from being "polluted' by wrong estimates of drift based on 
past NTP exchanges. This is a simplified example of the feed-forward approach.
Of course, raw counter values have to be converted to time in seconds at one 
stage, but this is done when a consumer of time request the creation of a 
timestamp (a kernel sub-system or a userland application).

Note that you do not have to convert the counter values. You can store them, as 
well as radclock outputs and delay the conversion.

> >
> > 2. Separate offset sync from rate sync. What I wasn't sure about is
> > why the rate sync would be so much more stable than offset sync since
> > they seem to both come from the same packet exchanges. Is the
> > advantage that the rate sync is smoothed over time whereas the offset
> > sync isn't?
> 
> If you correct the clock for offset, the only way you can do that is to
> somehow shift the time. Thus if you want the difference in times from t0
> to t2 when you corrected the offset at t1, that offset correction will
> affect the time difference between t2 and t0. Thus, if you only correct
> determine the rate, the difference in raw times times the rate will
> directly give you the time difference. 

Unruh's explication is pretty much accurate. I would add that the algorithm is 
layered. The rate is estimated first in a very reliable way (that is the easy 
task) and is used for the difference clock, where drift error cancel out if the 
interval measured is small enough. For the purpose of absolute time (that is 
the hard bit, and as Unruh pointed out, very much error prone), the drift 
estimation algorithm is built on top of the rate estimate one.
Last piece of information: the rate estimation has been 

Re: [ntp:questions] NTP License Check (Was: Re: NTP vs RADclock?)

[Dave Hart]

On Thu, Jun 7, 2012 at 6:21 AM, Steve Kostecke  wrote:
> On 2012-06-07, Dave Hart  wrote:
>> I am aware of no part of the ntpd tarballs that is solely licensed
>> under GPL.  libopts is dual-licensed BSD or GPL at user's choice.  The
>> rest of the package is BSD-style, as seen on the pages above.  If you
>> are aware of any GPL-only code we're distributing, please speak up so
>> that we can correct the mistake.
>
> List of files containing a GPL License:

Thanks, Steve.  The tool misses a number of exceptions in libopts and
Bison output (implying they're GPL-only), but it also found libopts
files licensed under GPL with no obvious exception, though I hope they
are oversights that can be corrected easily.

Thanks for filing the bug report.  More details for those interested in:

http://bugs.ntp.org/2214

Cheers,
Dave Hart
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

[ntp:questions] NTP License Check (Was: Re: NTP vs RADclock?)

[Steve Kostecke]

On 2012-06-07, Dave Hart  wrote:
> On Thu, Jun 7, 2012 at 2:05 AM, E-Mail Sent to this address will be
> added to the BlackLists wrote:
>> Parts of ntp (ntpd) source code reference GPL, LGPS,
>>  among other things e.g. ,
>>  
>
> I am aware of no part of the ntpd tarballs that is solely licensed
> under GPL.  libopts is dual-licensed BSD or GPL at user's choice.  The
> rest of the package is BSD-style, as seen on the pages above.  If you
> are aware of any GPL-only code we're distributing, please speak up so
> that we can correct the mistake.

List of files containing a GPL License:

steve@stasis:/usr/local/src/ntp/ntp-dev-4.2.7p278$ licensecheck \
--recursive . | grep GPL
./ntpd/ntp_parser.c: GPL (v3 or later) 
./ntpd/ntp_parser.h: GPL (v3 or later) 
./sntp/libopts/autoopts/usage-txt.h: LGPL (v3 or later) GENERATED FILE
./sntp/libopts/autoopts/options.h: LGPL (v3 or later) GENERATED FILE
./sntp/libopts/genshell.c: GPL (v3 or later) GENERATED FILE
./sntp/libopts/parse-duration.h: GPL (v3 or later) 
./sntp/libopts/ag-char-map.h: GPL (v3 or later) 
./sntp/libopts/parse-duration.c: GPL (v3 or later) 
./sntp/libopts/genshell.h: GPL (v3 or later) GENERATED FILE
./sntp/libopts/compat/compat.h: GPL (v3 or later) 
./sntp/libopts/compat/windows-config.h: GPL (v3 or later) 
./sntp/libevent/build-aux/ltmain.sh: GPL (v2 or later) 

License Type Inventory:

steve@stasis:/usr/local/src/ntp/ntp-dev-4.2.7p278$ licensecheck \
--recursive . | cut -d ':' -f 2 | sort -u
 BSD (2 clause) 
 BSD (2 clause) ISC 
 BSD (3 clause) 
 BSD (3 clause) GENERATED FILE
 BSD (4 clause) 
 BSD (4 clause) ISC 
 GENERATED FILE
 GPL (v2 or later) 
 GPL (v3 or later) 
 GPL (v3 or later) GENERATED FILE
 ISC 
 LGPL (v3 or later) GENERATED FILE
 *No copyright* GENERATED FILE
 *No copyright* Public domain
 *No copyright* UNKNOWN
 Public domain
 UNKNOWN

-- 
Steve Kostecke 
NTP Public Services Project - http://support.ntp.org/

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

Re: [ntp:questions] NTP vs RADclock?

[Julien Ridoux]

On Thursday, June 7, 2012 2:26:54 AM UTC+10, unruh wrote:
> On 2012-06-06, Julien Ridoux  wrote:
> > On Wednesday, June 6, 2012 4:41:59 PM UTC+10, unruh wrote:
> >> On 2012-06-06, Harlan Stenn  wrote:
> > Dear unruh (Dr. William Unruh?),
> >

> 
> >
> > I would encourage you to read the scientific papers we published. I am 
> > confident you will see the level of hype being much lower. The description 
> > of the algorithm you are requesting can be found in several papers. 
> > Repeating myself, the main one being : ""Robust Synchronization of Absolute 
> > and Difference Clocks over Networks". It does describe the algorithm in 
> > more details. It may not deliver all the details you are after (or be 
> > slightly outdated), but the code publicly available is also there for you 
> > to read. It is the ultimate reference after all.
> >
> 
> It would be nice to have a link to that publication, in particular not
> not one where you have to buy it. 
> And asking people to read the code is a cop out. I have tried hard to
> read the ntpd code for example, and the chrony code. While the latter is
> slightly (only sightly) better than the former, both are a real pain to
> figure out what is going on. Reading code is always a case of far fr too
> many trees for to see the forest. 
> 
> For others, I have found a copy at 
> http://www.cubinlab.ee.unimelb.edu.au/~darryl/Publications/synch_ToN.pdf

Please note that the page http://www.synclab.org/docs/ I mentioned before has 
links to all publications but the most recent. Please click the "Full text" 
link to access the one of interest. I have updated most links for convenience 
and missing ones will be added with the next update to the website.

> > It was not my intention to describe the entire algorithm in my previous 
> > message (it has been done in publicly available papers), but instead give 
> > some pointers and general answers to some of the questions raised earlier. 
> > My message did not intend to sparkle a heated discussion but instead try to 
> > provide honest answers to this group.
> 
> I am very confused by your graph comparing ntpd to radclock. The ntp has
> huge oscillations while from what I have read it is critically damped
> while what I see is a pretty high Q (of the order of 10 or so) in the
> graphs. Things I have not seen in my looks at ntpd. (Ntpd does have
> problems which I have spent time pointing out in the comparison with
> chrony) but oscillations like that I have not seen. Is this really ntpd
> or some stripped down testbed?

I am assuming you are talking about figure 13 in the paper mentioned above. The 
version of ntpd used in this plot is the stock standard version shipped with 
FreeBSD 6.1 (this data set has been captured in late 2006). The machine used is 
a Pentium 3 @600MHz (now long dead), a DELL Optiplex GX1 with an onboard 3Com 
100 Mbps NIC. In this experiment, ntpd is configured as a broadcast client only 
listening to a stratum-1 server on the LAN.

The broadcast configuration may be a cause for the large oscillations? I 
suppose ntpd experts may have an opinion on this.

Another paper of ours (more recent) shows more comparisons of radclock agains 
ntpd under a variety of scenarios:
http://www.synclab.org/pubs/radclock_2012_TON.pdf
In particular, figures 8 to 11 show ntpd performance that may resemble what you 
have observed: no erratic behaviour on the LAN if the polling period is small 
enough.

I would be interested in looking at a performance comparison of ntpd vs. chrony 
if you have one accessible. I will also try to start a comparison of chrony vs. 
radclock. It could be valuable to compare our findings. I have a fair few 
things on my plate these days, and this may get delayed a fair bit..

Julien Ridoux

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