subject:"Re\: \[ntp\:questions\] Red Hat vote for chrony"

On Dec 7, 2014, at 7:19 PM, William Unruh un...@invalid.ca wrote:
 I suspect most people are a bit more likely to use air conditioning to 
 control ambient
 temperature changes then they are to desolder and swap out their crystals in 
 the
 hopes of obtaining more precise timekeeping
 
 Actually air conditioning is largely irrelevant because it is not
 ambient air temperature changes that are most important, but temp
 changes inside the case caused by differing loads on the system. 

Data point: for a normal desktop machine I have at home, which has a 
95W TDP i5 CPU and a 145W 970 GPU, I can see a ~12C temperature change
on the motherboard temp sensor between idle and full load on both as the
total system draw goes from ~90 W to ~350 W, if I don't use air-conditioning.

With air-conditioning on, the temperature change shrinks to about 5C,
which reduces the thermal wandering of the XO by a factor of 2.  That
seems to be a worthwhile improvement, not largely irrelevant.

Furthermore, most of the systems I deal with at work are either 1U or
blades in datacenter racks with the raised floor forming a plenum to
deliver temperature-controlled air to each rack, hot and cold isle design, etc.
I can't observe even a 1C change in temp just by running an individual machine
or VM at peak load.  Even firing off something which causes a load spike for
an hour or two across all of the systems or VMs in a particular rack only
causes a 2-3C change.

In practice, that limits thermal wandering due to load from 10-20 PPM to
around ~2 PPM.

 One of my collegues debvised a script whose sole purpose was to stress
 the cpus so he could use the air coming out to dry his socks. 
 Ie, cpu load drives temp change which produces time shifts. 

Yes.  That matters the most for freestanding machines which are not kept
in air-conditioning.  It matters very little for machines in a data center,
because the ambient thermals there are controlled fairly precisely.

 And it is there that chrony tends to be better at keeping track of the
 rate changes.

That's the claim chrony makes, yes.

Regards,
-- 
-Chuck

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

Re: [ntp:questions] Red Hat vote for chrony

On Dec 7, 2014, at 7:27 PM, William Unruh un...@invalid.ca wrote:
 On 2014-12-07, Charles Swiger cswi...@mac.com wrote:
 On Dec 6, 2014, at 8:33 AM, William Unruh un...@invalid.ca wrote:
 On 2014-12-06, Charles Swiger cswi...@mac.com wrote:
[ ... ]
 Dude, give it a rest.  You've just acknowledged that the chrony docs at the 
 URL
 ending with manual.html directly above recommend using maxpoll=4 to the 
 LAN.
 
 No, the FAQ has that as an example. 
 
 Yes, the default values compiled into chrony of minpoll=5 maxpoll=10 are 
 nearly
 the same as what ntpd uses, which is polite when talking to the NTP pool or
 other WAN sources that you haven't made prior arrangements with.
 
 Can we skip the pendantry involved between default and recommended,
 especially when you seem to prefer the recommended faster polling yourself?
 
 Especially when the document you quote does not use the word
 recommended It uses the word example.

Um, the first sentence of section 5.3.4 uses the word 'recommended'.
I was going to quote it yet again for the third time, but I saw
that Miroslav just replied saying that he wrote that section.

You can argue this point further with him if you chose.

[ ... ]
 When ntpd has been up for a while using default maxpoll=10, how many past 
 polls
 are available (per timesource), and what interval of time does that 
 represent?
 
 You answered that below, in fact:
 
 Note that before it actually runs, it does remember the past 8 offsets AND 
 delays,
 
 ...which turns into 8 * 1024 seconds ~= 2.27 hours.  If we cannot manage to
 agree that this data is kept in memory by ntpd, then further discussion of 
 what
 ntpd might or might not do in discarding 7 out of 8 polls and so forth is
 completely moot.
 
 It is not used to set the clock. NOte that I will agree that ntpd also
 writes to a file the measurements in the logs. So what? It is not used
 by ntpd.

You've acknowledged that it keeps the data around, which means it remembers
that information.  The source code to clock_combine() was just posted by
David Woolley.

 (Starting from a false premise proves nothing about the following 
 conclusion.)
 
 Since you keep wanting to say I am wrong, why do you not tell us how
 ntpd works in your understanding?
 
 Let me provide three responses:
 
 1) I'd prefer you to say things which are accurate as to fact rather than 
 arguing.
 2) If you believe a statement I've made to be mistaken, feel free to point 
 it out.
 3) I'd rather test and submit patches than try to educate someone who 
 doesn't want to learn.
 
 Thought so. I interpret 1 as I don't know,

You'd be wrong in that intepretation if that's what you think I meant.

 2 as the fewer statements I make the less others can point out.

I don't think I've avoided making statements in this thread.

Either point out specific issues, if any, or you can make
general handwaving notions instead and pretend that you've
identified a specific issue without ever identifying one.

 For 3) how many patches and to what have you submitted?

You can google my name and tvtohz, setitimer, or wakeup latency and get
results like:

http://lists.freebsd.org/pipermail/freebsd-stable/2009-September/051803.html

The discussion was specifically including FreeBSD, DragonFlyBSD, Darwin/MacOS,
but should be relevant to the other BSD variants like NetBSD and OpenBSD.

Regards,
-- 
-Chuck

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

Re: [ntp:questions] Red Hat vote for chrony

2014-12-08 Thread William Unruh

On 2014-12-08, Charles Swiger cswi...@mac.com wrote:
 On Dec 7, 2014, at 7:19 PM, William Unruh un...@invalid.ca wrote:
 I suspect most people are a bit more likely to use air conditioning to 
 control ambient
 temperature changes then they are to desolder and swap out their crystals 
 in the
 hopes of obtaining more precise timekeeping
 
 Actually air conditioning is largely irrelevant because it is not
 ambient air temperature changes that are most important, but temp
 changes inside the case caused by differing loads on the system. 

 Data point: for a normal desktop machine I have at home, which has a 
 95W TDP i5 CPU and a 145W 970 GPU, I can see a ~12C temperature change
 on the motherboard temp sensor between idle and full load on both as the
 total system draw goes from ~90 W to ~350 W, if I don't use air-conditioning.

 With air-conditioning on, the temperature change shrinks to about 5C,
 which reduces the thermal wandering of the XO by a factor of 2.  That
 seems to be a worthwhile improvement, not largely irrelevant.

I find that very stange. Does the temperature in the room really
oscillate by 5 degrees if you run your machine? (Ie, you ascribe 5C of
the temp change to the room). 


 Furthermore, most of the systems I deal with at work are either 1U or
 blades in datacenter racks with the raised floor forming a plenum to
 deliver temperature-controlled air to each rack, hot and cold isle design, 
 etc.
 I can't observe even a 1C change in temp just by running an individual machine
 or VM at peak load.  Even firing off something which causes a load spike for
 an hour or two across all of the systems or VMs in a particular rack only
 causes a 2-3C change.

And those blades may well have much better internal cooling. 


 In practice, that limits thermal wandering due to load from 10-20 PPM to
 around ~2 PPM.

 One of my collegues debvised a script whose sole purpose was to stress
 the cpus so he could use the air coming out to dry his socks. 
 Ie, cpu load drives temp change which produces time shifts. 

 Yes.  That matters the most for freestanding machines which are not kept
 in air-conditioning.  It matters very little for machines in a data center,
 because the ambient thermals there are controlled fairly precisely.

 And it is there that chrony tends to be better at keeping track of the
 rate changes.

 That's the claim chrony makes, yes.

Actually no, I do not think I have read chronyd making that claim. I
have made that claim for chrony to try to explain the much better stats
that chrony is measured to have. The stats are not a claim, they are
measurements. The explanation is a claim. 
Chrony IS much faster at accounting for fluctuation in the rate or the
offset. That I have also measured. 


 Regards,

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

Re: [ntp:questions] Red Hat vote for chrony

On Dec 8, 2014, at 9:19 AM, William Unruh un...@invalid.ca wrote:
 Data point: for a normal desktop machine I have at home, which has a 
 95W TDP i5 CPU and a 145W 970 GPU, I can see a ~12C temperature change
 on the motherboard temp sensor between idle and full load on both as the
 total system draw goes from ~90 W to ~350 W, if I don't use air-conditioning.
 
 With air-conditioning on, the temperature change shrinks to about 5C,
 which reduces the thermal wandering of the XO by a factor of 2.  That
 seems to be a worthwhile improvement, not largely irrelevant.
 
 I find that very stange. Does the temperature in the room really
 oscillate by 5 degrees if you run your machine? (Ie, you ascribe 5C of
 the temp change to the room). 


With AC on, the room stays steady at 22 C or maybe goes up by one to 23 C.
With AC off and given several hours of load, the room temperature changes
from 22 C to maybe 25 C.

My computer is located at the opposite corner of the room from the AC;
if it were closer, it would probably show less of a swing

Regards,
-- 
-Chuck

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

Re: [ntp:questions] Red Hat vote for chrony

On Dec 8, 2014, at 12:04 PM, Phil W Lee p...@lee-family.me.uk wrote:
 With air-conditioning on, the temperature change shrinks to about 5C,
 which reduces the thermal wandering of the XO by a factor of 2.  That
 seems to be a worthwhile improvement, not largely irrelevant.
 
 Of course, server class machines tend to be designed with far tighter
 control of temperature, since wide temperature fluctuations are the
 worst enemy of reliability.

Indeed, although some servers are designed for SOHO and home media
stuff, and folks want those to run a little quieter than the typical
datacenter server, which tends to resemble a wind tunnel.  :-)

[ ... ]
 Furthermore, most of the systems I deal with at work are either 1U or
 blades in datacenter racks with the raised floor forming a plenum to
 deliver temperature-controlled air to each rack, hot and cold isle design, 
 etc.
 I can't observe even a 1C change in temp just by running an individual 
 machine
 or VM at peak load.  Even firing off something which causes a load spike for
 an hour or two across all of the systems or VMs in a particular rack only
 causes a 2-3C change.
 
 In practice, that limits thermal wandering due to load from 10-20 PPM to
 around ~2 PPM.
 
 So an order of magnitude better, even when tested to extremes which
 are well beyond any reasonable expectation of normal use.
 I would expect normal use probably stays within 1 PPM on those
 systems, based on the figures you've given for extreme load
 variations.

