Re: [ntp:questions] NTP vs chrony comparison (Was: oscillations in ntp clock synchronization)

[David J Taylor]

David L. Mills wrote:
> David,
>
> I didn't get to set the price. Much of the early royalties went to pay
> for indexing. The royalties aren't very much anyway. I did the whole
> thing in FrameMaker, which is what CRC uses. They just blew away my
> templates and blew in their own. Nobrainer for them.
>
> Dave

Yes, Dave, it must be very frustrating when something you would like to be 
available to and read by the NTP community is priced out of the reach of 
many.  Although an online version might be nice, I still prefer to curl up 
with a physical book to study something, and avoid the distractions of 
being at the computer.  Perhaps the second edition can be published more 
cheaply, and you might even get more royalties?  (I do appreciate that the 
royalties are /not/ the reason for publication!)

Cheers,
David 


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

Re: [ntp:questions] strange behaviour of ntp peerstats entries.

[Unruh]

[EMAIL PROTECTED] (Danny Mayer) writes:

>Unruh wrote:
>> Brian Utterback <[EMAIL PROTECTED]> writes:
>> 
>>> Unruh wrote:
 "David L. Mills" <[EMAIL PROTECTED]> writes:
>> 
> You might not have noticed a couple of crucial issues in the clock 
> filter code.
 I did notice them all. Thus my caveate. However throwing away 80% of the
 precious data you have seems excessive.
>> 
>> Note that the situation can arise that the one can wait many more than 8
>> samples for another one. Say sample i is a good one. and remains the best
>> for the next 7 tries. Sample i+7 is slightly worse than sample i and thus
>> it is not picked as it comes in. But the next i samples are all worse than
>> it. Thus it remains the filtered one, but is never used because it was not
>> the best when it came in. This situation could keep going for a long time,
>> meaning that ntp suddenly has no data to do anything with for many many
>> poll intervals. Surely using sample i+7 is far better than  not using any
>> data for that length of time.

>On the contrary, it's better not to use the data at all if its suspect. 
>ntpd is designed to continue to work well even in the event of loosing 
>all access to external sources for extended periods.

>> And this could happen again. Now, since the
>> delays are presumably random variables, the chances of this happening are
>> not great ( although under a condition of gradually worsening network the
>> chances are not that small), but since one is running ntp for millions or
>> billions of samples, the chances of this happening sometime becomes large. 
>> 

>There are quite a few ntpd servers which are isolated and once an hour 
>use ACTS to fetch good time samples. This is not rare at all.

And then promplty throw them away because they do not satify the minimum
condition? No, it is not "best" to throw away data no matter how suspect.
Data is a preecious comodity and should be thrown away only if you are damn
sure it cannot help you. For example lets say that the change in delay is
.1 of the variance of the clock. The max extra noise that delay can cause
is about .01 Yet NTP will chuck it. Now if the delay is 100 times the
variance, sure chuck it. It probably cannot help you. The delay is a random
process, non-gaussian admitedly, and its effect on the time is also a
random process-- usually much closer to gaussian. And why was the figure of
8 chosen ( the best of the last 8 tries) why not 1? or 3? I suspect it
came off the top of someone's head-- lets not throuw away too much stuff,
since it would make ntp unseable, but lets throw away some to feel
virtuous. Sorry for being sarcastic, but I would really like to know what
the justification was for throwing so much data away.

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

Re: [ntp:questions] First attempt GPSD/PPS ->NTP time server

[Unruh]

[EMAIL PROTECTED] (Folkert van Heusden) writes:

>> The GPS time is not very accurate anyway, and can vary wildly, probably 

>> depending on the device, so don't expect perfect offsets.  On my Garmin G
>PS 

>> 18 LVC, I use 0.190 which gets it in the ballpark, but can randomly jump 

>> +16ms to -10ms at any time.

>But if you let ntp handle the pps signal it should be a steady 0.0-0.1ms
>difference as it then knows when this second started:

He was refering solely to the NMEA signal not the PPS. Some GPS receovers
have no pps.

> remote   refid  st t when poll reach   delay   offset  jit
>ter
>=
>=
>=
>===
>+GPS_NMEA(0) .GPS.0 l   17   16  3760.000   -0.001   0.
>001
>oPPS(0)  .PPS.0 l5   16  3770.000   -0.001   0.
>001

I am afraid I simply do not believe this. NMEA is lucky to get a ms not a
usec. The offset on the NMEA should be a lot bigger than .001


>Folkert van Heusden

>-- 

>MultiTail ist eine flexible Applikation um Logfiles und Kommando
>Eingaben zu überprüfen. Inkl. Filter, Farben, Zusammenführen,
>Ansichten etc. http://www.vanheusden.com/multitail/
>--
>Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com

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

Re: [ntp:questions] strange behaviour of ntp peerstats entries.

[Danny Mayer]

Unruh wrote:
> Brian Utterback <[EMAIL PROTECTED]> writes:
> 
>> Unruh wrote:
>>> "David L. Mills" <[EMAIL PROTECTED]> writes:
> 
 You might not have noticed a couple of crucial issues in the clock 
 filter code.
>>> I did notice them all. Thus my caveate. However throwing away 80% of the
>>> precious data you have seems excessive.
> 
> Note that the situation can arise that the one can wait many more than 8
> samples for another one. Say sample i is a good one. and remains the best
> for the next 7 tries. Sample i+7 is slightly worse than sample i and thus
> it is not picked as it comes in. But the next i samples are all worse than
> it. Thus it remains the filtered one, but is never used because it was not
> the best when it came in. This situation could keep going for a long time,
> meaning that ntp suddenly has no data to do anything with for many many
> poll intervals. Surely using sample i+7 is far better than  not using any
> data for that length of time.

On the contrary, it's better not to use the data at all if its suspect. 
ntpd is designed to continue to work well even in the event of loosing 
all access to external sources for extended periods.

> And this could happen again. Now, since the
> delays are presumably random variables, the chances of this happening are
> not great ( although under a condition of gradually worsening network the
> chances are not that small), but since one is running ntp for millions or
> billions of samples, the chances of this happening sometime becomes large. 
> 

There are quite a few ntpd servers which are isolated and once an hour 
use ACTS to fetch good time samples. This is not rare at all.

Danny
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] NTP vs chrony comparison (Was: oscillations in ntp clock synchronization)

[Danny Mayer]

