the overall time and frequency errors were quite close to
ntpd (running on Linux).
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
algorithm
will be equal to the interval of T1 and all three servers will pass as
truechimers. Adding a third good server may not be enough to change
the result.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org
On Thu, Nov 20, 2014 at 07:27:47AM +, David Taylor wrote:
On 19/11/2014 11:56, Miroslav Lichvar wrote:
Can you try 3.17 or later and see if it's fixed? Also, it would be
interesting to know if adding nohz=off to the kernel command line
instead of recompiling works as a workaround too.
I
use? The PPS discipline is always disabled
when the Linux kernel is compiled with NO_HZ, so I think that could
explain what you are seeing. I'm not sure if that would be an ntpd bug
or kernel bug, but I can look into it.
--
Miroslav Lichvar
___
questions
On Thu, Nov 20, 2014 at 12:02:06PM +0100, Miroslav Lichvar wrote:
On Thu, Nov 20, 2014 at 10:16:13AM +, David Taylor wrote:
Running the sleep 10 sequence from a command procedure gives a difference of
1055, so I guess that's 105.5 interrupts per second. Does sound like 100
Hz, yes
try 3.17 or later and see if it's fixed? Also, it would be
interesting to know if adding nohz=off to the kernel command line
instead of recompiling works as a workaround too.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http
to fix widely used open source (S)NTP implementations
to not poll frequently and I'm wondering if this is a client I know.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
(using the standard PLL time constant shift) the best
poll would be even shorter.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
with a fudge
command?
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
ntpd is
running, the kernel 11-minute update mode will time the RTC update to
few ticks, that's few milliseconds with a 1000Hz kernel.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
On Fri, Aug 01, 2014 at 12:59:32PM +0200, Martin Burnicki wrote:
Miroslav Lichvar wrote:
To generalize it a bit more, there could be also a case of a PPS that
is not locked in phase and a case of a PPS that's not even locked in
frequency. When only a source with poor short-term stability
refclock itself. If local stratum is enabled,
the PPS will work immediately without any other sources, but the clock
obviously needs to be already close to the correct time on start,
otherwise it will be off by a whole number of seconds.
--
Miroslav Lichvar
be allowed to send a reponse with purposely
bad time.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
On Tue, Jun 24, 2014 at 06:25:37PM +0200, Jochen Bern wrote:
On -10.01.-28163 20:59, Miroslav Lichvar wrote:
Agreed, but wouldn't switching to TAI everywhere be much more
difficult than stopping messing with UTC and keep it a fixed offset
from TAI?
Having computer clocks run on UTC
On Tue, Jun 24, 2014 at 06:13:17PM -0500, Mike S wrote:
On 6/24/2014 5:59 AM, Miroslav Lichvar wrote:
To me, it seems the reasonable thing to do would be to decouple UTC and
UT1 completely and make the adjustment at a higher level like
timezones if necessary.
You're doing it wrong. If you
.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
scheduling leap seconds so as to aim for min-sum-of-squares, rather than
predefined schedule slots.)
Good point. The question is if they will ever choose to do that.
Thanks,
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http
be much more
difficult than stopping messing with UTC and keep it a fixed offset
from TAI?
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
is
independent of the host clock), it will need to run its own NTP
client. If the guest's clock is locked to the host's system clock,
there still may be a static offset between them and an NTP client
(possibly using the host as the NTP server) can be used to correct the
offset.
--
Miroslav Lichvar
to add to chrony. Add a new selection option to bypass the selection
algorithm and just combine its frequency with other sources by
estimated skew. This could work with both NTP sources and reference
clocks.
--
Miroslav Lichvar
___
questions mailing list
is probably using gettimeofday() which has microsecond
resolution (-20 in the log scale) and not the nanosecond
clock_gettime().
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
are
running, but in xntp3-5.93e (dated 1998) it seems the system peer is
unselected (and the message logged) on every clock step.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
?
That sounds like a horrible hack.
Even without chroot it will be difficult. If the ntpd process dropped
root privileges after start, it won't be able to re-exec and it may
not have permissions to open newly added refclocks or reread the keys,
for instance.
--
Miroslav Lichvar
would
have to update their refid definition at the same time. That's not
doable. Fixing the tools to print the value in hex instead of dotted
quads to avoid confusion seems like a better fix to me.
--
Miroslav Lichvar
___
questions mailing list
questions
constitute this refid issue a bug.
One that is rather confusing and time-consuming.
For IPv6 addresses the refid is defined as first 4 bytes of the MD5
sum of the address. With 2001:7b8:3:32:213:136:0:252 (tt52.ripe.net)
that is 0xac023551, or 172.2.53.81 in the quad-dotted notation.
--
Miroslav
to update the clock has the shortest distance and may carry more
useful information than the other points combined if the clock is
stable enough.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
/show_bug.cgi?id=759
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
;
}
sys_offset = z / y;
So, if this is calculated immediately after a new selected-by-filter reading
comes in, x is infinity and only the latest one is used.
The synchronization distance includes also delay, dispersion and
precision, so it should never be zero and x should be real.
--
Miroslav Lichvar
by ntpdc) isn't blocked on ntp-dev, it has
been _removed_!
Wasn't it only disabled by default? It still seems to be in 4.2.7p411
in the ntp_request.c file, but enable mode7 is now required to
process the ntpdc queries.
--
Miroslav Lichvar
as expected.
ntpd -c /dev/null 0.pool.ntp.org
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
Vendors should be careful with the pool command.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
can't be easily ignored and it's necessary to have all
networking HW with PTP support to account for all processing delays.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
contribute to that are that 3.2.27 and
3.6.11 appear to be OK, at least on the Raspberry Pi (Debian).
The relevant commit seems to be
http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?id=08ec0c58fb8a05d3191d5cb6f5d6f81adb419798
It was included in 2.6.38.
--
Miroslav Lichvar
of telling the server it should never slew faster
than 300PPM. Is there one?
I think the kernel would have to be recompiled with a smaller
MAXFREQ_SCALED constant or ntpd recompiled with smaller NTP_MAXFREQ if
the kernel discipline is disabled.
--
Miroslav Lichvar
.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
! For my machine it shows that the interrupt
latency is around 12 us.
I'm wondering if the kernel module could have an option which would
enable a polling method to time stamp the PPS events.
--
Miroslav Lichvar
___
questions mailing list
questions
, but
still fast enough to send tens of thousands of packets per second.
I think it makes more sense to have one loop controlling just the PHC
and another, much tighter, syncing the system clock from the PHC,
rather than trying to sync the system clock through the PHC.
--
Miroslav Lichvar
on Ethernet.
The phc2sys program from the linuxptp project can be used to
synchronize the system clock to the PHC or the PHC to the system
clock. It can do that via PPS or filtered clock readings.
--
Miroslav Lichvar
___
questions mailing list
driver like NMEA?
If you don't need the pps from /dev/ttyACM0, my suggestion would be to
prevent loading of the pps_ldisc module, so there is always only one
pps device. Any chance you added a udev rule to load pps_ldisc
automatically when the serial device is created?
--
Miroslav Lichvar
is created two minutes later (some USB
device?).
Do you see two /dev/pps* devices and are you sure ntpd is using the
gpio one? Perhaps there is an ordering problem?
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org
it better to start it from udev then? The gpsd sources provide a
hotplug script, which I think is included at least in the Debian and Fedora
gpsd packages.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org
. Are those numbers nanoseconds?
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
rate
ntpd can handle. IIRC, the ntpd process itself needed only a couple of
percent of the CPU, I think the bottleneck is always in the kernel or
the NIC.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo
Netherlands
85.17.71.101 Netherlands
85.252.162.7 Norway
86.61.66.23 Slovenia
90.155.74.40 United Kingdom
91.198.87.118Netherlands
94.26.2.134 Bulgaria
95.211.7.153 Netherlands
98.191.213.7 United States
--
Miroslav Lichvar
On Fri, Mar 23, 2012 at 06:12:11PM +0100, Terje Mathisen wrote:
Miroslav Lichvar wrote:
On Fri, Mar 23, 2012 at 11:49:19AM +0100, Terje Mathisen wrote:
But I think a much bigger problem with the clock filter and PLL
combination is that it can't drop more than 7 samples. When the
network
just from the
last two samples? With PLL or similar, increasing the time constant
accordingly might be a better approach.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
unusual.
This sounds familiar. Perhaps the OP is hitting the bug 2156 fixed
recently? If the emulated adjtime on Windows doesn't apply the 500 ppm
limit, it could have explained the huge frequency error.
--
Miroslav Lichvar
___
questions mailing list
is the ntpd log (in UTC+2
timezone):
http://pastebin.com/ZRi6qv8E
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
On Thu, Mar 08, 2012 at 02:28:07PM +0100, Miroslav Lichvar wrote:
In a clknetsim simulation with ntp-4.2.6p5 I can see the clock is
correctly stepped by 1.0 second. Here is the ntpd log (in UTC+2
timezone):
http://pastebin.com/ZRi6qv8E
In another simulation set to start 15 seconds before
in the right/UTC timezone and I think that would
be a nice feature. To check if a leap second will occur on a specified
date, it just needs to call mktime() in the right/UTC zone and see if
the seconds overflowed or not, see
http://pastebin.com/DqM4s35Y
--
Miroslav Lichvar
On Thu, Jan 05, 2012 at 11:40:25AM +0800, Dennis Ferguson wrote:
On 4 Jan, 2012, at 22:54 , Miroslav Lichvar wrote:
The simulations were done with a clock wandering at 1 ppb/s,
10/100/1000us network jitter with exponential distribution and the NTP
clients were configured to use 64s polling
as visclocks.py. It also has
a game mode, where you control the frequency and phase of the clock by
mouse and you can try to beat the other clients. :)
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
Why not degrade the resolution of the clock directly in ntp sources?
In get_systime():
GET_SYSTIME_AS_TIMESPEC(ts);
ts.tv_nsec /= 100;
ts.tv_nsec *= 100;
--
Miroslav Lichvar
___
questions mailing list
questions
and the adjustment is in
100-ns units applied over an lpTimeIncrement interval. If the interval
is too short I suspect this could also limit the time and frequency
accuracy of the system clock.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
and
later have kernel, ntp and chrony packages compiled with PPS support
and it should work out of the box, even with SELinux enabled :).
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
to to ~10 microseconds, the recent suggestion posted here to
never use Windows for serious timekeeping might need to be revisited.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
On Thu, Dec 01, 2011 at 12:24:44AM +, Pete Ashdown wrote:
Miroslav Lichvar mlich...@redhat.com writes:
Would be interesting to know if this happens on every ntpd restart or
only shortly after the GPS unit was powered up.
Every restart (that doesn't have 127.127.0.1 in the config
On Wed, Nov 30, 2011 at 11:28:22PM +, unruh wrote:
On 2011-11-30, Miroslav Lichvar mlich...@redhat.com wrote:
On Wed, Nov 30, 2011 at 10:24:45PM +, unruh wrote:
If he has peerstats log file, he can look at it and see what teh offset
is of the oncore and the other ntp sources to see
you'll need to make sure the
kernel RTC synchronization (11 minute mode) is not enabled as it would
throw off the RTC drift estimation. See hwclock(8) for more
information.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http
with the same sing, the actual
error is probably closer to the reported offset.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
On Mon, Sep 05, 2011 at 04:47:20PM +, unruh wrote:
On 2011-09-05, Miroslav Lichvar mlich...@redhat.com wrote:
It's from gpsd which seems to make the NMEA receive timestamp after
the message is processed.
Never did understand that. Timestamping the beginning of the sentences
is cheap
(firmware 3.70) I see errors up to 150 ms. That
wouldn't be that bad if it was randomly distributed.
A capture over 30 hours:
http://mlichvar.fedorapeople.org/tmp/18x_nmea.png
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http
On Mon, Sep 05, 2011 at 03:04:54PM +, unruh wrote:
On 2011-09-05, Miroslav Lichvar mlich...@redhat.com wrote:
With 18x LVC (firmware 3.70) I see errors up to 150 ms. That
wouldn't be that bad if it was randomly distributed.
A capture over 30 hours:
http://mlichvar.fedorapeople.org
are very good numbers for such high polling interval. Is the
crystal oscillator thermally stabilized?
In any case I'd suggest to use a shorter maximum poll interval. The
default maxpoll is way too high for jitters normally seen on LANs if
you want best accuracy.
--
Miroslav Lichvar
)
11255 1 ntpd CALL ioctl(7,PPS_IOC_KCBIND,0xefffdf8c)
A shot in the dark, have you tried removing flag3 1 to disable the
kernel PPS discipline?
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo
to remove the flag3
setting.
Also, how is marked the PPS source in ntpq -p output?
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
It seems the GPS driver is not getting or is ignoring the PPS signal.
I think there were some issues fixed recently in it. I'd try the ATOM
driver (22) first to verify ntpd was compiled with PPS support and is
able to use it.
--
Miroslav Lichvar
the timepps.h header, try this one
https://raw.github.com/ago/pps-tools/HEAD/timepps.h
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
is between the two. With -g the first clock update
is allowed, but the clock is not stepped so the following updates will
still be be over the panic limit and ntpd will abort.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http
, it makes things worse with normal
delays as the offset will contain network jitter.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
, the RMS time
error is about 40 us for the standard PLL and 80 us for the Linux PLL.
The 99th percentiles are about 100 us and 200 us respectively.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
the unit was upgraded.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
have a better chance that the best server is
significantly better than the others though.
The problem can be usually fixed by increasing the anti-clockhopping
distance by tos mindist, perhaps to 10 ms.
--
Miroslav Lichvar
___
questions mailing list
, as it would with the kernel loop.
Fortunately, you can improve that significantly by enabling the FLL
part of the loop by setting a shorter Allan intercept, in 4.2.6 it's
11 by default (set in log2(s)), i.e. FLL is active with poll 11 and
above.
For example:
tinker allan 7
HTH,
--
Miroslav
, I can't at this point
suggest when it was fixed or which change fixed it.
I think it's the bug #1554, which was fixed only in 4.2.7.
https://bugs.ntp.org/show_bug.cgi?id=1554
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http
,
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
On Wed, May 11, 2011 at 12:55:15PM +0200, Miroslav Lichvar wrote:
On Fri, May 06, 2011 at 12:44:42PM +0800, Dennis Ferguson wrote:
level, it will typically end up making an adjustment roughly every
10 seconds or so with the time adjustments tending to be about 10
nanoseconds in size
increasing the root dispersion
instead. When the distance reacheas a certain limit, the clients will
switch to another source.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
, only the distance check, is that correct?
Thanks,
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
to get the MV scheme working though. I have read the
official ntp-keygen page and the wiki document.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
by default)
he can fairly quickly throw your clock off and let you drift away.
In addition to the authentication, it's important to monitor
reachability of the peers.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http
=47730,
tc=4,
mintc=3, offset=-0.013, frequency=22.454, sys_jitter=0.011,
clk_jitter=0.016, clk_wander=0.028
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
be very good, but
at least the clock won't be stepped.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
window and traffic
shaping configured properly.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
://pkgs.fedoraproject.org/gitweb/?p=ntp.git;a=tree
the other ntpstat-* patches might be useful too.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
to be a design decision to use similar polling interval for all
sources, even when they have very different jitter.
As others have said, a workaround is to set minpoll to 10 for the NTP
sources.
--
Miroslav Lichvar
___
questions mailing list
questions
or not.
awk '{ n++; r += $3 * l 0; l = $3 } END { print r / n }'
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
and the PLL gain.
http://mlichvar.fedorapeople.org/clknetsim/
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
On Tue, Jan 18, 2011 at 12:49:52PM +, David Woolley wrote:
Miroslav Lichvar wrote:
The trouble is with when locked. When the jitter reaches a certain
point (or better the ratio between jitter and clock stability --
usually expressed as Allan intercept in the NTP docs), the PLL won't
On Tue, Jan 18, 2011 at 02:11:12PM +, David Woolley wrote:
Miroslav Lichvar wrote:
Yes, when the jitter is too low or the clock too unstable. Ideally,
ntp would run a statistic and adjust it in runtime. Chrony counts
It does. I forget the exact metric, but look for the term poll adjust
of network delays too. With
normally distributed delays I see improvement about 3, but with
exponentially distributed delays it's slightly more than 10. Is that
because the selected sample is the one with the best delay, so it
carries more information than the others?
--
Miroslav Lichvar
table, etc). I'd say that
starting ntpd two times per day will take much less resources than
running it continuosly.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
the current
thinkness.
I think the longer poll time is telling you something good about the
internal clock in the BSD system.
What exactly?
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
(even with poll 15 or 16).
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
14 milliseconds of CPU, including system time.
Note that CPU power consumption depends on which sleep state it's in
and it usually takes a lot of time to switch to/from deeper states, so
it's more energy efficient to load CPU once for 0.5 seconds than 5
times for 10 microseconds.
--
Miroslav
?
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
sources will
pass. Older versions worked also with centers of the intervals and as
the centers of A and B are lying outside the intersection interval, C
would be the only truechimer.
I'd be curious to hear why that approach was dropped.
--
Miroslav Lichvar
prefer one clock, it
might be inaccessible for a while and you will hop anyway.
Yes, the maximum anti-clockhopping threshold is a fixed value (1 ms by
default), so it can't work well in all situations. But it can be tuned
with the tos mindist command.
--
Miroslav Lichvar
101 - 200 of 257 matches
Mail list logo