Yes, exactly.  Without doing anything unusual, a machine racked
in a DC is likely to have quite reasonable thermal stability.

That said, I'll admit that ~1-2 PPM isn't especially accurate; it'd
be an error of at least tens of milliseconds per day if the local clock
lost connection to a local or networked timesource.  That would
translate into weeks or even a month or so before the error accumulated
to a full second, which isn't too bad from a human timescale perspective.

 One of my collegues devised a script whose sole purpose was to stress
 the cpus so he could use the air coming out to dry his socks. 
 Ie, cpu load drives temp change which produces time shifts. 
 
 Yes.  That matters the most for freestanding machines which are not kept
 in air-conditioning.  It matters very little for machines in a data center,
 because the ambient thermals there are controlled fairly precisely.
 
 And the machines themselves are better designed to run at constant
 temperature irrespective of load.
 Freestanding office machines have noise reduction well above
 temperature stability on the list of design priorities.
 The attitude with them is just to stop it actually overheating to the
 point of failure, although it may struggle with even that when a bit
 of ordinary office dust gets into the works.
 Of course, a server room is unlikely to have very much of that dust,
 either.

Yes, I also find it a bit surprising than modern desktop CPUs and GPUs
are willing to run right up to their thermal trip points of ~80 C or so
rather than bump up fan speed a little more to keep them more around 50 C.

Older systems tended to use more aggressive cooling, especially laptops.

Well, smarter firmware and Hall effect sensors to measure fan speed means
you can spin the fans more slowly than if you needed to apply 40% minimum
speed just to be sure that the fan would spin up from idle.

[ ... ]
 Of course, in an ideal system designed for clock stability, the clock
 variation with temperature would be measured, and an offset based on
 the temperature of the crystal applied directly to the output of the
 clock itself, before it was supplied to the operating system.

Yes; you're describing calibrating a temperature-compensated XO, or TCXO.

 In theory, this wouldn't be expensive if done at the mass production
 stage, but clock stability isn't high enough on the design priorities
 for designers to put it into mass market machines.


Nope.  Generic AT crystals are dirt-cheap so I doubt many folks would
pay even $10 extra for a TCXO variant, much less be willing to pay
twice as much for their motherboard to get an SC cut crystal in an OCXO.

Regards,
-- 
-Chuck

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

Re: [ntp:questions] Red Hat vote for chrony

2014-12-07 Thread detha

On Sat, 06 Dec 2014 14:27:47 +, David Woolley wrote:

 On 06/12/14 12:27, Charles Swiger wrote:
 Some folks will be satisfied with Miroslav Lichvar's simulations but
 I'm not smart enough to understand them.  Other's will be convinced
 because they can run Chrony on a Unix laptop and save power or
 discipline a clock with only a few minutes a day of connect time.  I
 don't know who those people are.
 
 Sure, those seem to have been the major use-cases that chrony wanted to
 handle.
 
 RHEL, the subject of this thread, is not intended for laptops; it is
 intended for mission critical servers.

More and more of those servers end up being virtualized. Quicker reaction
to virtualization funnies, and faster convergence on VMs that are spun
up/down on demand, seem to be one of the main reasons Redhat switched to
chrony.

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

Re: [ntp:questions] Red Hat vote for chrony

2014-12-07 Thread David Woolley


On 07/12/14 09:08, detha wrote:

More and more of those servers end up being virtualized. Quicker reaction
to virtualization funnies, and faster convergence on VMs that are spun
up/down on demand, seem to be one of the main reasons Redhat switched to
chrony.


Surely the right solution for that is a virtualisation assist API that 
provide access to the host time, and if it is possible to read residual 
counts/cycle counters, without virtualisation overhead, to communicate 
the information needed to use that data for the next few seconds. 
Obviously that requires work from the developers of the virtual hosts.


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

Re: [ntp:questions] Red Hat vote for chrony

2014-12-07 Thread Charles Swiger


 On Dec 6, 2014, at 11:46 AM, Paul tik-...@bodosom.net wrote:
 On Sat, Dec 6, 2014 at 7:27 AM, Charles Swiger cswi...@mac.com wrote:
 Um, certainly?  Are you concerned about the quality of the XO which shipped 
 with a Soekris board?
 That'd be important if you were running a stratum-2+ timeserver.
 
 If you don't do the reading you won't understand the problems.

I would agree with this point if it were applicable.

 Here's a salient quote from Ackerman
[ ... ]
 This isn't about modifying a 4501 for testing or measurement.  It's about 
 modifying it for high resolution production service.  By the way in the 
 current era the 4501 is poor choice.  Common SoC based systems like the 
 BeagleBone Black have everything you need (and more), are cheaper and no 
 un-soldering is required.

The thread was originally about Red Hat adopting chrony, and how one
might measure its timekeeping with sub-microsecond accuracy.  You then claimed:

But to try and stay on point:  how do you measure the performance of a typical 
disciplined system (virtual) clock in a general purpose computer -- ideally 
without specialized hardware and software but those are okay if the results can 
be meaningfully generalized.  Given those measures you can decide if you prefer 
NTP, Chrony, SNTP or something else.

...so the details of using SoC based systems rather than a Net4501 nowadays 
shouldn't
be relevant to what you asked for.  Heck, even today's modern smartphone has an
AGPS chip and more horsepower than a ~2002-era Soekris with an embedded CPU.

 You setup a high quality clock somewhere and pull timestamps from the
 general purpose computer you want to measure. 
 
 Perhaps you're unfamiliar with the problem PTP solves.  That is one of things 
 you have to deal with if you're going to use external measurements to assess 
 the quality of your clock discipline.

If you want to use PTP for timestamping, rather than a PPS signal over a
GPIO pin, parallel/serial port, fine.  What PTP time source did you have in 
mind?

If a $1500 PRS-10 is out-of-bounds even for measurement purposes against a
~$250 embedded system + GPS puck, surely a Symmetricom XLi or Meinberg LANTIME
PTP grandmaster clock would also fall outside of your chosen realm of
without specialized hardware.

 Maybe you're also unfamiliar with what NTP is doing:  It disciplines a 
 virtual (system) clock which is derived from the on-board (usually 
 uncompensated) crystal.

I've been providing NTP stratum-1 or -2 timeservice to the public since the 
late 80's.
I can recall switching to ntpd from timed about the timeframe that physical 
networks
were moving from coax to RJ-45 plugs, anyway.

Nevertheless, you're welcome to patronize me about my limited knowledge of NTP 
if you
at least have a productive point to make by doing so.

 That's why NTP can act as a thermometer.  The big problem is temperature 
 induced wander and that's something (back to RedHat and Chrony) Chrony claims 
 to do better.

Yes, ntpd and chrony will notice temperature changes causing a frequency drift, 
at least
when a system is using cheap AT-cut XOs, which commonly show a 
temperature-dependency
frequency variation in the 10s of PPM range for a 10 C change around room 
temperature.
A more expensive SC-cut XO will likely remain stable to a few PPM for such a 
range,
and a calibrated TCXO or OCXO will do better still.

I suspect most people are a bit more likely to use air conditioning to control 
ambient
temperature changes then they are to desolder and swap out their crystals in the
hopes of obtaining more precise timekeeping

Regards,
-- 
-Chuck


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

Re: [ntp:questions] Red Hat vote for chrony

2014-12-07 Thread Charles Swiger

On Dec 6, 2014, at 8:33 AM, William Unruh un...@invalid.ca wrote:
On 2014-12-06, Charles Swiger cswi...@mac.com wrote:

On Dec 5, 2014, at 8:39 PM, William Unruh un...@invalid.ca wrote:
[ ... ]
Just like your claim whether the chrony docs recommend using maxpoll=4
across the network to a LAN timesource or not was wrong?

I have given you the quotes from the chrony docs. Where do you get your
statement from?

The chrony docs, section 5.3.4:

http://chrony.tuxfamily.org/manual.html#How-can-I-improve-the-accuracy-of-the-system-clock-with-NTP-sources_003f

OK, lets quote the whole section
[ ...section snipped, as you found what I linked to and even quoted before... ]
Note the caveates : server located on the same lan. In fact more
frequent polling IS better especially when one uses the a system with
memory-- ie where the system uses the offsets measured for the last 64
times to figure out what the best time now is.

Yes, so chrony recommends using maxpoll=4 to the LAN, and not only to local
refclocks.

But, compare this with the actual documentation for chrony, not this
faq which I quoted, and you erased. (Minpoll 5 maxpoll 10)

Dude, give it a rest. You've just acknowledged that the chrony docs at the URL
ending with manual.html directly above recommend using maxpoll=4 to the LAN.

Yes, the default values compiled into chrony of minpoll=5 maxpoll=10 are nearly
the same as what ntpd uses, which is polite when talking to the NTP pool or
other WAN sources that you haven't made prior arrangements with.

Can we skip the pendantry involved between default and recommended,
especially when you seem to prefer the recommended faster polling yourself?

Just like your claim about whether ntpd cares about figuring out the local
clock frequency or whether it only chases the offset was wrong?

ntpd does not care about figuring out the local clock frequency.

You keep repeating this assertion when it is quite obviously wrong.

Above, you've acknowledged that ntp.drift contains the (frequency) offset
for the clock. That's the single most important piece of data to have
around even if the machine loses network connectivity with other timeservers,
or ntpd is restarted, or the machine itself is rebooted.

It is ONLY used when the ntpd is started/restarted.
If it makes you feel happy, yes ntpd does know about the current drift
rate.

Try not to confuse making me happy with being able to state the truth,
be honestly mistaken about a point but also acknowledge it once corrected,
or chosing to be wilfully dishonest.

Nothing personal: everyone faces such a choice

It knows nothing about the past drift rate. That is what I call
memory. And in normal operation, it does not even know about the current
drift rate-- it is the operating system that does that. All ntpd does is
to change the current drift rate to try to minimize the offset.