Brian Utterback wrote:
> Danny, I agree with everything you said except:
> 
> Danny Mayer wrote:
>> I agree. I don't see how it can be a specification violation. The 
>> biggest factor is how well it keeps time. A caesium clock keeps good 
>> time but you wouldn't say that it violates the specification.
>>
> 
> When we first started looking at the V4 spec for the ntp-wg, my first
> thought was the same as yours, namely that what happens inside a system
> shouldn't matter, the algorithms don't matter, only what it chimes
> matters. And strictly speaking, this is true. However, after reading
> Dave's book (Das Buch as he calls it), I realized that an important
> factor to the stability of the NTP network is the actual speed at
> which the clocks slew, i.e. the 500 PPM limit. This is largely
> ignored in the spec. I sent in some comments about how I thought it
> should be addressed but alas, my changes didn't make it in the latest
> versions.
> 

I'm not sure what it was you were trying to modify, the NTP v4 draft, 
the book, something else.

I never said that you can consider ntpd in isolation. It's part of a 
network of ntpd servers and each is interacting with others. That's a 
very important part of the specification and each is affected by the others.

Danny

> Brian Utterback
> 
> ___
> questions mailing list
> questions@lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/questions
> 

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

Re: [ntp:questions] First attempt GPSD/PPS ->NTP time server

[Folkert van Heusden]

> The GPS time is not very accurate anyway, and can vary wildly, probably 
> depending on the device, so don't expect perfect offsets.  On my Garmin GPS 
> 18 LVC, I use 0.190 which gets it in the ballpark, but can randomly jump 
> +16ms to -10ms at any time.

But if you let ntp handle the pps signal it should be a steady 0.0-0.1ms
difference as it then knows when this second started:
 remote   refid  st t when poll reach   delay   offset  jitter
==
+GPS_NMEA(0) .GPS.0 l   17   16  3760.000   -0.001   0.001
oPPS(0)  .PPS.0 l5   16  3770.000   -0.001   0.001


Folkert van Heusden

-- 
MultiTail ist eine flexible Applikation um Logfiles und Kommando
Eingaben zu überprüfen. Inkl. Filter, Farben, Zusammenführen,
Ansichten etc. http://www.vanheusden.com/multitail/
--
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

[ntp:questions] comparing 2 NTP implementations

[Folkert van Heusden]

Hi,

I would like to compare 2 NTP implementations. What would be the best
way?
I was thinking of configuring 7 upstream servers on these 2 physical
servers and then on a third pc (which is also synced against these 7)
check the difference?


Folkert van Heusden

-- 
Multitail es una herramienta flexible que permite visualizar los "log
file" y seguir la ejecución de comandos. Permite filtrar, añadir
colores, combinar archivos, la visualización de diferencias (diff-
view), etc.  http://www.vanheusden.com/multitail/
--
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Re: [ntp:questions] Book Publishers (Was: NTP vs chrony comparison)

[Unruh]

"Richard B. Gilbert" <[EMAIL PROTECTED]> writes:

>Jason Rabel wrote:
>>>Richard B. Gilbert wrote:
>>>
Computer Network Time Synchronization: The Network Time Protocol by
David L. Mills (Hardcover - Mar 24, 2006)

Available from Amazon.com.   You may be able to find a copy at a
University Book store.  Be prepared for "Sticker Shock".  It ain't
cheap!  Publishing in small quantities is EXPENSIVE!!!  It's different
when you can amortize your setup costs over 50,000 copies!

"Das Buch" is unlikely to become a best seller!
>>>
>>>Perhaps we could have a Lulu version?  They can manage small quantities 
>>>very effectively.  See:
>>>
>>> http://www.lulu.com
>>>
>>>I'd love to see the book, but can't afford those Amazon prices.
>>>
>>>Cheers,
>>>David 
>> 
>> 
>> Or even CafePress has a very reasonable book printing prices.

>Printing is relatively cheap.  Typesetting is generally more expensive, 
>especially when you have to do equations, greek letters, graphs, etc. 
>Once the plates are made and installed on the press you are talking 
>about the price of electricity, paper and ink.  The setup costs are huge 
>compared to the actual cost of paper, ink, and electricity.

Well, that used to be true, before typesetting machines leanred to read
postscript of pdf. And it is even less true if you publish it online. the
typesetting costs are zero since the author usually does them.



>I know whereof I speak.  My wife has published "fan fiction" (StarTrek 
>and Beauty and the Beast (TV Show) under a "pen name")) and I put up the 
>"working capital".  Those small press runs are a real killer!


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

Re: [ntp:questions] NTP daemon - fixed offset against real time

[Unruh]

David Woolley <[EMAIL PROTECTED]> writes:

>[EMAIL PROTECTED] wrote:
>> 
>> i would like to ask you for help or ideas with one ntp related task.
>> I need to setup one ntp server to serve its sntp clients
>> with time, which is specific amount of time (several seconds) in

>You would need to modify the source code to do that.  If you do so, 
>please also overwrite the stratum, reported to clients, with 15, so that 
>if anyone else does try to use you as a server, they won't be able to 
>further distribute broken time.  (It may also be possible to set a silly 
>root dispersion, if the SNTP clients are not too fussy about it, to 
>completely stop NTP clients using the server adding your time offset to 
>root dispersion would be reasonably honest, as long as it is more then 
>one second.)


I would think it would be both easier and much less prone to introducing
bugs if theprogram running TV stuff added on the offset. Come two years
from now you will forget that the time on the machines is munged time, and
use it as real time. 

\on \Linux you could probably define a special timezone which was x seconds
off UTC. 
The refclocks off course have the offset option on some of them-- I do not
think it limits you as to how big that could be-- ie get a GPS source, use
the NMEA as a clock, and put in the appropriate offset.



>> advance against correct real time taken from another ntp server in
>> network. I did some search in documentation from both ntpd and
>> openntpd, but i didn't find any configuraition option related to this.

>One wouldn't expect the facility to deliberately break them in this way.

>> I need this quirky thing due to time syncing of several broadcast
>> graphics servers which also generates clocks to TV picture and it is
>> necessary to compensate delay caused by MPEG coding and transmission
>> of TV signal.

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

Re: [ntp:questions] NTP vs chrony comparison (Was: oscillations in ntp clock synchronization)

[Unruh]

"David L. Mills" <[EMAIL PROTECTED]> writes:

>Richard,

>There were several different architecture computers considered in the 
>1995 and 1998 studies, incluing SPARC, Alpha, Intel and several lab 
>instruments. All oscillators conformed to a simple model: white phase 
>noise (slope -1) below the intercept, random-walk frequency noise (slope 
>+0.5) above the intercept. This is equivalent to your model.

