RE: [chrony-users] Chrony offset and stability adjustments? (fwd)

[Bill Unruh <unruh@xxxxxxxxxxxxxx>]

Not clear what you mean by by hardware based ntp appliances that will service
all clients. What I interpret this as is that you have some external say GPS
driven clock which each client uses ntp ith as its server but the clients are
still VM based operatimg systems. The problem is that vm based operating
systems cannot reliably carry time through the times between their getting the
real time from the server. thus the time they get from the server might be
great, but the client has no was of knowing how much time passedbetweent the
last time they querried the server and now . chrony and ntp assume that the
local clock is reasonable in that it counts some internal process wich is
reasonably regular, it is just that its rate fluctuates. chrony estimates that
and corrects it. But a VM can simply forget to count that internal process for
huge swathes of time, randomly. Areader can still make sense of the book by an
abook by an attrocios speller, but if whole swathes of letters are simply
omitted randomly it gets really hard to read. Thus it is best if the
underlying OS which runs the VM does the timekeeping since it remains in
control of the hardware always The VM is then altered so that its gettime
routines always query the underlying oS directly, and not attempt to keep
their own time. However that means that the VM OS has to be altered in its
gettime routines. Snce many of the VM oS are proprietary, that is hard to do.


On Wed, 9 Jan 2019, LeBlanc, Daniel James wrote:

> Hi All.
>
> Thank you all for your comments - there appears to be a great deal of complexities associated with the use of virtualized hardware to provide accurate time.  We intend to use the VM-based approach only for the first weeks of a tech trial, after which we will be deploying hardware-based NTP appliances that will service all clients.
>
> Thanks!
>
> Daniel J. LeBlanc, P.Eng., MBA, DTME | Senior Network Architect | Bell Canada
>
>
>
> -----Original Message-----
> From: Miroslav Lichvar [mailto:mlichvar@xxxxxxxxxx]
> Sent: January-09-19 6:08 AM
> To: chrony-users@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [chrony-users] Chrony offset and stability adjustments? (fwd)
>
> On Wed, Jan 09, 2019 at 10:56:56AM +1300, Bryan Christianson wrote:
> > > On 8/01/2019, at 10:31 PM, Miroslav Lichvar <mlichvar@xxxxxxxxxx> wrote:
> > >
> > > In the estimate of the maximum error, it's important to include also
> > > half of the root delay, so in your examples it would be about 250
> > > microseconds.
> >
> > OK - still less than 1ms as required by the OP.
> > Maybe this maximum error estimate could also be shown in 'chronyc tracking'?
>
> Yeah, that would probably make sense. It's included in the tracking
> log.
>
> > > Raspberry PIs have ethernet on USB, which adds some latency, and IIRC
> > > the default interrupt coalescing is very large. You might want to try
> > > setting a smaller rx-usecs value with ethtool -C, which should reduce
> > > the root delay and give the clients a better estimate of the maximum
> > > error.
> >
> > I had a quick look at this, but the nic in the RPi doesn't seem to support the coalesce options of ethtool with Debian Stretch.
>
> You are right. From the current source code of the driver it doesn't
> look like there is any support for getting or setting the coalescing
> parameters. There is no support for SW timestamping either. I probably
> confused it with a different board. It may not even make sense to do
> on a USB NIC.
>
> I did a quick test with a RPi 3 I have here for non-NTP purposes and
> the peer delay to a good server connected to the same switch is around
> 160 microseconds, so the maximum error due to timestamping would be
> about 80 microseconds. Not an ideal HW for timekeeping, but certainly
> good enough for sub-millisecond accuracy.
>
> --
> Miroslav Lichvar
>
> --
> To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
> with "unsubscribe" in the subject.
> For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
> with "help" in the subject.
> Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.
>
>
> --
> To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
> with "unsubscribe" in the subject.
> For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
> with "help" in the subject.
> Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.

--
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx 
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx 
with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.