IF the operating system is incapable of changing the clock rate, ntpd
tries to do it for the operating system. Every second it resets the
clock to take into account the error in the rate of the clock. In this
case, ntpd remembers the current drift rate. But only the current drift
rate. Again, it has no memory of the past.

When ntpd has been up for a while using default maxpoll=10, how many past polls
are available (per timesource), and what interval of time does that represent?

You answered that below, in fact:

Note that before it actually runs, it does remember the past 8 offsets AND
delays,

...which turns into 8 * 1024 seconds ~= 2.27 hours. If we cannot manage to
agree that this data is kept in memory by ntpd, then further discussion of what
ntpd might or might not do in discarding 7 out of 8 polls and so forth is
completely moot.

(Starting from a false premise proves nothing about the following conclusion.)

Since you keep wanting to say I am wrong, why do you not tell us how
ntpd works in your understanding?

Let me provide three responses:

1) I'd prefer you to say things which are accurate as to fact rather than
arguing.
2) If you believe a statement I've made to be mistaken, feel free to point it
out.
3) I'd rather test and submit patches than try to educate someone who doesn't
want to learn.

...and skip the rest as being addressed above.

Regards,
--
-Chuck

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

Re: [ntp:questions] Red Hat vote for chrony

2014-12-07 Thread Paul

On Sun, Dec 7, 2014 at 2:42 PM, Charles Swiger cswi...@mac.com wrote:

 I would agree with this point if it were applicable.


In fact it is as others have tried to point out to you.


... Heck, even today's modern smartphone has an
 AGPS chip and more horsepower than a ~2002-era Soekris with an embedded
 CPU.


I have no idea what you're talking about but horsepower is not relevant.


 If you want to use PTP for timestamping, rather than a PPS signal over a
 GPIO pin, parallel/serial port, fine.  What PTP time source did you have
 in mind?


As as been pointed out to you by others you can't measure error using the
network unless you remove the network error.  That's why you would use PTP
but as also noted measuring across the network is the wrong answer.  I
wasn't suggesting using PTP.  I said it tries to solve *one* of the tings
you have to deal with.


  Maybe you're also unfamiliar with what NTP is doing:  It disciplines a
 virtual (system) clock which is derived from the on-board (usually
 uncompensated) crystal.

 I've been providing NTP stratum-1 or -2 timeservice to the public since
 the late 80's.


 Nevertheless, you're welcome to patronize me about my limited knowledge of
 NTP if you

at least have a productive point to make by doing so.


 And I've been doing it
since you could peer with fuzzballs.  Driving to work every day for 30
years doesn't make you an automotive engineer.

  The big problem is temperature induced wander and that's something (back
 to RedHat and Chrony) Chrony claims to do better.

 Yes, ntpd and chrony will notice temperature changes causing a frequency
 drift,


You don't need to repeat approximately what I said back to me.


Back to your favorite source: http://phk.freebsd.dk/time/20141026.html
but you won't read it so:

The reason most crystals don't behave that way, is that people usually
don't put a 100W variable heating element right next to them.
If you look at the horizontal part, you can see a lot of small wiggles,
that is the aircondition cycling on and off.
Around 5000 seconds, there's a dip, that's me using the machine to crunsh a
couple of gigabytes of data, and the heat from the CPU affects the crystal.

The 100W heater is the CPU by the way.

And as long I we're providing pointless qualifications:

If a $1500 PRS-10 is out-of-bounds even for measurement purposes against a
~$250 embedded system + GPS puck


I have a PRS-10 and s GPSD(D)OCXO system.  I even have a decent counter and
scope.  I didn't say it was out of bounds for measurement I said the
opposite.  Are you one of those opposite guys?  If I say X are you going to
say I said not-X?

This started when you said:

Without measuring the
local clock against some other clock or oscillator which is known to be
accurate to sub-microsecond levels, one doesn't have the data needed to draw
conclusions about the actual timekeeping precision.

I (sort of) agree with you but nothing you've said addresses that issue.
But you don't have to believe me.  Just pay attention to any of the people
that have tried to point out your errors.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Red Hat vote for chrony

2014-12-07 Thread Charles Swiger

On Dec 7, 2014, at 12:47 PM, Paul tik-...@bodosom.net wrote:
 On Sun, Dec 7, 2014 at 2:42 PM, Charles Swiger cswi...@mac.com wrote:
 ... Heck, even today's modern smartphone has an
 AGPS chip and more horsepower than a ~2002-era Soekris with an embedded CPU.
 
 I have no idea what you're talking about but horsepower is not relevant.

Oddly enough: if I have no idea what someone was talking about, I don't assume
that what they said could not possibly be relevant.

 If you want to use PTP for timestamping, rather than a PPS signal over a
 GPIO pin, parallel/serial port, fine.  What PTP time source did you have in 
 mind?
 
 As as been pointed out to you by others you can't measure error using the 
 network unless you remove the network error.  That's why you would use PTP 
 but as also noted measuring across the network is the wrong answer.  I wasn't 
 suggesting using PTP.  I said it tries to solve *one* of the tings you have 
 to deal with.

You've told me one thing that you wouldn't use.

That doesn't answer the question of what you would use.

 Maybe you're also unfamiliar with what NTP is doing:  It disciplines a 
 virtual (system) clock which is derived from the on-board (usually 
 uncompensated) crystal.
 
 I've been providing NTP stratum-1 or -2 timeservice to the public since the 
 late 80's.
 
 Nevertheless, you're welcome to patronize me about my limited knowledge of 
 NTP if you
 at least have a productive point to make by doing so.
 
  And I've been doing it since you could peer with fuzzballs.  Driving to work 
 every day for 30 years doesn't make you an automotive engineer.

Right, and your point was?

Pretend you wanted to explain what you meant by this to an neutral third party.

 The big problem is temperature induced wander and that's something (back to 
 RedHat and Chrony) Chrony claims to do better.
 
 Yes, ntpd and chrony will notice temperature changes causing a frequency 
 drift,
 
 You don't need to repeat approximately what I said back to me. 

I was attempting to find some level of agreement about basic facts.

 Back to your favorite source: http://phk.freebsd.dk/time/20141026.html
 but you won't read it so:

WTF is that supposed to mean?

 The reason most crystals don’t behave that way, is that people usually don’t 
 put a 100W variable heating element right next to them.
 If you look at the horizontal part, you can see a lot of small wiggles, that 
 is the aircondition cycling on and off.
 Around 5000 seconds, there’s a dip, that’s me using the machine to crunsh a 
 couple of gigabytes of data, and the heat from the CPU affects the crystal.
 
 The 100W heater is the CPU by the way.

I've either read my supposed favorite source already and/or or not read it.

100W CPU under load causes XO drift.  And so?
 
 And as long I we're providing pointless qualifications:

Um, wow.  Did you fail to stroke your ego in private today?

Dude, unless I want to hire somebody, I generally don't care any more about
someone else's qualifications than I care about what they think of mine.

 If a $1500 PRS-10 is out-of-bounds even for measurement purposes against a
 ~$250 embedded system + GPS puck
 
 I have a PRS-10 and s GPSD(D)OCXO system.  I even have a decent counter and 
 scope.  I didn't say it was out of bounds for measurement I said the 
 opposite.  Are you one of those opposite guys?  If I say X are you going to 
 say I said not-X?


If we're talking about data, if X is right, then I'm hopefully going to say X 
is right.

 [ ... ]
 Without measuring the
 local clock against some other clock or oscillator which is known to be
 accurate to sub-microsecond levels, one doesn't have the data needed to draw
 conclusions about the actual timekeeping precision.
 
 I (sort of) agree with you but nothing you've said addresses that issue.  But 
 you don't have to believe me.  Just pay attention to any of the people that 
 have tried to point out your errors.

And what errors would these be?

Regards,
-- 
-Chuck

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

Re: [ntp:questions] Red Hat vote for chrony

2014-12-07 Thread William Unruh

On 2014-12-07, Charles Swiger cswi...@mac.com wrote:
...
 That's why NTP can act as a thermometer.  The big problem is temperature 
 induced wander and that's something (back to RedHat and Chrony) Chrony 
 claims to do better.

 Yes, ntpd and chrony will notice temperature changes causing a frequency 
 drift, at least
 when a system is using cheap AT-cut XOs, which commonly show a 
 temperature-dependency
 frequency variation in the 10s of PPM range for a 10 C change around room 
 temperature.
 A more expensive SC-cut XO will likely remain stable to a few PPM for such a 
 range,
 and a calibrated TCXO or OCXO will do better still.

 I suspect most people are a bit more likely to use air conditioning to 
 control ambient
 temperature changes then they are to desolder and swap out their crystals in 
 the
 hopes of obtaining more precise timekeeping

Actually air conditioning is largely irrelevant because it is not
ambient air temperature changes that are most important, but temp
changes inside the case caused by differing loads on the system. 

One of my collegues debvised a script whose sole purpose was to stress
the cpus so he could use the air coming out to dry his socks. 
Ie, cpu load drives temp change which produces time shifts. 

And it is there that chrony tends to be better at keeping track of the
rate changes.


 Regards,

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

Re: [ntp:questions] Red Hat vote for chrony

2014-12-07 Thread William Unruh

On 2014-12-07, Charles Swiger cswi...@mac.com wrote:
On Dec 6, 2014, at 8:33 AM, William Unruh un...@invalid.ca wrote:
On 2014-12-06, Charles Swiger cswi...@mac.com wrote:

I have given you the quotes from the chrony docs. Where do you get your
statement from?

The chrony docs, section 5.3.4:

http://chrony.tuxfamily.org/manual.html#How-can-I-improve-the-accuracy-of-the-system-clock-with-NTP-sources_003f

OK, lets quote the whole section
[ ...section snipped, as you found what I linked to and even quoted before...
]
Note the caveates : server located on the same lan. In fact more
frequent polling IS better especially when one uses the a system with
memory-- ie where the system uses the offsets measured for the last 64
times to figure out what the best time now is.

Yes, so chrony recommends using maxpoll=4 to the LAN, and not only to local
refclocks.