Unfortunately this does not seem to be the way that actual computers
behave, or should \i say, my computers. The problem is that there are
frequency shifts, which occur over very short time scales, and last hours.
These are probably because the copmpters do lots of work during theday and
get hot, and then when the students go home, or have a weekend, they get
cold. Ie, non-linear non-gaussian processes. I certainly understand the
white noise/1/f model, just  worry about its applicability to actual
computers used by real people.



>Additional data are in the nanokernel documentation. The only 
>differences are in the (x, y) intercept. You don't need das Buch to 
>justify this model; there is evidence all over the place. Clocks of all 
>kinds from cold rocks to Cesium oscillators all show very similar 
>chacteristics, whether modelled in the time domain or frequency domain.

>It's easy to make your own Allan characteristic. Just let the computer 
>clock free-run for a couple of weeks and record the offset relative to a 
>known and stable standard, preferable at the smallest poll interval you 
>can. The PPS from a GPS receiver is an ideal source, but you have to 
>jerry-rig a means to capture each transition.

Yes, I did that. I adapted a parallel interrupt routine to capture the
times and make them available as a /dev. It is what shows the behavour of
the clock. on one of my real systems.



>Dave

>Richard B. Gilbert wrote:
>> Unruh wrote:
>> 
>>> "David L. Mills" <[EMAIL PROTECTED]> writes:
>>>
>>>
 David,
>>>
>>>
>>>
 1. I have explained in very gory detail in many places how the time 
 constant is chosen for the best accuracy using typical computer 
 oscillators and network paths. See the briefings on the NTP project 
 page and especially the discussion about the Allan intercept. If you 
 want the 
>>>
>>>
>>>
>>> The Allan intercept is predicated on a very specific model of the 
>>> noise in
>>> a clock ( as I recall basically random gaussian noise at high 
>>> frequencies,
>>> and 1/f noise at low). It is not at all clear that real computers comply
>>> with that.
>>>
>>>
 best accuracy over the long term, you had better respect that. Proof 
 positive is in my 1995 SIGCOMM paper, later IEEE Transactions on 
 Networking paper and das Buch. I abvsolutely relish scientific 
 critique, but see the briefings and read the papers first.
>>>
>>>
>>>
 2. To reduce the convergence time, reduce the time constant, but only 
 at the expense of long term accuracy. An extended treatise on that is 
 in das Buch, especially Chaptera 4, 6 and 12. I would be delighted to 
 hear critique of the material, but read the chapters first.
>>>
>>>
>>>
>>> While you may know what in the world Das Buch is (Hitlers Mein Kampf?) 
>>> I do
>>> not. Nor do I know where to get it.
>> 
>> 
>> Computer Network Time Synchronization: The Network Time Protocol by 
>> David L. Mills (Hardcover - Mar 24, 2006)
>> 
>> Available from Amazon.com.   You may be able to find a copy at a 
>> University Book store.  Be prepared for "Sticker Shock".  It ain't 
>> cheap!  Publishing in small quantities is EXPENSIVE!!!  It's different 
>> when you can amortize your setup costs over 50,000 copies!
>> 
>> "Das Buch" is unlikely to become a best seller!
>> 

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

Re: [ntp:questions] NTP vs chrony comparison (Was: oscillations in ntp clock synchronization)

[Unruh]

"Richard B. Gilbert" <[EMAIL PROTECTED]> writes:

>David,

>Why are you telling me this?   My contribution to this thread consisted 
>of the above exposition of the publication data and availability of "Das 
>Buch".

He is not good at following attributions in threads. He addressed it to you
because he read my comments in your reply. I understood them to be directed
to me.

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

Re: [ntp:questions] NTP vs chrony comparison (Was: oscillations in ntp clock synchronization)

[Unruh]

David Woolley <[EMAIL PROTECTED]> writes:


>What I was expecting was for it to unconditionally do both frequency and 
>phase calibration, in the absence of the drift file.  I presume that 
>chrony does a correction on the first couple of samples and then refines it.

Yes. Actually it does a recalibration using the last n samples ( where n is
dynamic and grows with stabiltiy and shrinks if the linear fit is not a
very good one-- good defined by looking at how often the errors in the
linear fit cross zero) It then uses the adjtimex OFFSET single shot
adjustment to get rid of the ofset and uses the slope to set the freuency,
adjusting the old samples to account for the change in offset and
frequency, and keeping track of the offset ajustment in case it was
interrupted or did not completely conpensate. 



>Incidentally, the "else FREQ" doesn't seem to match the code and looks 
>like it would prevent it ever getting out of the calibration under some 
>conditions.

>It looks like I need to fetch the latest source, although it looks, from 
>your observations, as though it is still far from what I would consider 
>right.

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

Re: [ntp:questions] NTP vs chrony comparison (Was: oscillations in ntp clock synchronization)

[David L. Mills]

David,

I don't know your version, but the TSET state was removed some time ago 
and your comments are different from the current source. It's really 
hard to test the discipline under all conceivable conditions. Now and 
then somebody cooks up a case considered very unlikely, like Solaris 
adjtime() behavior with large offsets and force-slew mode, so the code 
does get tweaked from time to time.

Dave

David Woolley wrote:

> Petri Kaukasoina wrote:
> 
>> David Woolley  <[EMAIL PROTECTED]> wrote:
> 
> 
>>> That has quite a lot of similarity with what ntpd itself does if it 
>>> is cold started with iburst.  The only big difference is that it uses 
>>> 900, 
> 
> 
>>
>> Hmm, I can't see that. I put in only one good time source with iburst,
>> deleted the drift file and started ntpd. The time offset just keeps 
>> growing
>> and the frequency changes in very small steps. Now, after 30 minutes 
>> time is
>> already 25 ms off and the frequency is only 1.5 ppm (the correct value 
>> would
>> be about 25 ppm).
> 
> 
> Looking at the comments in the 4.2.0 source code, it looks like you may 
> be right; yet another reason why ntpd doesn't handle startup transients 
> well!
> 
> If this is still true in the latest version ("< max" means offset < 128ms):
> 
>  *  State   < max   > max   Comments
>  *  
>  *  NSETFREQFREQno ntp.drift
> 
>  *  FREQSYNCif (mu < 900) FREQ  calculate frequency
>  *  else if (allow) TSET
>  *  else FREQ
>  *
> 
> Worse than is obvious here, it only sets the time on the first sample if 
> it is out by more than 128ms.  More obvious, unless the frequency error 
> is so high that the time changes by more than  128ms between the first 
> two good samples, it will use the slow PLL method of calibrating the 
> frequency.  Even then, unless the offset is more than 128ms both the for 
> first sample, and after every subsequent sample, it will compute the 
> frequency based on the final absolute value of clock offset, not the 
> difference between the first and last readings; this might not be too 
> important, because it looks to me to require the intial offset to be 
> very close to 128ms (low  probability) or the frequency error to be 
> quite high (percentage error in frequency calculation relatively low) 
> for it to complete the frequency calibration.
> 
> What I was expecting was for it to unconditionally do both frequency and 
> phase calibration, in the absence of the drift file.  I presume that 
> chrony does a correction on the first couple of samples and then refines 
> it.
> 
> Incidentally, the "else FREQ" doesn't seem to match the code and looks 
> like it would prevent it ever getting out of the calibration under some 
> conditions.
> 
> It looks like I need to fetch the latest source, although it looks, from 
> your observations, as though it is still far from what I would consider 
> right.

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

Re: [ntp:questions] NTP vs chrony comparison (Was: oscillations in ntp clock synchronization)

[Unruh]

"David J Taylor" <[EMAIL PROTECTED]> writes:

>Richard B. Gilbert wrote:
>[]
>> Computer Network Time Synchronization: The Network Time Protocol by
>> David L. Mills (Hardcover - Mar 24, 2006)
>>
>> Available from Amazon.com.   You may be able to find a copy at a
>> University Book store.  Be prepared for "Sticker Shock".  It ain't
>> cheap!  Publishing in small quantities is EXPENSIVE!!!  It's different
>> when you can amortize your setup costs over 50,000 copies!
>>
>> "Das Buch" is unlikely to become a best seller!

>Perhaps we could have a Lulu version?  They can manage small quantities 
>very effectively.  See:

>  http://www.lulu.com

>I'd love to see the book, but can't afford those Amazon prices.

Would have been nice if there were an online version.

>Cheers,
>David 


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

Re: [ntp:questions] NTP vs chrony comparison (Was: oscillations in ntp clock synchronization)

[Unruh]

[EMAIL PROTECTED] (Danny Mayer) writes:

>Unruh wrote:
>> "David L. Mills" <[EMAIL PROTECTED]> writes:

>>> Reading your claims literally, chrony would have to slew the clock 
>>> considerably greater than the 500 PPM provided by the standard Unix 
>>> adjtime() system call. Please explain how it does that.
>> 
>> Using the Linux adjtimex system call which has the ability to change the
>> ticksize which gives much greater than 500PPM slew rate for the clocks.
>> ( Up to 10PPM, although that is never used. ) And as I understand it,
>> your handling of leap seconds in ntp also uses far greater than 500PPM slew 
>> rates. 

>No, ntpd deliberately limits frequency changes to 500 PPM. That's hard 
>coded. You need to avoid using anything greater than that as Dave has 
>explained. That would be the reason why it taks ntpd longer to bring the 
>clock back to the right time.

Well, no to both. ntpd steps, which hardly obeys that limit, and the reason
ntp takes such a long time is that it has an intergration loop with such a
long time constant. If it put its mind to it and used the 500PPM to get rid
of a 50ms offset, it would only take 200 sec, not 3 hours.
It slowly jacks the PPM to 400 or so and then slowly drops it again below
the nominal. This is done to avoid trashing or instability.



dd>Danny

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

Re: [ntp:questions] NTP vs chrony comparison (Was: oscillations in ntp clock synchronization)

[David L. Mills]

Petru,

The default 900-s stepout interval was originally determined by the time 
an old Spectracom WWVB receiver took to regain synchronization after a 
leapsecond and should probably be reduced. It can of course be tinkere.

During the initial training period the time is not disciplined other 
than to amortize the initial offset. The bookeeping to do that and 
preserve an accurate frequency measuremen got too tedious and fragile. 
So, at the end of the training period the offset that built up during 
the interval is amortized. I didn't think this was much of a problem, 
since in practice the training is done only once.

Dave

Petri Kaukasoina wrote:

> David Woolley  <[EMAIL PROTECTED]> wrote:
> 
>>Petri Kaukasoina wrote:
>>
>>>Basically, it stepped time with ntpdate, slept 100 seconds and stepped time
>>>again with ntpdate. From the time adjustment, the script calculated the
>>>drift value and put that to the drift file. Again, the time offset always
>>>stays below 1 ms.
>>
>>That has quite a lot of similarity with what ntpd itself does if it is 
>>cold started with iburst.  The only big difference is that it uses 900, 
>>rather than 100 seconds.  I don't know if that is the same 900 as 
>>controlled by "tinker stepout", but, even if it is, the side effect on 
>>stepout's would probably be undesirable.  To cold start you need to 
>>delete the drift file, or not configure it.
> 
> 
> Hmm, I can't see that. I put in only one good time source with iburst,
> deleted the drift file and started ntpd. The time offset just keeps growing
> and the frequency changes in very small steps. Now, after 30 minutes time is
> already 25 ms off and the frequency is only 1.5 ppm (the correct value would
> be about 25 ppm).

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

Re: [ntp:questions] NTP vs chrony comparison (Was: oscillations in ntp clock synchronization)

[David L. Mills]

David,

I didn't get to set the price. Much of the early royalties went to pay 
for indexing. The royalties aren't very much anyway. I did the whole 
thing in FrameMaker, which is what CRC uses. They just blew away my 
templates and blew in their own. Nobrainer for them.

Dave

David J Taylor wrote:

> Richard B. Gilbert wrote:
> []
> 
>>Computer Network Time Synchronization: The Network Time Protocol by
>>David L. Mills (Hardcover - Mar 24, 2006)
>>
>>Available from Amazon.com.   You may be able to find a copy at a
>>University Book store.  Be prepared for "Sticker Shock".  It ain't
>>cheap!  Publishing in small quantities is EXPENSIVE!!!  It's different
>>when you can amortize your setup costs over 50,000 copies!
>>
>>"Das Buch" is unlikely to become a best seller!
> 
> 
> Perhaps we could have a Lulu version?  They can manage small quantities 
> very effectively.  See:
> 
>   http://www.lulu.com
> 
> I'd love to see the book, but can't afford those Amazon prices.
> 
> Cheers,
> David 
> 
> 

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

