Post by Miroslav LichvarPost by Richard CochranTherfore, the overall real time behavior of the system has a direct
effect on application time accuracy. The single microsecond time error
due to the PHC/SYS servo is insignificant when compared with the
overall system latencies.
I think I understand what you are saying here, but I'm still not
convinced there are no applications where only a minimal or average
latency would matter.
I am trying to say that the system latencies (like ISR latency which
ranges from single to dozens of microseconds and depends on system
activity) will always introduce an error. You can filter, estimate,
and finagle all you want, but without an independent method of
comparing the system clock (like HW pps), you can never really know
what you have achieved, since the way that you read the clock
re-introduces the same errors that you supposedly filtered out.
Also, it does no good to say, "on average, under idle load, the time
error is so and so." You are only fooling yourself or your customers
with such claims. Instead, you need to specify the worst case
error. The worst case *will* appear in normal usage.
For example, consider time stamping a series of "interesting events"
that occur at irregular intervals.
Q: What is the error in the time stamps?
A: Several milliseconds.
You can't tell which of the time stamps have the average error, and
which have the large error, so you must assume the larger error.
A similar argument applies when talking about application timers.
One of the main points of the paper was that the pps method provides
time that is "good enough" for most application. Other applications
with special needs can simply use clock_gettime on the PHC device.
Post by Miroslav LichvarAt least, it should be useful for the kernel itself. For example, it
would allow us to make a high quality PPS master synced to UTC or
measure the latency of the serial port I'm using for the GPS PPS and
compensate for it.
With a lot effort, you can characterize the PPS jitter on your
particular serial port, with your particular motherboard, and your
particular kernel version, etc. That is all well and good, but it
requires some expert knowledge. It doesn't help us to offer a general
purpose solution.
I appreciate what you are doing with the phc2sys program, and I
welcome any improvements. Still, I am bit sceptical about achieving
better results than a few microsecond time error for the system clock.
Post by Miroslav LichvarIn case you are interested in how it compares to some other
algorithms, here are results of simulations with the NTP
implementations ntpd and chrony using a SHM reference clock with poll
set to 8 seconds (the SHM is read every second) and the phc2sys
program reading a PHC once per second in two settings of the PI
constants. The SHM and PHC jitter was set to 1 microsecond with normal
distribution and the clock wander changed from 0.01 ppb/s to 100
ppb/s. The error in time and frequency of the system clock was
monitored.
http://mlichvar.fedorapeople.org/tmp/phc2sys_offset.png
http://mlichvar.fedorapeople.org/tmp/phc2sys_freq.png
Those are interesting looking curves. Can you explain what they show?
What is the SHM ref clock? Is it the NTP driver?
What is the X axis?
How did you measure the RMS error?
How do you set the jitter?
How do you change the wander?
I really don't get it :(
Post by Miroslav LichvarPost by Richard CochranThe advantage would be to use the kernel's NTP servo. People do trust
it, even if no one really understands it.
Some don't trust it. The kernel discipline is using 4x shorter PLL
time constant than the reference implementation, against the advice of
Dr. Mills. I think the problem is that it was designed many years ago,
when typical network jitters were orders of magnitude larger, while
Yep. Although wireless and power modem networks are still pretty bad.
The machines are lot faster, too. This makes a difference for the pps
measurements.
Post by Miroslav Lichvarthe clock stability hasn't changed much or could be even worse due to
more power hungry devices inside current computers. The Allan
intercept is much shorter than it was before.
Thanks,
Richard