No, read the chrony docs. the default is maxpoll 10 minpoll 5.
That the faq as an example uses 2 and 4 is I agree stupid. It is faq. I
have no idea who wrote it.

But, compare this with the actual documentation for chrony, not this
faq which I quoted, and you erased. (Minpoll 5 maxpoll 10)

Dude, give it a rest. You've just acknowledged that the chrony docs at the
URL
ending with manual.html directly above recommend using maxpoll=4 to the LAN.

No, the FAQ has that as an example.

Yes, the default values compiled into chrony of minpoll=5 maxpoll=10 are
nearly
the same as what ntpd uses, which is polite when talking to the NTP pool or
other WAN sources that you haven't made prior arrangements with.

Can we skip the pendantry involved between default and recommended,
especially when you seem to prefer the recommended faster polling yourself?

Especially when the document you quote does not use the word
recommended It uses the word example.

Just like your claim about whether ntpd cares about figuring out the local
clock frequency or whether it only chases the offset was wrong?

ntpd does not care about figuring out the local clock frequency.

You keep repeating this assertion when it is quite obviously wrong.

Above, you've acknowledged that ntp.drift contains the (frequency) offset
for the clock. That's the single most important piece of data to have
around even if the machine loses network connectivity with other
timeservers,
or ntpd is restarted, or the machine itself is rebooted.

It is ONLY used when the ntpd is started/restarted.
If it makes you feel happy, yes ntpd does know about the current drift
rate.

Try not to confuse making me happy with being able to state the truth,
be honestly mistaken about a point but also acknowledge it once corrected,
or chosing to be wilfully dishonest.

Nothing personal: everyone faces such a choice

When ntpd has been up for a while using default maxpoll=10, how many past
polls
are available (per timesource), and what interval of time does that represent?

You answered that below, in fact:

Note that before it actually runs, it does remember the past 8 offsets AND
delays,

...which turns into 8 * 1024 seconds ~= 2.27 hours. If we cannot manage to
agree that this data is kept in memory by ntpd, then further discussion of
what
ntpd might or might not do in discarding 7 out of 8 polls and so forth is
completely moot.

It is not used to set the clock. NOte that I will agree that ntpd also
writes to a file the measurements in the logs. So what? It is not used
by ntpd.

(Starting from a false premise proves nothing about the following conclusion.)

Since you keep wanting to say I am wrong, why do you not tell us how
ntpd works in your understanding?

Let me provide three responses:

Thought so. I interpret 1 as I don't know, 2 as the fewer statements
I make the less others can point out. For 3) how many patches and to
what have you submitted?

...and skip the rest as

Re: [ntp:questions] Red Hat vote for chrony

2014-12-06 Thread Charles Swiger

On Dec 5, 2014, at 8:39 PM, William Unruh un...@invalid.ca wrote:

This is obviously false. What do you think /etc/ntp.drift is?

It is the offset from the standard rate of the clock. That memory is
never used except on bootup. ntpd has to know how much to alter the
drift.

Ah, so you acknowledge that your original statement was wrong.

That wasn't intended to be a trick question.

Hmm. Unless one considers intellectual honesty to be tricky, perhaps

Just like your claim whether the chrony docs recommend using maxpoll=4
across the network to a LAN timesource or not was wrong?

I have given you the quotes from the chrony docs. Where do you get your
statement from?

The chrony docs, section 5.3.4:

http://chrony.tuxfamily.org/manual.html#How-can-I-improve-the-accuracy-of-the-system-clock-with-NTP-sources_003f

Just like your claim about whether ntpd cares about figuring out the local
clock frequency or whether it only chases the offset was wrong?

ntpd does not care about figuring out the local clock frequency.

You keep repeating this assertion when it is quite obviously wrong.

Figuring out the local clock frequency is the most important thing
ntpd does. Getting that right means that the local clock can be trusted
to provide reasonably accurate time for a decent while even if freewheeling.

(Or for the folks who don't care whether their noon is a minute off from
real time, just so long as everything on the LAN in their isolated island
is mutually synced and that there are 3600 computer seconds per hour of
wall clock time.)

Regards,
--
-Chuck
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Red Hat vote for chrony

2014-12-06 Thread David Woolley


On 06/12/14 12:27, Charles Swiger wrote:

But to try and stay on point:  how do you measure the performance of a typical 
disciplined system (virtual) clock in a general purpose computer -- ideally 
without specialized hardware and software but those are okay if the results can be 
meaningfully generalized.  Given those measures you can decide if you prefer NTP, Chrony, 
SNTP or something else.



You setup a high quality clock somewhere and pull timestamps from the
general purpose computer you want to measure.  Something like Nagios


This only works for measuring the ability to cope with time source that 
is an order or magnitude or so worse than your high quality source.


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

Re: [ntp:questions] Red Hat vote for chrony

2014-12-06 Thread David Woolley


On 06/12/14 12:27, Charles Swiger wrote:

Some folks will be satisfied with Miroslav Lichvar's simulations but I'm not 
smart enough to understand them.  Other's will be convinced because they can 
run Chrony on a Unix laptop and save power or discipline a clock with only a 
few minutes a day of connect time.  I don't know who those people are.



Sure, those seem to have been the major use-cases that chrony wanted to handle.


RHEL, the subject of this thread, is not intended for laptops; it is 
intended for mission critical servers.


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

Re: [ntp:questions] Red Hat vote for chrony

2014-12-06 Thread David Lord


Charles Swiger wrote:

On Dec 5, 2014, at 5:55 PM, Paul tik-...@bodosom.net wrote:
[ ... ]

Even back in 2002 with very inexpensive commodity hardware, FreeBSD was
able to achieve accuracy measured to ~260 nanoseconds:

H.  So phk uses a $1,500 rubidium standard as a system oscillator and
you call it inexpensive and commodity.


No, he used a $1500 rubidium clock to accurately measure the timekeeping
quality of a $220 Soekris computer, and concluded:

I have earlier complained that no good and cheap hardware were available which 
could timestamp a PPS signal reliably and precisely but now the Soekris computer has 
proven that it does indeed deliver just that: With a pricetag of approx USD220 (single 
unit including enclosure) this is the best hardware you can find for a stratum 1 NTP 
server.

If you wanted to drive such hardware via a ~$40 GPS puck, you'd probably
see an accuracy of around a microsecond, perhaps a bit worse depending
on the timekeeping accuracy which the GPS puck provides.  That was also
the level of accuracy I was seeing from generic Intel hardware running
FreeBSD as a stratum 1 with a GPS source.

I've used a digital frequency counter which had an onboard TCXO (or possibly
a DTCXO) for measuring.  Although the frequency counter supported receiving
higher-quality PPS timing from an external atomic clock, I've never had a
Cs or Rb source, so I won't claim to have measured sub-microsecond accuracy 
with it.


He also ran a particular install of BSD and a non-standard NTP.


I believe he ran FreeBSD 4.x and likely the ntpd from ports.

Regards,


Not quite

I believe this clock project needed a little work with soldering
iron and also ntpd/freebsd had to be modified to support the
sc520 gpio.

Soekris net4501 with AMD Elan sc520 cpu which has internal time
register resolution of around 100n.

System clock I believe used a TAPR clock-block frequency
synthesizer and a FATpps signal conditioner kits.

I couldn't find any UK supplier for the parts and shipping costs
from the states was too expensive.


David

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

Re: [ntp:questions] Red Hat vote for chrony

2014-12-06 Thread William Unruh

On 2014-12-06, Charles Swiger cswi...@mac.com wrote:

On Dec 5, 2014, at 8:39 PM, William Unruh un...@invalid.ca wrote:

This is obviously false. What do you think /etc/ntp.drift is?

It is the offset from the standard rate of the clock. That memory is
never used except on bootup. ntpd has to know how much to alter the
drift.

Ah, so you acknowledge that your original statement was wrong.

That wasn't intended to be a trick question.

Hmm. Unless one considers intellectual honesty to be tricky, perhaps

Just like your claim whether the chrony docs recommend using maxpoll=4
across the network to a LAN timesource or not was wrong?

I have given you the quotes from the chrony docs. Where do you get your
statement from?

The chrony docs, section 5.3.4:

http://chrony.tuxfamily.org/manual.html#How-can-I-improve-the-accuracy-of-the-system-clock-with-NTP-sources_003f

OK, lets quote the whole section
The optimal polling interval depends on many factors, this includes the
ratio between the wander of the clock and the network jitter (sometimes
expressed in NTP documents as the Allan intercept), the temperature
sensitivity of the crystal oscillator and the maximum rate of change of
the temperature. An example of the directive for a server located in the
same LAN could be

server ntp.local minpoll 2 maxpoll 4 polltarget 30

Note the caveates : server located on the same lan. In fact more
frequent polling IS better especially when one uses the a system with
memory-- ie where the system uses the offsets measured for the last 64
times to figure out what the best time now is.

But, compare this with the actual documentation for chrony, not this
faq which I quoted, and you erased. (Minpoll 5 maxpoll 10)

Just like your claim about whether ntpd cares about figuring out the local
clock frequency or whether it only chases the offset was wrong?

ntpd does not care about figuring out the local clock frequency.

You keep repeating this assertion when it is quite obviously wrong.

It is ONLY used when the ntpd is started/restarted.
If it makes you feel happy, yes ntpd does know about the current drift
rate. It knows nothing about the past drift rate. That is what I call
memory. And in normal operation, it does not even know about the current
drift rate-- it is the operating system that does that. All ntpd does is
to change the current drift rate to try to minimize the offset.

Since you keep wanting to say I am wrong, why do you not tell us how
ntpd works in your understanding?

But it does not figure out the clock frequency. It just changes the
clock frequency to try to eliminate the offset just measured.

Note that before it actually runs, it does remember the past 8 offsets
AND delays, These are not used in the ntp clock control algorithm. These
are used to select the one with the lowest delay, to feed to the
algorithm as the current offset, to use in changing the frequency,
and the rest are unused.

Note that ntpd also keeps itself in memory, so it remembers its own
code as well.