Re: [ntp:questions] NTP vs chrony comparison (Was: oscillations in ntp clock synchronization)

[David L. Mills]

Danny,

Unless the computer clock intrinsic frequency error is huge, the only 
time the 500-PPM kicks in is with a 100-ms step transient and poll 
interval 16 s. The loop still works if it hits the stops; it just can't 
drive the offset to zero.

Dave

Danny Mayer wrote:

> Unruh wrote:
> 
>>"David L. Mills" <[EMAIL PROTECTED]> writes:
> 
> 
>>>Reading your claims literally, chrony would have to slew the clock 
>>>considerably greater than the 500 PPM provided by the standard Unix 
>>>adjtime() system call. Please explain how it does that.
>>
>>Using the Linux adjtimex system call which has the ability to change the
>>ticksize which gives much greater than 500PPM slew rate for the clocks.
>>( Up to 10PPM, although that is never used. ) And as I understand it,
>>your handling of leap seconds in ntp also uses far greater than 500PPM slew 
>>rates. 
> 
> 
> No, ntpd deliberately limits frequency changes to 500 PPM. That's hard 
> coded. You need to avoid using anything greater than that as Dave has 
> explained. That would be the reason why it taks ntpd longer to bring the 
> clock back to the right time.
> 
> Danny

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

Re: [ntp:questions] NTP vs chrony comparison (Was: oscillations in ntp clock synchronization)

[Richard B. Gilbert]

David L. Mills wrote:
> Richard,
> 
> There were several different architecture computers considered in the 
> 1995 and 1998 studies, incluing SPARC, Alpha, Intel and several lab 
> instruments. All oscillators conformed to a simple model: white phase 
> noise (slope -1) below the intercept, random-walk frequency noise (slope 
> +0.5) above the intercept. This is equivalent to your model.
> 
> Additional data are in the nanokernel documentation. The only 
> differences are in the (x, y) intercept. You don't need das Buch to 
> justify this model; there is evidence all over the place. Clocks of all 
> kinds from cold rocks to Cesium oscillators all show very similar 
> chacteristics, whether modelled in the time domain or frequency domain.
> 
> It's easy to make your own Allan characteristic. Just let the computer 
> clock free-run for a couple of weeks and record the offset relative to a 
> known and stable standard, preferable at the smallest poll interval you 
> can. The PPS from a GPS receiver is an ideal source, but you have to 
> jerry-rig a means to capture each transition.
> 
> Compute the RMS frequency differences, decimate and repeat. Don't take 
> the following seriously, I lifted it without considering context, but 
> that's the general idea. Be very careful about missing data, etc., as 
> that creates spectral lines that mess up the plot.
> 
> p = w; r = diff(x); q = y; i = 1; d = 1;
> while (length(q) >= 10)
> u = diff(p) / d;
> x2(i) = sqrt(mean(u .* u) / 2);
> u = diff(r) / d;
> x1(i) = sqrt(mean(u .* u) / 2);
> u = diff(q);
> y1(i) = sqrt(mean(u .* u) / 2);
> p = p(1:2:length(p));
> r = r(1:2:length(r));
> q = q(1:2:length(q));
> m1(i) = d; i = i + 1; d = d * 2;
> end
> loglog(m1, x2 * 1e6, m1, x1 * 1e6, m1, y1 * 1e6, m1, (x1 + y1) * 1e6)
> axis([1 1e5 1e-4 100]);
> xlabel('Time Interval (s)');
> ylabel('Allan Deviation (PPM)');
> print -dtiff allan
> 
> Dave
> 
> Richard B. Gilbert wrote:
> 
>> Unruh wrote:
>>
>>> "David L. Mills" <[EMAIL PROTECTED]> writes:
>>>
>>>
 David,
>>>
>>>
>>>
>>>
 1. I have explained in very gory detail in many places how the time 
 constant is chosen for the best accuracy using typical computer 
 oscillators and network paths. See the briefings on the NTP project 
 page and especially the discussion about the Allan intercept. If you 
 want the 
>>>
>>>
>>>
>>>
>>> The Allan intercept is predicated on a very specific model of the 
>>> noise in
>>> a clock ( as I recall basically random gaussian noise at high 
>>> frequencies,
>>> and 1/f noise at low). It is not at all clear that real computers comply
>>> with that.
>>>
>>>
 best accuracy over the long term, you had better respect that. Proof 
 positive is in my 1995 SIGCOMM paper, later IEEE Transactions on 
 Networking paper and das Buch. I abvsolutely relish scientific 
 critique, but see the briefings and read the papers first.
>>>
>>>
>>>
>>>
 2. To reduce the convergence time, reduce the time constant, but 
 only at the expense of long term accuracy. An extended treatise on 
 that is in das Buch, especially Chaptera 4, 6 and 12. I would be 
 delighted to hear critique of the material, but read the chapters 
 first.
>>>
>>>
>>>
>>>
>>> While you may know what in the world Das Buch is (Hitlers Mein 
>>> Kampf?) I do
>>> not. Nor do I know where to get it.
>>
>>
>>
>> Computer Network Time Synchronization: The Network Time Protocol by 
>> David L. Mills (Hardcover - Mar 24, 2006)
>>
>> Available from Amazon.com.   You may be able to find a copy at a 
>> University Book store.  Be prepared for "Sticker Shock".  It ain't 
>> cheap!  Publishing in small quantities is EXPENSIVE!!!  It's different 
>> when you can amortize your setup costs over 50,000 copies!
>>
>> "Das Buch" is unlikely to become a best seller!
>>

David,

Why are you telling me this?   My contribution to this thread consisted 
of the above exposition of the publication data and availability of "Das 
Buch".

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

Re: [ntp:questions] NTP daemon - fixed offset against real time

[msmucr]

On 26 Led, 19:03, "Dennis Hilberg, Jr."
<[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > Hello,
>
> > i would like to ask you for help or ideas with one ntp related task.
> > I need to setup one ntp server to serve its sntp clients
> > with time, which is specific amount of time (several seconds) in
> > advance against correct real time taken from another ntp server in
> > network. I did some search in documentation from both ntpd and
> > openntpd, but i didn't find any configuraition option related to this.
> > I need this quirky thing due to time syncing of several broadcast
> > graphics servers which also generates clocks to TV picture and it is
> > necessary to compensate delay caused by MPEG coding and transmission
> > of TV signal.
>
> You can do this with the 'fudge' command with the 'time1' option.  The docs
> say it's a "Reference Clock Command," but I've used it successfully with
> regular internet servers before to fix the small time offset due to my ntp
> server's asymmetric connection.
>
> See:http://www.eecis.udel.edu/~mills/ntp/html/clockopt.html#cmd
>
> > Thanks a lot
>
> > Michal Smucr
>
> Dennis
>
> --
> Dennis Hilberg, Jr. \  timekeeper(at)dennishilberg(dot)com
> NTP Server Information:  \  http://saturn.dennishilberg.com/ntp.php

Hello Dennis,

Thank you very much for advice. I'll try it.

Michal Smucr

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

Re: [ntp:questions] NTP vs chrony comparison (Was: oscillations in ntp clock synchronization)

[David L. Mills]

Richard,

There were several different architecture computers considered in the 
1995 and 1998 studies, incluing SPARC, Alpha, Intel and several lab 
instruments. All oscillators conformed to a simple model: white phase 
noise (slope -1) below the intercept, random-walk frequency noise (slope 
+0.5) above the intercept. This is equivalent to your model.

Additional data are in the nanokernel documentation. The only 
differences are in the (x, y) intercept. You don't need das Buch to 
justify this model; there is evidence all over the place. Clocks of all 
kinds from cold rocks to Cesium oscillators all show very similar 
chacteristics, whether modelled in the time domain or frequency domain.

It's easy to make your own Allan characteristic. Just let the computer 
clock free-run for a couple of weeks and record the offset relative to a 
known and stable standard, preferable at the smallest poll interval you 
can. The PPS from a GPS receiver is an ideal source, but you have to 
jerry-rig a means to capture each transition.

Compute the RMS frequency differences, decimate and repeat. Don't take 
the following seriously, I lifted it without considering context, but 
that's the general idea. Be very careful about missing data, etc., as 
that creates spectral lines that mess up the plot.

p = w; r = diff(x); q = y; i = 1; d = 1;
while (length(q) >= 10)
 u = diff(p) / d;
 x2(i) = sqrt(mean(u .* u) / 2);
 u = diff(r) / d;
 x1(i) = sqrt(mean(u .* u) / 2);
 u = diff(q);
 y1(i) = sqrt(mean(u .* u) / 2);
 p = p(1:2:length(p));
 r = r(1:2:length(r));
 q = q(1:2:length(q));
 m1(i) = d; i = i + 1; d = d * 2;
end
loglog(m1, x2 * 1e6, m1, x1 * 1e6, m1, y1 * 1e6, m1, (x1 + y1) * 1e6)
axis([1 1e5 1e-4 100]);
xlabel('Time Interval (s)');
ylabel('Allan Deviation (PPM)');
print -dtiff allan

Dave

Richard B. Gilbert wrote:
> Unruh wrote:
> 
>> "David L. Mills" <[EMAIL PROTECTED]> writes:
>>
>>
>>> David,
>>
>>
>>
>>> 1. I have explained in very gory detail in many places how the time 
>>> constant is chosen for the best accuracy using typical computer 
>>> oscillators and network paths. See the briefings on the NTP project 
>>> page and especially the discussion about the Allan intercept. If you 
>>> want the 
>>
>>
>>
>> The Allan intercept is predicated on a very specific model of the 
>> noise in
>> a clock ( as I recall basically random gaussian noise at high 
>> frequencies,
>> and 1/f noise at low). It is not at all clear that real computers comply
>> with that.
>>
>>
>>> best accuracy over the long term, you had better respect that. Proof 
>>> positive is in my 1995 SIGCOMM paper, later IEEE Transactions on 
>>> Networking paper and das Buch. I abvsolutely relish scientific 
>>> critique, but see the briefings and read the papers first.
>>
>>
>>
>>> 2. To reduce the convergence time, reduce the time constant, but only 
>>> at the expense of long term accuracy. An extended treatise on that is 
>>> in das Buch, especially Chaptera 4, 6 and 12. I would be delighted to 
>>> hear critique of the material, but read the chapters first.
>>
>>
>>
>> While you may know what in the world Das Buch is (Hitlers Mein Kampf?) 
>> I do
>> not. Nor do I know where to get it.
> 
> 
> Computer Network Time Synchronization: The Network Time Protocol by 
> David L. Mills (Hardcover - Mar 24, 2006)
> 
> Available from Amazon.com.   You may be able to find a copy at a 
> University Book store.  Be prepared for "Sticker Shock".  It ain't 
> cheap!  Publishing in small quantities is EXPENSIVE!!!  It's different 
> when you can amortize your setup costs over 50,000 copies!
> 
> "Das Buch" is unlikely to become a best seller!
> 

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

Re: [ntp:questions] NTP daemon - fixed offset against real time

[Dennis Hilberg, Jr.]

[EMAIL PROTECTED] wrote:
> Hello,
> 
> i would like to ask you for help or ideas with one ntp related task.
> I need to setup one ntp server to serve its sntp clients
> with time, which is specific amount of time (several seconds) in
> advance against correct real time taken from another ntp server in
> network. I did some search in documentation from both ntpd and
> openntpd, but i didn't find any configuraition option related to this.
> I need this quirky thing due to time syncing of several broadcast
> graphics servers which also generates clocks to TV picture and it is
> necessary to compensate delay caused by MPEG coding and transmission
> of TV signal.

You can do this with the 'fudge' command with the 'time1' option.  The docs 
say it's a "Reference Clock Command," but I've used it successfully with 
regular internet servers before to fix the small time offset due to my ntp 
server's asymmetric connection.

See: http://www.eecis.udel.edu/~mills/ntp/html/clockopt.html#cmd

> Thanks a lot
> 
> Michal Smucr

Dennis

-- 
Dennis Hilberg, Jr. \  timekeeper(at)dennishilberg(dot)com
NTP Server Information:  \  http://saturn.dennishilberg.com/ntp.php

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

Re: [ntp:questions] NTP daemon - fixed offset against real time

[David Woolley]

[EMAIL PROTECTED] wrote:
> 
> i would like to ask you for help or ideas with one ntp related task.
> I need to setup one ntp server to serve its sntp clients
> with time, which is specific amount of time (several seconds) in

You would need to modify the source code to do that.  If you do so, 
please also overwrite the stratum, reported to clients, with 15, so that 
if anyone else does try to use you as a server, they won't be able to 
further distribute broken time.  (It may also be possible to set a silly 
root dispersion, if the SNTP clients are not too fussy about it, to 
completely stop NTP clients using the server adding your time offset to 
root dispersion would be reasonably honest, as long as it is more then 
one second.)


> advance against correct real time taken from another ntp server in
> network. I did some search in documentation from both ntpd and
> openntpd, but i didn't find any configuraition option related to this.

One wouldn't expect the facility to deliberately break them in this way.

> I need this quirky thing due to time syncing of several broadcast
> graphics servers which also generates clocks to TV picture and it is
> necessary to compensate delay caused by MPEG coding and transmission
> of TV signal.

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

[ntp:questions] NTP daemon - fixed offset against real time

[msmucr]

Hello,

i would like to ask you for help or ideas with one ntp related task.
I need to setup one ntp server to serve its sntp clients
with time, which is specific amount of time (several seconds) in
advance against correct real time taken from another ntp server in
network. I did some search in documentation from both ntpd and
openntpd, but i didn't find any configuraition option related to this.
I need this quirky thing due to time syncing of several broadcast
graphics servers which also generates clocks to TV picture and it is
necessary to compensate delay caused by MPEG coding and transmission
of TV signal.

Thanks a lot

Michal Smucr

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

Re: [ntp:questions] Book Publishers (Was: NTP vs chrony comparison)

[Richard B. Gilbert]

Jason Rabel wrote:
>>Richard B. Gilbert wrote:
>>
>>>Computer Network Time Synchronization: The Network Time Protocol by
>>>David L. Mills (Hardcover - Mar 24, 2006)
>>>
>>>Available from Amazon.com.   You may be able to find a copy at a
>>>University Book store.  Be prepared for "Sticker Shock".  It ain't
>>>cheap!  Publishing in small quantities is EXPENSIVE!!!  It's different
>>>when you can amortize your setup costs over 50,000 copies!
>>>
>>>"Das Buch" is unlikely to become a best seller!
>>
>>Perhaps we could have a Lulu version?  They can manage small quantities 
>>very effectively.  See:
>>
>> http://www.lulu.com
>>
>>I'd love to see the book, but can't afford those Amazon prices.
>>
>>Cheers,
>>David 
> 
> 
> Or even CafePress has a very reasonable book printing prices.

Printing is relatively cheap.  Typesetting is generally more expensive, 
especially when you have to do equations, greek letters, graphs, etc. 
Once the plates are made and installed on the press you are talking 
about the price of electricity, paper and ink.  The setup costs are huge 
compared to the actual cost of paper, ink, and electricity.

I know whereof I speak.  My wife has published "fan fiction" (StarTrek 
and Beauty and the Beast (TV Show) under a "pen name")) and I put up the 
"working capital".  Those small press runs are a real killer!


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