So to be perfectly clear, ntp does not remember past events to use, in
addition to the current event, in adjusting the rate of the clock.
That is what I call memory. That is what I call a non-Markovian process.

Which chrony and ntpd do well.

Regards,

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

Re: [ntp:questions] Red Hat vote for chrony

2014-12-06 Thread David Woolley


On 06/12/14 16:33, William Unruh wrote:


memory. And in normal operation, it does not even know about the current
drift rate-- it is the operating system that does that. All ntpd does is


That's because part of the NTP algorithm is implemented in the kernel 
where it can be done per tick with negligble overhead.



to change the current drift rate to try to minimize the offset.


It, or the NTP code in the kernel, maintains two separate corrections, 
one for short term phase errors and one for long term frequency errors.





IF the operating system is incapable of changing the clock rate, ntpd
tries to do it for the operating system. Every second it resets the
clock to take into account the error in the rate of the clock. In this
case, ntpd remembers the current drift rate. But only the current drift
rate. Again, it has no memory of the past.


The very long time constant means that it remembers many hours into the 
past when operating at the longest poll interval.  In fact your real 
complaint is not that it doesn't use historical data, but that it looks 
too far back in history.


If I read https://www.eecis.udel.edu/~mills/ntp/html/discipline.html 
correctly, and allowing for times really meaning plus, the frequency 
control time constant is 2048 seconds (34 minutes) for poll=6 and about 
9 hours for poll 10.


As noted in that paper, there are two correction terms, a relatively 
fast one to correct the phase, and the one discussed above to correct 
the long term frequency.


I suspect that chrony does work well in a workstation environment, where 
temperature is not well controlled and loading is bursty, but will lose 
some of its advantages in the server environment, at which RHEL is aimed.


(Actually, a thought struck me that the real problem with ntpd may be 
that the time constant for the phase correction  (and poll rate) is tied 
to that for the frequency correction.)



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

Re: [ntp:questions] Red Hat vote for chrony

On Sat, Dec 6, 2014 at 7:27 AM, Charles Swiger cswi...@mac.com wrote:

 Um, certainly?  Are you concerned about the quality of the XO which
 shipped with a Soekris board?
 That'd be important if you were running a stratum-2+ timeserver.


If you don't do the reading you won't understand the problems.  Here's a
salient quote from Ackerman

*To implement high-performance timekeeping, you need to modify the net4501
board to accept an external clock signal*, as well as use the high
resolution timer. These steps require fairly good soldering skills as the
surface mount components on the board are tiny; if you're unsure of
yourself, find someone with SMT soldering experience to help you.
Locate and remove the Soekris clock crystal (X1). A small heat gun is the
best way to do this, but with care a soldering iron and solder wick can be
used to lift the part. The only pin on X1 that we'll use is the one in the
upper left corner, so make sure you don't damage that solder pad. 

And regarding the Clock-Block

The Clock-Block is a flexible frequency synthesizer that can be used for
many timing and clocking purposes.It accepts an *external reference signal*
from 2 MHz to 50 MHz, and can be programmed via DIP switches to generate
output frequencies in the range of about 500 kHz to 250 MHz. The output is
a square wave at either 3.3 or 5 volts peak-to-peak. An on-board divider
circuit allows the output frequency to be reduced by factors of 16 to 16384
for specialized applications.* One application for the Clock-Block is to
replace the crystal oscillator of a PC motherboard to allow synchronizing
the PC's clock to an external high-precision reference*.

This isn't about modifying a 4501 for testing or measurement.  It's about
modifying it for high resolution production service.  By the way in the
current era the 4501 is poor choice.  Common SoC based systems like the
BeagleBone Black have everything you need (and more), are cheaper and no
un-soldering is required.

You setup a high quality clock somewhere and pull timestamps from the
 general purpose computer you want to measure.


Perhaps you're unfamiliar with the problem PTP solves.  That is one of
things you have to deal with if you're going to use external measurements
to assess the quality of your clock discipline.

Maybe you're also unfamiliar with what NTP is doing:  It disciplines a
virtual (system) clock which is derived from the on-board (usually
uncompensated) crystal
.  That's why NTP can act as a thermometer.  The big problem is temperature
induced wander and that's something (back to RedHat and Chrony) Chrony
claims to do better.


I suspect fiddling something into an external TIC is a way to go but
something both simpler and more clever is what I'm curious about.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Red Hat vote for chrony

On Sat, Dec 6, 2014 at 11:12 AM, William Unruh un...@invalid.ca wrote:

 You do not understand them, but feel confident to make recommendations
 despite that?


While I'm not making a broader statement about who understands what I
believe you're conflating my comments with those from cswi...@mac.com.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Red Hat vote for chrony

On Sat, Dec 6, 2014 at 11:12 AM, William Unruh un...@invalid.ca wrote:

 And in my tests 10 years ago or so, I used a local gps clock to test the
 ability of chrony and ntpd to discipline a computer clock networked to
 another server which was disciplined by a gps. Thus the network was the
 same, and the difference was ntpd vs chrony.
 chrony was better. Primarily, I think, because chrony responded more
 quickly to drift rate changes due to temp changes.


I looked at your data back in the day.  Even then I thought they were old.
Of course if the secret sauce is loop constants (I haven't read the Chrony
architecture document, maybe because there isn't one) then perhaps the
results would still be the same.


  Other's will be convinced because they can run Chrony on a Unix laptop
 and save power or discipline a clock with only a few minutes a day of
 connect time.  I don't know who those people are.

 Both chrony and ntpd
 send out the same packets and both have roughly the same polls, so where
 is this powersaving coming from?)


And I thought you were chugging the kool-aid:

Using chrony over ntp has also other advantages:

   - smaller memory footprint (1.3MB vs 6MB resident size)
   - no unnecessary process wakeups, this is good for powersaving. The ntpd
   process normally wakes up every second.
   ...

For me it's consistency.  I want to run the same timekeeping software
everywhere* and Chrony doesn't run everywhere.

*my everywhere is obviously not anyone else's everywhere.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Red Hat vote for chrony

2014-12-06 Thread William Unruh

On 2014-12-06, Paul tik-...@bodosom.net wrote:
 On Sat, Dec 6, 2014 at 11:12 AM, William Unruh un...@invalid.ca wrote:

 And in my tests 10 years ago or so, I used a local gps clock to test the
 ability of chrony and ntpd to discipline a computer clock networked to
 another server which was disciplined by a gps. Thus the network was the
 same, and the difference was ntpd vs chrony.
 chrony was better. Primarily, I think, because chrony responded more
 quickly to drift rate changes due to temp changes.


 I looked at your data back in the day.  Even then I thought they were old.
 Of course if the secret sauce is loop constants (I haven't read the Chrony
 architecture document, maybe because there isn't one) then perhaps the
 results would still be the same.

They are old, and naive. A much better job could be done. However, they
are indicative. As I mentioned it would be a really good project to have
someone do a better comparison-- both simulated for example with
Lichvar's simulation software, and real life measurements.


...

 Using chrony over ntp has also other advantages:

- smaller memory footprint (1.3MB vs 6MB resident size)
- no unnecessary process wakeups, this is good for powersaving. The ntpd
process normally wakes up every second.

That is to impliment the in-house frequency scaling on systems where
userland has no way of changing the frequency of the system clock. Under
linux and adjtimex one can alter the system clock (by up to 10% of
nominal,-- ntpd only uses max 500PPM, while chrony can use the full
range)
I do not know if ntpd shuts off that once per sec if the system clock
can be altered in the kernel. 

...

 For me it's consistency.  I want to run the same timekeeping software
 everywhere* and Chrony doesn't run everywhere.

True and fair enough. Chrony only works on Linux or bsd systems. (That could 
probably be
expanded to include OsX but I do not know if it does out of the box). It
does not do Windows, so if you have windows machines, chrony is not an
option. But then this thread was about Redhat, which is Linux.


 *my everywhere is obviously not anyone else's everywhere.

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

Re: [ntp:questions] Red Hat vote for chrony

On Sat, Dec 6, 2014 at 4:57 PM, William Unruh un...@invalid.ca wrote:

 But then this thread was about Redhat, which is Linux.



I understand that but it's not the point.  This thread is about a distro
defaulting to Chrony -- and why that's a bad (or good) thing. I say it's an
inconvenience because I'm uninterested in Chrony on Linux (RedHat or
otherwise). While we have many Linux boxes many of our servers are not
Linux/BSD based.  It's bad enough dealing with various versions of NTP
without having yet another critical part of the infrastructure be
different.  Luckily we're busy moving away from RedHat.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Red Hat vote for chrony

2014-12-06 Thread William Unruh

On 2014-12-06, Paul tik-...@bodosom.net wrote:
 On Sat, Dec 6, 2014 at 4:57 PM, William Unruh un...@invalid.ca wrote:

 But then this thread was about Redhat, which is Linux.



 I understand that but it's not the point.  This thread is about a distro
 defaulting to Chrony -- and why that's a bad (or good) thing. I say it's an
 inconvenience because I'm uninterested in Chrony on Linux (RedHat or
 otherwise). While we have many Linux boxes many of our servers are not
 Linux/BSD based.  It's bad enough dealing with various versions of NTP
 without having yet another critical part of the infrastructure be
 different.  Luckily we're busy moving away from RedHat.

AFAIK they will still ship ntpd as well. You can pretty easily uninstall
chrony and install ntpd if that is what you desire. You have to set up
lots of other stuff on your systems anyway. And this default is way way
down on the list of problems in comparison to  Redhat defaulting to systemd:-)

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

Re: [ntp:questions] Red Hat vote for chrony

On 2014-12-05, Charles Swiger cswi...@mac.com wrote:
 On Dec 4, 2014, at 7:00 PM, William Unruh un...@invalid.ca wrote:
 [ ... ]
 Actually Miroslav Lichvar IS an expert. He is the chrony maintainer, has
 done a lot of testing comparing chrony to ntpd ( which showed that
 chrony controlled the clock a factor of 2 to 20 times better than ntpd
 did), and is with Redhat. 

 The data I've seen for chrony suggests it handles broken clocks such as
 commonly found in VMs better than ntpd does.  The tradeoff is that
 chrony prioritizes chasing the reference time over first trying to ensure
 that the local clock frequency is stable, whereas ntpd really wants
 to make sure that the local clock counts 3600 seconds in each hour of
 wall-clock time and then worries about slewing the local time to match
 up with the reference time.