Re: [ntp:questions] Book Publishers (Was: NTP vs chrony comparison)

[Jason Rabel]

> Richard B. Gilbert wrote:
>> Computer Network Time Synchronization: The Network Time Protocol by
>> David L. Mills (Hardcover - Mar 24, 2006)
>>
>> Available from Amazon.com.   You may be able to find a copy at a
>> University Book store.  Be prepared for "Sticker Shock".  It ain't
>> cheap!  Publishing in small quantities is EXPENSIVE!!!  It's different
>> when you can amortize your setup costs over 50,000 copies!
>>
>> "Das Buch" is unlikely to become a best seller!
>
>Perhaps we could have a Lulu version?  They can manage small quantities 
>very effectively.  See:
>
>  http://www.lulu.com
>
>I'd love to see the book, but can't afford those Amazon prices.
>
>Cheers,
>David 

Or even CafePress has a very reasonable book printing prices.

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

Re: [ntp:questions] NTP vs chrony comparison (Was: oscillations in ntp clock synchronization)

[David Woolley]

Jan Ceuleers wrote:

> NIST is a US government institution; might there perhaps be different 
> laws or regulations elsewhere in the world? Does anyone among the 
> readership here know?

I used the US case as that is the one that has come up on the newsgroup, 
but I assume there are similar rules elsewhere.  I think the NIST is 
only documenting the rules in this case, my guess is that it is the SEC 
that sets them, in the USA. I did the search with a site:nist.gov to 
reduce the false positives.

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

Re: [ntp:questions] NTP vs chrony comparison (Was: oscillations in ntp clock synchronization)

[Jan Ceuleers]

David,

David Woolley wrote:
>> ISTR that time stamps on financial transactions are required to be 
>> within two seconds of the correct time.  With NTP that standard is not 
>> too difficult to meet.
> 
> In 2006, it turns out that it was 3 seconds 
> ,

NIST is a US government institution; might there perhaps be different 
laws or regulations elsewhere in the world? Does anyone among the 
readership here know?

Thx, Jan

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

Re: [ntp:questions] NTP vs chrony comparison (Was: oscillations in ntp clock synchronization)

[David Woolley]

Richard B. Gilbert wrote:

> ISTR that time stamps on financial transactions are required to be 
> within two seconds of the correct time.  With NTP that standard is not 
> too difficult to meet.

In 2006, it turns out that it was 3 seconds 
, which makes me wonder why so 
many people were concerned about proving traceability when using NTP, as 
NTP will have stopped accepting times when it thinks their maximum error 
is only 1 second.

It seems to me that an appropriate ear and keyboard method could pretty 
much guarantee 3 seconds.  It got the impression, from the questions, 
that the state of the art was much better than that.  cron, ntpdate, and 
a check for large corrections should do.  (In a non-airconditioned 
domestic environment 2 seconds a week with weekly corrections isn't 
unreasonable, once the frequency has been calibrated.)

I think the optimum solution for that requirement would probably be to 
simply capture the most recent NMEA time string of a GPS receiver, plus 
a simple timeout and a check for error sentences. (You can probably add 
two to three seconds to the GPS value to take full advantage of the 6 
seconds peak to peak error!)

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

Re: [ntp:questions] NTP vs chrony comparison (Was: oscillations in ntp clock synchronization)

[David Woolley]

Petri Kaukasoina wrote:
> David Woolley  <[EMAIL PROTECTED]> wrote:

>> That has quite a lot of similarity with what ntpd itself does if it is 
>> cold started with iburst.  The only big difference is that it uses 900, 

> 
> Hmm, I can't see that. I put in only one good time source with iburst,
> deleted the drift file and started ntpd. The time offset just keeps growing
> and the frequency changes in very small steps. Now, after 30 minutes time is
> already 25 ms off and the frequency is only 1.5 ppm (the correct value would
> be about 25 ppm).