Nope. ntp changes the rate of the local clock to correct offsets. That
is all it does. It does not make the rate correct, and then the offset.
It simply alters the rate at any time so as to decrease the offset, and
it does this measurement by measurement. It has no memory. 
Chrony uses the last N measurements to make the best estimate of the
rate and the offset that it can. It sets the rate to the best estimate
of the true rate, and then adds a rate correction to decrease the
offset. 


 It's informative to note that the chrony docs (section 5.3.4) recommend
 using minpoll=2 and maxpoll=4!  With those settings chrony will send 225

that is for refclocks. 

 polls per hour, versus 3.5 polls per hour for ntpd with its maxpoll=10.
 Assuming arguendo the claim of a factor of 20 times better is true, I
 still don't care to pay the price of a factor of 64 times more network polls.

You may set the minpoll and maxpoll to whateever you want. But chrony
does not advocate a maxpoll of 4 over the network. Read again. 


 Furthermore-- unfortunately-- I have yet to see data on the accuracy of
 chrony measured against high-quality TCXO or Rb/Cs reference clocks,
 such as the PRS-10 that PHK used:


 http://www.thinksrs.com/products/PRS10.htm

 ...the current version of which claims to have a +/- 10 ns accuracy for
 the PPS signal.  Instead, most of the data I've seen provided for chrony
 has involved comparing local clock timestamps to the reference timesource
 or to some other network timesource, without detailed information as to the
 accuracy of those references.

Nope. I have done measurements on the net where I compared the net to a
gps PPS source. The computer PPS has an accuracy  of about 1microsec and
that can be compared to the network time. I get an increase of about 2-3
times better than ntp. Lichvar got something like 20 times better using
a PPS against a local high accuracy time source. The main reason seems
to be that chrony is far more algile-- it catches temperature drifts
much more quickly than ntpd does, for the same poll. Remember that ntpd
throws out 85% of the measurements it makes, in order to try (poorly) to
compensate for network up-down inequalities. Sometimes, if the network
is very variably assymetric that can improve results. Usually it simply
throws away valuable measurements. ntpd is also designed to act very
slowly to changes in rate. It is a design philosophy Mills defends
strongly, with the matra of stability. Chrony, because of its long term
memory, recognizes and responds to rate variations much more quickly,
with no sign of instability. It would be good to have a detailed
analysis of the chrony algorithm to see if there are corner cases where
chrony does worse by going unstable. ntpd is simple to analyse (if one
ignores the extreme non-linearity of the jump if the offset is greater
than 128ms.)

If you would like to compare chrony vs ntp with your PRS10, please do
so. Otherwise look at some of he numbers I have on
www.theory.physics.ubc.ca/chrony



 Of course you're not going to see much delta between the local clock and the
 reference that you're polling every 16 seconds.  Without measuring the
 local clock against some other clock or oscillator which is known to be
 accurate to sub-microsecond levels, one doesn't have the data needed to draw
 conclusions about the actual timekeeping precision.

Actually not true. How do you think the standards of the various
contries determine the accuracy of their clocks. They have no better
time standard to compare them with. And yet they confidently will quote
accuracy figures for their clocks. Study that.



 Regards,

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

Re: [ntp:questions] Red Hat vote for chrony

On Dec 5, 2014, at 3:42 AM, William Unruh un...@invalid.ca wrote:
On 2014-12-05, Charles Swiger cswi...@mac.com wrote:
On Dec 4, 2014, at 7:00 PM, William Unruh un...@invalid.ca wrote:
[ ... ]
Actually Miroslav Lichvar IS an expert. He is the chrony maintainer, has
done a lot of testing comparing chrony to ntpd ( which showed that
chrony controlled the clock a factor of 2 to 20 times better than ntpd
did), and is with Redhat.

The data I've seen for chrony suggests it handles broken clocks such as
commonly found in VMs better than ntpd does. The tradeoff is that
chrony prioritizes chasing the reference time over first trying to ensure
that the local clock frequency is stable, whereas ntpd really wants
to make sure that the local clock counts 3600 seconds in each hour of
wall-clock time and then worries about slewing the local time to match
up with the reference time.

Nope. ntp changes the rate of the local clock to correct offsets. That
is all it does. It does not make the rate correct, and then the offset.

If you don't know what the rate of the local clock is, how can you figure
out the proper slewing rate?

One can obviously keep slewing the clock towards the reference time even
without having a good idea of the intrinsic drift, but such an approach
will tend to overshoot the ideal frequency adjustment and ring or
oscillate back and forth.

It simply alters the rate at any time so as to decrease the offset, and
it does this measurement by measurement. It has no memory.

This is obviously false. What do you think /etc/ntp.drift is?

Furthermore, I distinctly recall you complaining that ntpd's clock filter
throws away 7 out of 8 polls; even though you are mis-interpreting the
situation, you at least acknowledged that ntpd is keeping track of prior
data.

Or did someone else write Message-id: Hh0tu.8666$tr7.4...@fx22.iad?

Chrony uses the last N measurements to make the best estimate of the
rate and the offset that it can. It sets the rate to the best estimate
of the true rate, and then adds a rate correction to decrease the
offset.

Yes, that's a reasonable approach.

It's informative to note that the chrony docs (section 5.3.4) recommend
using minpoll=2 and maxpoll=4! With those settings chrony will send 225

that is for refclocks.

polls per hour, versus 3.5 polls per hour for ntpd with its maxpoll=10.
Assuming arguendo the claim of a factor of 20 times better is true, I
still don't care to pay the price of a factor of 64 times more network polls.

You may set the minpoll and maxpoll to whateever you want. But chrony
does not advocate a maxpoll of 4 over the network. Read again.

I suggest following your own advice before trying to correct others.

http://chrony.tuxfamily.org/manual.html#How-can-I-improve-the-accuracy-of-the-system-clock-with-NTP-sources_003f

5.3.4 How can I improve the accuracy of the system clock with NTP sources?

Select NTP servers that are well synchronised, stable and close to your
network. It’s better to use more than one server, three or four is usually
recommended as the minimum, so chronyd can detect falsetickers and combine
measurements from multiple sources.
[ ... ]
The optimal polling interval depends on many factors, this includes the ratio
between the wander of the clock and the network jitter (sometimes expressed in
NTP documents as the Allan intercept), the temperature sensitivity of the
crystal oscillator and the maximum rate of change of the temperature. An
example of the directive for a server located in the same LAN could be

server ntp.local minpoll 2 maxpoll 4 polltarget 30

The docs aren't talking about reference clocks here, they are talking about
polling another machine over the LAN.

Furthermore-- unfortunately-- I have yet to see data on the accuracy of
chrony measured against high-quality TCXO or Rb/Cs reference clocks,
such as the PRS-10 that PHK used:

http://www.thinksrs.com/products/PRS10.htm

...the current version of which claims to have a +/- 10 ns accuracy for
the PPS signal. Instead, most of the data I've seen provided for chrony
has involved comparing local clock timestamps to the reference timesource
or to some other network timesource, without detailed information as to the
accuracy of those references.

Nope. I have done measurements on the net where I compared the net to a
gps PPS source. The computer PPS has an accuracy of about 1microsec and
that can be compared to the network time.

About a microsecond is two orders of magnitude worse than ~10 nanoseconds.
As I said before, I'd be happy to review data for chrony taken against that
quality of reference.

I get an increase of about 2-3
times better than ntp. Lichvar got something like 20 times better using
a PPS against a local high accuracy time source. The main reason seems
to be that chrony is far more algile-- it catches temperature drifts
much more quickly than ntpd does, for the same poll.

More agile is

Re: [ntp:questions] Red Hat vote for chrony

2014-12-05 Thread David Woolley


On 05/12/14 08:42, William Unruh wrote:


Nope. ntp changes the rate of the local clock to correct offsets. That
is all it does. It does not make the rate correct, and then the offset.


Not true.  It applies a correction for the offset, such that if that 
were the only error, it would be eliminated exponentially with a time 
constant that is related to the poll rate.  I believe it expects to 
update this correction well before it is fully applied.


At the same time, it applies a correction to the long term estimate of 
the frequency, with a much longer time constant.




much more quickly than ntpd does, for the same poll. Remember that ntpd
throws out 85% of the measurements it makes, in order to try (poorly) to


If the round trip variability was sufficiently low that this pre-filter 
were not needed, any variations in the samples it is ignoring would be 
largely suppressed by the loop filters, which have time constants that 
are significantly longer than even eight times the poll interval.  ntpd 
is heavily oversampling, which means that the min and maxpols quoted for 
chrony imply an even higher excess rate.





Actually not true. How do you think the standards of the various
contries determine the accuracy of their clocks. They have no better
time standard to compare them with. And yet they confidently will quote
accuracy figures for their clocks. Study that.


I presume that whatever time transfer mechanism they use has well 
characterised errors.  NTP operates in an environment where the errors 
are not well characterised.


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

Re: [ntp:questions] Red Hat vote for chrony

2014-12-05 Thread Paul

On Fri, Dec 5, 2014 at 9:37 AM, Charles Swiger cswi...@mac.com wrote:

 I also make sure that my
 timeservers are running in temperature-controlled environments so that
 such daily drifts you mention are minimized.


I'm starting to think that people answering questions are unsure of the
real question so they make a number of assumptions.  If you care about
sub-millisecond time then you need to say that and the question should be
answered in that context.  I suspect most of the questions here refer to
sub-second accuracy and most of the elaboration is unneeded.  If all your
external clocks fail I suspect the typical user can depend on the
disciplined virtual clock for days.

For almost all of human history, the sun or the fixed celestial heavens
 have provided the most accurate time reference available.  Even today,
 we add (or subtract, in theory) leap seconds in order to keep UTC and UT1
 aligned to better than a second courtesy of IERS.

 Yes, the USNO, CERN, and so forth now do have sufficiently high quality
 atomic clocks which have better timekeeping precision than celestial
 observations.


I think there's some confusion here.  Search for BIPM paper clock or read 
http://www.ggos-portal.org/lang_en/GGOS-Portal/EN/Topics/Services/BIPM/BIPM.html



 Such a point is orthogonal to the notion of how to measure a local clock


I think this is an interesting question.  How does one get high resolution
measurements of the error in the virtual clock maintained with NTP (or
Chrony)?  I thought it was done with purpose built systems.  I don't expect
a random version of Linux on generic hardware to be able to maintain the
clock at nanosecond scale.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Red Hat vote for chrony

On 2014-12-05, Charles Swiger cswi...@mac.com wrote:
 On Dec 5, 2014, at 3:42 AM, William Unruh un...@invalid.ca wrote:
 On 2014-12-05, Charles Swiger cswi...@mac.com wrote:
 On Dec 4, 2014, at 7:00 PM, William Unruh un...@invalid.ca wrote:
 [ ... ]
 Actually Miroslav Lichvar IS an expert. He is the chrony maintainer, has
 done a lot of testing comparing chrony to ntpd ( which showed that
 chrony controlled the clock a factor of 2 to 20 times better than ntpd
 did), and is with Redhat. 
 
 The data I've seen for chrony suggests it handles broken clocks such as
 commonly found in VMs better than ntpd does.  The tradeoff is that
 chrony prioritizes chasing the reference time over first trying to ensure
 that the local clock frequency is stable, whereas ntpd really wants
 to make sure that the local clock counts 3600 seconds in each hour of
 wall-clock time and then worries about slewing the local time to match
 up with the reference time.
 
 Nope. ntp changes the rate of the local clock to correct offsets. That
 is all it does. It does not make the rate correct, and then the offset.

 If you don't know what the rate of the local clock is, how can you figure
 out the proper slewing rate?

ntpd does not care what the rate is. If it sees an offset, it alters the
rate todecrease that offset. It keeps doing this until the offset is
gone. It is designed so that the overshoot is very small (critical
damping). 

 One can obviously keep slewing the clock towards the reference time even
 without having a good idea of the intrinsic drift, but such an approach
 will tend to overshoot the ideal frequency adjustment and ring or
 oscillate back and forth.

Not if it is properly designed (critical damping). Mills did a good job
of designing a feedback system. As he says it is standard engineering
practice.


 It simply alters the rate at any time so as to decrease the offset, and
 it does this measurement by measurement. It has no memory. 

 This is obviously false.  What do you think /etc/ntp.drift is?

It is the offset from the standard rate of the clock. That memory is
never used except on bootup. ntpd has to know how much to alter the
drift.


 Furthermore, I distinctly recall you complaining that ntpd's clock filter
 throws away 7 out of 8 polls; even though you are mis-interpreting the
 situation, you at least acknowledged that ntpd is keeping track of prior
 data.

But it does not use them. It looks at the delays, and choses the
shortest delay from the last 8 offset measurements. The scheme is a
simple feedback system, which remembers the current drift and
measures the current offset. That by current it means the offset with
the lowest delay of the last 8 measurements does not alter the design.
It is a Markovian system. It does not remember what the drift or the
offset was 15 measurements ago, for example. 

If you really want to understand ntpd, read the documentation or Mill's
book. Don't try picking apart a clearly very short descritption.
delta r_i= alpha (remotetime_i - localtime_i) is the equation used,
where delta r_i is the change in the rate of the clock, remotetime_i is
the time as measured by the ntp exchange procedure of he remote clock,
and localtime_i is the time on the local clock when that remote time was
measured. alpha is a constant chosed to make the feedback loop be close
to critically damped. 

In order to make the system resistant to varying assymetric travel
times, they introduced another step. The i in the above is not every
measurement, but the best of 8 (ie the one with the shortest delay,
under the assumption that that will be the one with least assymetry in
the travel path). But it also means that 85 % of the measurements are
simply discarded-- never used to determine the clock offsets or delays
or anything. So, ntpd loads the network with 8 times as many queries
as it actually uses. If there are large variations in the delays on the
two paths, this is probably as good as you can do. If there are not,
this is a very wasteful procedure and means you throw away data that you
could have used to better control your clock. 

Chrony remembers up to 64 past offsets and rates, and uses those in a
linear regression to get the best estimate of the current offset and
rate. It changes how long a memory it uses by estimating whether or not
the a linear fit is a good approximation to that data series, and throws
away old measurements until it does feel that a linear fit is a good
estimate. It does not try to do assymmetric path corrections which might
be a detraction of chrony in some situations (my measurements indicate
it is not on the systems I have looked at at least, but there may be
situations in which it might help). 

BEcause of the clock selection algorithm, and the conservative choice
for alpha, ntpd responds very slowly to changes in the rates due to
temperature changes for example. chrony is much faster, and I believe
this is one of the reasons for the better control that chrony gives.

Re: [ntp:questions] Red Hat vote for chrony

On 2014-12-05, David Woolley david@ex.djwhome.demon.invalid wrote:
 On 05/12/14 08:42, William Unruh wrote:

 Nope. ntp changes the rate of the local clock to correct offsets. That
 is all it does. It does not make the rate correct, and then the offset.

 Not true.  It applies a correction for the offset, such that if that 
 were the only error, it would be eliminated exponentially with a time 
 constant that is related to the poll rate.  I believe it expects to 
 update this correction well before it is fully applied.

??? Not sure what you mean by not true. ntpd corrects offsets by
changing the rate. ntp corrects rate changes by seeing the cumulative
offset changes and changes the rate to correct the offsets. 


 At the same time, it applies a correction to the long term estimate of 
 the frequency, with a much longer time constant.


 much more quickly than ntpd does, for the same poll. Remember that ntpd
 throws out 85% of the measurements it makes, in order to try (poorly) to

 If the round trip variability was sufficiently low that this pre-filter 
 were not needed, any variations in the samples it is ignoring would be 
 largely suppressed by the loop filters, which have time constants that 
 are significantly longer than even eight times the poll interval.  ntpd 
 is heavily oversampling, which means that the min and maxpols quoted for 
 chrony imply an even higher excess rate.

Those quotes were simply wrong. 
to quote from the chrony docs

3.4.2 Typical configuration files.
--

To illustrate how a dial-up home computer might be configured, example
configuration files are shown in this section.

   For the '/etc/chrony.conf' file, the following can be used as an
   example.

 server 0.pool.ntp.org minpoll 5 maxpoll 10 maxdelay 0.4 offline
 server 1.pool.ntp.org minpoll 5 maxpoll 10 maxdelay 0.4 offline
 server 2.pool.ntp.org minpoll 5 maxpoll 10 maxdelay 0.4 offline
 ...
 
Does that look any different from what ntpd recommends?

Also from the same document (chrony.txt in the docs that come with
chrony) 

'minpoll'
 Although 'chronyd' will trim the rate at which it samples the
 server during normal operation, the user may wish to constrain the
 minimum polling interval.  This is always defined as a power of 2,
 so tt/minpoll 5/ would mean that the polling interval cannot drop
 below 32 seconds.  The default is 6 (64 seconds).
 'maxpoll'
 In a similar way, the user may wish to constrain the maximum
 polling interval.  Again this is specified as a power of 2, so
tt/maxpoll 9/ indicates that the polling interval must stay at or
below 512 seconds.  The default is 10 (1024 seconds).







 Actually not true. How do you think the standards of the various
 contries determine the accuracy of their clocks. They have no better
 time standard to compare them with. And yet they confidently will quote
 accuracy figures for their clocks. Study that.

 I presume that whatever time transfer mechanism they use has well 
 characterised errors.  NTP operates in an environment where the errors 
 are not well characterised.

Not true. Remember that they are operating down at the sub nanosecond
level, and if you think transfer even across the room is well
characterized at that level, 

But anyway that comment of mine was not about transfer errors. It was a
reply tothe statement that the only way of characterizing the
uncertainty of clocks is to have one that keeps better time than the
clock one is looking at. 

But to get back to the chrony vs ntpd:

chrony operates in an environment where the errors are not well
characterised as well. IF you are in an environment where there are
large (factors of 2) changes in the travel times in each direction, the
clock filter of ntpd might give better results. It is something that has
not AFAIK been tested. I am not sure what the answer would be. 
HOwever, that is not true of most situations in which ntpd or chrony are
used. The dominant error is temperature fluctuations in which the clock
frequency wanders around. ntpd handles that badly. chrony handles it
better.  So do you use a system which maybe protects you better in
unusual situations, or one wich handles the typical case better?

chrony could be altered to try to estimate whether or not one is in a
case where there are large fluctuations in the travel times giving
fluctuating assymetries in the travel time, and if so apply something
like the ntpd clock filter. But it would have to be pretty bad I think
before it became necessary. 

It would be a good master's project for someone to do the comparison. 



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

Re: [ntp:questions] Red Hat vote for chrony

On Dec 5, 2014, at 11:47 AM, Paul tik-...@bodosom.net wrote:
 On Fri, Dec 5, 2014 at 9:37 AM, Charles Swiger cswi...@mac.com wrote:
 I also make sure that my
 timeservers are running in temperature-controlled environments so that
 such daily drifts you mention are minimized.
 
 I'm starting to think that people answering questions are unsure of the
 real question so they make a number of assumptions.  If you care about
 sub-millisecond time then you need to say that and the question should be
 answered in that context.

Well, we do have time enthusiasts around who like to achieve the best
precision they can, regardless of whether there is a specific business
justification or not.  :-)

 I suspect most of the questions here refer to
 sub-second accuracy and most of the elaboration is unneeded.

True; if you just want accuracy to the nearest second, you don't need
to do anything elaborate to achieve that.

Absent any other requirements, I think it reasonable for folks to target
~1 millisecond level of accuracy, which is quite doable on many platforms,
even using remote timeservers over the WAN.

 If all your external clocks fail I suspect the typical user can depend
 on the disciplined virtual clock for days.