Looking at the comments in the 4.2.0 source code, it looks like you may 
be right; yet another reason why ntpd doesn't handle startup transients 
well!

If this is still true in the latest version ("< max" means offset < 128ms):

  *  State   < max   > max   Comments
  *  
  *  NSETFREQFREQno ntp.drift

  *  FREQSYNCif (mu < 900) FREQ  calculate frequency
  *  else if (allow) TSET
  *  else FREQ
  *

Worse than is obvious here, it only sets the time on the first sample if 
it is out by more than 128ms.  More obvious, unless the frequency error 
is so high that the time changes by more than  128ms between the first 
two good samples, it will use the slow PLL method of calibrating the 
frequency.  Even then, unless the offset is more than 128ms both the for 
first sample, and after every subsequent sample, it will compute the 
frequency based on the final absolute value of clock offset, not the 
difference between the first and last readings; this might not be too 
important, because it looks to me to require the intial offset to be 
very close to 128ms (low  probability) or the frequency error to be 
quite high (percentage error in frequency calculation relatively low) 
for it to complete the frequency calibration.

What I was expecting was for it to unconditionally do both frequency and 
phase calibration, in the absence of the drift file.  I presume that 
chrony does a correction on the first couple of samples and then refines it.

Incidentally, the "else FREQ" doesn't seem to match the code and looks 
like it would prevent it ever getting out of the calibration under some 
conditions.

It looks like I need to fetch the latest source, although it looks, from 
your observations, as though it is still far from what I would consider 
right.

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

Re: [ntp:questions] NTP vs chrony comparison (Was: oscillations in ntp clock synchronization)

[Petri Kaukasoina]

Hal Murray <[EMAIL PROTECTED]> wrote:
>
>That's a bug in the TSC calibration code.
>
>Recent Linux kernels use the TSC for timekeeping.  (At least on the
>systems I work with.)  There may be a simple command line option
>to use another chunk of hardware.

Yes. cat /sys/devices/system/clocksource/clocksource0/available_clocksource
prints the available clocksources, for example: "tsc acpi_pm jiffies". 
cat /sys/devices/system/clocksource/clocksource0/current_clocksource shows
which source is used, and
echo acpi_pm > /sys/devices/system/clocksource/clocksource0/current_clocksource
makes it to use acpi_pm. Of course, ntpd must recalibrate the frequency drift
then. After that the drift value seems to be correct after reboots! The time
source can be selected at boot time by adding "clocksource=acpi_pm" to the
kernel command line.

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

Re: [ntp:questions] NTP vs chrony comparison (Was: oscillations in ntp clock synchronization)

[Petri Kaukasoina]

David Woolley  <[EMAIL PROTECTED]> wrote:
>Petri Kaukasoina wrote:
>> Basically, it stepped time with ntpdate, slept 100 seconds and stepped time
>> again with ntpdate. From the time adjustment, the script calculated the
>> drift value and put that to the drift file. Again, the time offset always
>> stays below 1 ms.
>
>That has quite a lot of similarity with what ntpd itself does if it is 
>cold started with iburst.  The only big difference is that it uses 900, 
>rather than 100 seconds.  I don't know if that is the same 900 as 
>controlled by "tinker stepout", but, even if it is, the side effect on 
>stepout's would probably be undesirable.  To cold start you need to 
>delete the drift file, or not configure it.

Hmm, I can't see that. I put in only one good time source with iburst,
deleted the drift file and started ntpd. The time offset just keeps growing
and the frequency changes in very small steps. Now, after 30 minutes time is
already 25 ms off and the frequency is only 1.5 ppm (the correct value would
be about 25 ppm).

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

Re: [ntp:questions] NTP vs chrony comparison (Was: oscillations in ntp clock synchronization)

[David Woolley]

David L. Mills wrote:

> Well, I have done a market survey of sorts, if you can count my 
> consulting clients. There seems general agreement that 1 ms is a good 

Examples of specialized uses, rather than typical IT manager requirements.

> network on the sea floor off the Washington state coast. They need a 
> millisecond for experiments lasting months, not just 8-hour shifts, and 

The significance of the 8 hour shifts is that it means that start up 
transients are experienced every 8 hours of up time, not just 2 or 3 
times a year, so they are much more important.  (Also, down times are 
more like 60,000 seconds, and the hardware is commodity quality.)

> that when the experiment boxes get rather warm. Crony might work here as 
> well, but it would have to track large swings in temperature.

Nothing I've read so far indicates that chrony would have any problems. 
  In any case, I would have thought the thermal mass of the ocean would 
make temperature changes slow and therefore easy to track.

> I hear you say "100 ms" which I interpret as 100 milliseconds. Even 25 
> year old fuzzballs could to much better than that on the congested 
> ARPAnet. Did you mean 100 microseconds?

100ms is a rough estimate of the point at which almost any time 
synchronization method that has sub-second timestamps will work, with 
just very simple clock disciplines.  It represents a point at which ntpd 
is used because it is there, rather than because it is needed to meet 
the requirements.ent behaviour, as they could just use ntpdate in a cron 
job.

I presume that the 100 microseconds is the true error, measured by out 
of band means, as my impression is that one should expect offsets in the 
low milliseconds on Unix, and maybe into the very low 10s on Windows.
(The last time I ran ntpd on Windows was some time ago, and a fairly old 
version, but I still believe that it doesn't like running on loaded 
systems.)

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

Re: [ntp:questions] NTP vs chrony comparison (Was: oscillations in ntp clock synchronization)

[David Woolley]

Danny Mayer wrote:

> No, ntpd deliberately limits frequency changes to 500 PPM. That's hard 
> coded. You need to avoid using anything greater than that as Dave has 
> explained. That would be the reason why it taks ntpd longer to bring the 
> clock back to the right time.

Assuming that the static frequency error is consistent with a medium to 
high quality motherboard, slew rate limiting should only kick in if the 
clock was out by more than the order of a second in the first place, in 
which case stepping would have to have been inhibited.  For normal users 
the slow convergence is due to loop time constant being more suited to 
handling gradual temperature variations than startup transients of 
frequency hits.

The slew rate limit, for zero static error, is 1s/2000s.  The loop first 
zero crossing I seem to be remember being quoted at about 3000s, with 
minpoll set for 64 and the slew rate not being exceeded.  The resulting 
peak slew rate is more than 1/3000, for a 1 second error, but will be 
well below 1/2000 for a 128ms error.

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