For real hardware, sure-- once the intrinsic frequency drift has been setup,
you can free-run for days into weeks without drifting too far.  Cell phone
towers (especially CDMA) are a decent example of such fault-tolerant systems.

 For almost all of human history, the sun or the fixed celestial heavens
 have provided the most accurate time reference available.  Even today,
 we add (or subtract, in theory) leap seconds in order to keep UTC and UT1
 aligned to better than a second courtesy of IERS.
 
 Yes, the USNO, CERN, and so forth now do have sufficiently high quality
 atomic clocks which have better timekeeping precision than celestial
 observations.
 
 
 I think there's some confusion here.  Search for BIPM paper clock or read 
 http://www.ggos-portal.org/lang_en/GGOS-Portal/EN/Topics/Services/BIPM/BIPM.html

What confusion?  Certainly it's a decent paper to read

 Such a point is orthogonal to the notion of how to measure a local clock
 
 I think this is an interesting question.  How does one get high resolution
 measurements of the error in the virtual clock maintained with NTP (or
 Chrony)?  I thought it was done with purpose built systems.

Yes, you need to compare timestamps using purpose-built systems like a
TCXO, Cesium, or Rubidium clock connected ideally via fast-interrupt
driven parallel, serial, or network port which hopefully also provides
hardware timestamping to minimize the processing latency.

 I don't expect a random version of Linux on generic hardware to be able to
 maintain the clock at nanosecond scale.

True.  I don't expect any version of Linux to perform at nanosecond scale, but
that has as much to do with kernel bugs and compromises in timekeeping that
particular OS has chosen.

Even back in 2002 with very inexpensive commodity hardware, FreeBSD was able to
achieve accuracy measured to ~260 nanoseconds:

http://phk.freebsd.dk/soekris/pps/

...per a Rb-based atomic clock.  This is the sort of analysis I want to see
for chrony.

Regards,
-- 
-Chuck

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

Re: [ntp:questions] Red Hat vote for chrony

On Dec 5, 2014, at 11:53 AM, William Unruh un...@invalid.ca wrote:
[ ... ]
 It simply alters the rate at any time so as to decrease the offset, and
 it does this measurement by measurement. It has no memory. 
 
 This is obviously false.  What do you think /etc/ntp.drift is?
 
 It is the offset from the standard rate of the clock. That memory is
 never used except on bootup. ntpd has to know how much to alter the
 drift.

Ah, so you acknowledge that your original statement was wrong.

Just like your claim whether the chrony docs recommend using maxpoll=4
across the network to a LAN timesource or not was wrong?

Just like your claim about whether ntpd cares about figuring out the local
clock frequency or whether it only chases the offset was wrong?

Regards,
-- 
-Chuck

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

Re: [ntp:questions] Red Hat vote for chrony

2014-12-05 Thread Paul

On Fri, Dec 5, 2014 at 3:35 PM, Charles Swiger cswi...@mac.com wrote:

 Well, we do have time enthusiasts around who like to achieve the best
 precision they can, regardless of whether there is a specific business
 justification or not.  :-)


Sure but that doesn't help someone that just wants a simple (-minded)
configuration to keep a few clocks in sync.


  If all your external clocks fail I suspect the typical user can depend
  on the disciplined virtual clock for days.

 For real hardware, sure-- once the intrinsic frequency drift has been
 setup,
 you can free-run for days into weeks without drifting too far.  Cell phone
 towers (especially CDMA) are a decent example of such fault-tolerant
 systems.

c

While perhaps strictly correct I was talking about the common crystal in a
typical computer not the  Cesium, Rubidum or OCXO in a cell site and
there's really no basis for comparison.


 What confusion?  Certainly it's a decent paper to read


I misquoted.  This Without measuring the local clock against some other
clock or oscillator

suggests comparing a clock to a better frequency reference but BIPM creates
a virtual clock (with better Allen deviation) and everyone steers toward
that.  Perhaps you meant something else.

Yes, you need to compare timestamps using purpose-built systems like a
 TCXO, Cesium, or Rubidium clock


That wasn't my point.  You need a purpose built NTP server to expose

its virtual clock for comparison to an external frequency reference.  Of
course you need a purpose built reference but only in the sense that
you'd use real counter rather than one in a voltmeter.

 Even back in 2002 with very inexpensive commodity hardware, FreeBSD was
 able to
 achieve accuracy measured to ~260 nanoseconds:


H.  So phk uses a $1,500 rubidium standard as a system oscillator and
you call it inexpensive and commodity.  He also ran a particular install of
BSD and a non-standard NTP.  All of those are what I was referring to when
I said purpose built system to measure the variance of an NTP disciplined
virtual oscillator.  By the way high resolution low-latency counters in
computers have become commodity items.  The software to use them -- not so
much.

It might be nice to conduct a similar experiment with Chrony but it's all
pointless.  As Bill suggests you want to measure typical performance in
typical environments.  That's the bit I said was interesting and I don't
think the published numbers make it clear what's better.

Frankly I suspect even that is pointless.  If someone asked me how to do
NTP on the cheap I'd say buy or build some number of Laureline-like PLLs in
a box with a NTP packet emulator or some NTP servers off Ebay and run
SNTP/OpenNTP on the clients.   If you have a larger budget then buy
Meinberg, Microsemi et. al. new.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Red Hat vote for chrony

On Dec 5, 2014, at 5:55 PM, Paul tik-...@bodosom.net wrote:
[ ... ]
 Even back in 2002 with very inexpensive commodity hardware, FreeBSD was
 able to achieve accuracy measured to ~260 nanoseconds:
 
 H.  So phk uses a $1,500 rubidium standard as a system oscillator and
 you call it inexpensive and commodity.

No, he used a $1500 rubidium clock to accurately measure the timekeeping
quality of a $220 Soekris computer, and concluded:

I have earlier complained that no good and cheap hardware were available which 
could timestamp a PPS signal reliably and precisely but now the Soekris 
computer has proven that it does indeed deliver just that: With a pricetag of 
approx USD220 (single unit including enclosure) this is the best hardware you 
can find for a stratum 1 NTP server.

If you wanted to drive such hardware via a ~$40 GPS puck, you'd probably
see an accuracy of around a microsecond, perhaps a bit worse depending
on the timekeeping accuracy which the GPS puck provides.  That was also
the level of accuracy I was seeing from generic Intel hardware running
FreeBSD as a stratum 1 with a GPS source.

I've used a digital frequency counter which had an onboard TCXO (or possibly
a DTCXO) for measuring.  Although the frequency counter supported receiving
higher-quality PPS timing from an external atomic clock, I've never had a
Cs or Rb source, so I won't claim to have measured sub-microsecond accuracy 
with it.

 He also ran a particular install of BSD and a non-standard NTP.

I believe he ran FreeBSD 4.x and likely the ntpd from ports.

Regards,
-- 
-Chuck

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

Re: [ntp:questions] Red Hat vote for chrony

On Dec 5, 2014, at 5:55 PM, Paul tik-...@bodosom.net wrote:
[ ... ]
 Even back in 2002 with very inexpensive commodity hardware, FreeBSD was
 able to achieve accuracy measured to ~260 nanoseconds:
 
 H.  So phk uses a $1,500 rubidium standard as a system oscillator and
 you call it inexpensive and commodity.

No, he used a $1500 rubidium clock to accurately measure the timekeeping
quality of a $220 Soekris computer, and concluded:

I have earlier complained that no good and cheap hardware were available which 
could timestamp a PPS signal reliably and precisely but now the Soekris 
computer has proven that it does indeed deliver just that: With a pricetag of 
approx USD220 (single unit including enclosure) this is the best hardware you 
can find for a stratum 1 NTP server.

If you wanted to drive such hardware via a ~$40 GPS puck, you'd probably
see an accuracy of around a microsecond, perhaps a bit worse depending
on the timekeeping accuracy which the GPS puck provides.  That was also
the level of accuracy I was seeing from generic Intel hardware running
FreeBSD as a stratum 1 with a GPS source.

I've used a digital frequency counter which had an onboard TCXO (or possibly
a DTCXO) for measuring.  Although the frequency counter supported receiving
higher-quality PPS timing from an external atomic clock, I've never had a
Cs or Rb source, so I won't claim to have measured sub-microsecond accuracy 
with it.

 He also ran a particular install of BSD and a non-standard NTP.

I believe he ran FreeBSD 4.x and likely the ntpd from ports.

Regards,
-- 
-Chuck

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

Re: [ntp:questions] Red Hat vote for chrony

On Dec 5, 2014, at 5:55 PM, Paul tik-...@bodosom.net wrote:
[ ... ]
 Even back in 2002 with very inexpensive commodity hardware, FreeBSD was
 able to achieve accuracy measured to ~260 nanoseconds:
 
 H.  So phk uses a $1,500 rubidium standard as a system oscillator and
 you call it inexpensive and commodity.

No, he used a $1500 rubidium clock to accurately measure the timekeeping
quality of a $220 Soekris computer, and concluded:

I have earlier complained that no good and cheap hardware were available which 
could timestamp a PPS signal reliably and precisely but now the Soekris 
computer has proven that it does indeed deliver just that: With a pricetag of 
approx USD220 (single unit including enclosure) this is the best hardware you 
can find for a stratum 1 NTP server.

If you wanted to drive such hardware via a ~$40 GPS puck, you'd probably
see an accuracy of around a microsecond, perhaps a bit worse depending
on the timekeeping accuracy which the GPS puck provides.  That was also
the level of accuracy I was seeing from generic Intel hardware running
FreeBSD as a stratum 1 with a GPS source.

I've used a digital frequency counter which had an onboard TCXO (or possibly
a DTCXO) for measuring.  Although the frequency counter supported receiving
higher-quality PPS timing from an external atomic clock, I've never had a
Cs or Rb source, so I won't claim to have measured sub-microsecond accuracy 
with it.

 He also ran a particular install of BSD and a non-standard NTP.

I believe he ran FreeBSD 4.x and likely the ntpd from ports.

Regards,
-- 
-Chuck

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

Re: [ntp:questions] Red Hat vote for chrony