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 i
curacy affected by
jitter/wander, poll interval and the PLL gain.
http://mlichvar.fedorapeople.org/clknetsim/
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
n 5
times for 10 microseconds.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
l be orders of magnitude
worse than continuosly running ntpd (even with poll 15 or 16).
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
eep the noise down and to get 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.nt
scanning the peer hash 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
disabling all
unneeded NMEA sentences?
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
With the latest versions, clock hopping may not be so much of
> a problem. Bu tit is still an issue. Even if you 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
ge, so the
intersection interval will be equal to C and all three 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
intervals
overlap. Otherwise they both will be falsetickers.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
On Tue, Jan 04, 2011 at 04:12:06PM -0500, Brian Utterback wrote:
> On 01/04/11 13:44, Miroslav Lichvar wrote:
> > It says and explains that minimum number of servers to detect one
> > falseticker is four, is that really correct? I understand that four is
> > better for reli
r the configuration with only
one server by users who would rather have two sources marked as
falsetickers and know a problem needs to be fixed than unknowingly
follow a bad truechimer.
Is it possible to reword that section?
Thanks,
--
Miroslav Li
t automatically and not
lose accuracy. Please be careful to not abuse public servers with too
short interval.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
al
> offsets is dead in the water.
Which kernels? I'm pretty sure it's not the case with Linux.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
fact slewed the clock, adapting to differing
> adjtime() implementations.
Or clamp the adjustment to 500 microseconds so there is no leftover.
Or disable the fast phase correction when started without drift file.
Ditching a very useful feature just because Solaris slews faster than
500 ppm see
00e-6)
adjustment = -500e-6 - drift_comp;
clock_offset -= adjustment;
adj_systime(adjustment + drift_comp);
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
hitting here.
If 500 ppm is the standard rate, Linux is working fine and
the other systems are the bad ones.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
On Wed, Nov 03, 2010 at 04:06:39PM +, Dave Hart wrote:
> On Wed, Nov 3, 2010 at 09:24 UTC, Miroslav Lichvar
> wrote:
> > On Tue, Nov 02, 2010 at 10:03:30PM +, David L. Mills wrote:
> >> I ran the same test here on four different machines with the
> >> ex
t +
drift_clock doesn't go over 500 microseconds fixed the problem for me.
The error in frequency estimation is now below 2 ppm.
I have also rerun the original test with drift file and ntpd now
reaches the 200us sync in less than 2000 seconds with al
2 14:37:55 localhost ntpd[8526]: 10.34.32.125 80a4 84 reachable
Nov 2 14:49:16 localhost ntpd[8526]: 10.34.32.125 96ba 8a sys_peer
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
to 8 or less? Similarly to the daemon loop, but
only with one step.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
.096238729 -136.437 0.016847350 1.730365 6
51544 8809.102 0.117385634 -135.990 0.017442850 1.626332 6
51544 9400.248 0.0 -135.990 0.00119 1.521295 6
Here is a plot of real frequency offset, not sure if this will be any
help:
http://mlichvar.fedorapeople.org/tmp/ntp_start4
01:28 ntpd[3635]: 192.168.123.2 966a 8a sys_peer
1 Jan 10:13:37 ntpd[3635]: 192.168.123.2 8673 83 unreachable
1 Jan 10:20:08 ntpd[3635]: 192.168.123.3 961a 8a sys_peer
Any explanation for this? I've tried versions 4.2.2, 4.2.4, 4.2.6 and
the latest dev, the result is always the same.
T
the STA_FLL flag? I
think it would be nice if ntpd switched the FLL limit to 256 s with
tinker allan 8 or lower.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
1 Jan 02:06:53 ntpd.new2[3135]: 0.0.0.0 c618 08 no_sys_peer
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
equency calibration doesn't work correctly here.
Please let me know if you need more information.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
he
initial offset is over 0.05 second, the overshoot can easily reach 100
percent, is this expected?
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
u are not planning to run without PPS or would rather use an NTP
source as a backup, remove the 127.127.28.0 line and use gpsd just for
the PPS source.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
ork properties, you could simulate
whole network in clknetsim (http://mlichvar.fedorapeople.org/clknetsim/).
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
all gps info out below as i only want to know what to do with
> ntp
> now.
Any interesting ntpd messages in syslog?
One additional thing you could try is to disable the kernel discline
by adding "disable kernel" to ntp.conf. If this helps, it's a kernel
bug or possibly a
t rate to be sure
it's replying to all queries.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
7.062213 cycles
A single-core Athlon 64:
2000.448523 MHz, rdtsc: 3.351000 nanoseconds, 6.703503 cycles
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
he raw data from peerstats and
measurements files have to be processed instead.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
get_systime(&tr);
+ tr.l_i -= first.l_i;
LFPTOD(&tr, gtod[i]);
}
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
pd prints here (patched to use smaller MINSTEP):
ntpd[9357]: proto: precision = 0.086 usec
I've seen values as low as 40 ns. The system has to use TSC as
clocksource though.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
h
sting to repeat the experiment with trace 3 and
> NTP operating at a poll interval of 16 s..
To trace 3 seems to correspond 0.4us exponential phase noise and
0.4ppb/s random-walk frequency noise. In such setting and 16s polling
interval chrony is about 15 times better than ntpd.
--
Mir
t machines I have found have
> a precision of about 500 ns. Note, precision is the time taken to
> read the kernel clock and is not the resolution.
With current CPUs the precision is well below 100 ns. (thus the
MINSTEP constant used in ntpd's precision routine is too high)
--
er of tens of percent, but it's still better.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
a
stronger frequency noise is good enough to get similar results as with
real data.
What I'm hoping to get from the survey is a range for random-walk
frequency noise which will give results similar to real oscillators
and which I should focus on i
On Fri, Sep 10, 2010 at 03:11:14PM +0200, Udo van den Heuvel wrote:
> On 2010-09-10 15:04, Miroslav Lichvar wrote:
> > If you have a PPS device and would be willing to run the machine
> > unsynchronized for a day, I'd like to ask you to measure the Allan
> > d
an -p adev.plot /sys/devices/virtual/pps/pps0/assert
(change the sys file as appropriate)
3. let it collect the PPS samples for at least one day
4. hit q and send me the adev.plot file
Thanks,
--
Miroslav Lichvar
___
questions mailing list
question
ixed in?
With 2.6.35, I still see frequency changes in order of tens of ppm
between reboots. Maybe it's hardware specific.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
ch even with the minimum poll 3.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
On Tue, Aug 03, 2010 at 09:14:34PM +0100, David Woolley wrote:
> Miroslav Lichvar wrote:
> >The most important thing is to set minpoll and maxpoll for the server
> >specified in ntp.conf. Generally, lower is better unless the network
> >load to the NTP server is a concer
4.
For example:
server 172.17.255.254 iburst minpoll 4 maxpoll 4
disable kernel
tinker allan 16
The allan parameter specifies at what update interval will be FLL
used, set it to the polling interval to ensure it's always enabled.
With ntp-4.2.4 it's specified in seconds, with 4.2.6 it
d with NTP_MINPOLL 1 and here is a PLL response plot
for SHIFT_PLL 4 poll 1 and SHIFT_PLL 2 poll 3:
http://fedorapeople.org/~mlichvar/clknetsim/test6.png
The initial offset is 0.1 second, after crossing zero offset, they
both stay in negative.
--
Miroslav Lichvar
_
http://fedorapeople.org/~mlichvar/clknetsim/test1_exp.png
With poll 6 and 10ppb/s wander, the crossover is around 10ms jitter.
With larger jitters SHIFT_PLL 2 can be up to 2 times worse (it seems
this can't be improved by lowering the poll interval) and with very
small jitters it can be a
On Wed, Jun 30, 2010 at 09:43:26PM +0100, David Woolley wrote:
> Miroslav Lichvar wrote:
>
> >and is using the LOCAL driver, the rest have clocks with 1ppb/s
> >wander. Between all nodes is network delay with exponential
> >distribution and a constant jitter. The simul
experiment with all strata using SHIFT_PLL 4:
http://fedorapeople.org/~mlichvar/clknetsim/test5_ntp.png
You probably know what to expect here, but I was surprised to see that
with high jitter the SHIFT_PLL 4 strata are actually better than their
SHIFT_PLL 2 sou
mportant for NASA/JPL users when
> converting to and from UTC and TAI and eventually to TDB for deep
> space missions.
The offset is available in the adjtimex structure, so with some
patching it should work on Linux too.
--
Miroslav Lichvar
___
ques
tion runs slower.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
cks like getting time with the
rdtsc instruction instead of making a system call.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
27;t remember ever seeing it and the ntpd daemon mode works
fine as far as I can tell.
> 3. The calling sequence for the ntp_gettime() system call is
> incompatible with current use. As a result, access to the TAI-UTC
> offset by application programs is not available.
This probably won&#
gured with Lisp-style expressions, there are
several random number generators and waveforms available. It's also
possible to use a file with pregenerated or measured values as a
source.
>From NTP applications, currently supported are Linux ntpd and chronyd.
--
Mir
s not. In clock_filter() there are several places where it
can return without calling clock_select().
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
ase version, that
> might explain your results.
I can reproduce it with 4.2.6p1 and 4.2.7p32, I haven't tried
anything else.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
When the source stops responding, the first few MAXDISPERSE samples
pushed from the transmit() timeout won't pass the epoch check in
clock_filter(), then the function will abort on the condition which
checks if there are any acceptable samples.
nd reachable.
The tally indicator sometimes stays at * even when the peer is
unreachable, that's why I have filed the bug 1554. There are steps to
reproduce and a description of the events in clock filter which are
causing the problem.
--
se something else for monitoring, probably track the reachable status
for each peer, or is there something better?
Thanks,
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
t; I am struggling for evidence at the moment.
I couldn't find a description either, but it seems to work as expected.
PPS is turned off when the sync is lost and turned on when a fix is
back. It works only when the fix status is changed, i.e. the command
itself doesn't change the PPS s
output if
>>>the receiver loses lock.
>>
>> But lots of low-cost GPS receivers don't do that.
>
> .. including the popular GPS18 LVC. So it's better to have a driver which
> reads the serial output of the GPS to confirm lock.
GPS18(x) LVC supports a PPS auto off m
rg/show_bug.cgi?id=1554
It seems to happen when the reachability register wasn't full (or above
a certain limit) when the source stopped providing samples. The source
will stay marked as system peer and ntpd will continue to serve time
even if it's actually not sychroniz
uot;XFAC" ??
>
> inquisitive minds want to know ;-)
There is a comment before that hunk:
/*
* clear crypto if we change the local address
*/
So it would seem the string is used when the network interface which is
used to send packets to the peer has changed its address and the crypto
can do something about it. With only
one source you never know.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
On Thu, Apr 15, 2010 at 03:44:21PM +, unruh wrote:
> On 2010-04-15, Miroslav Lichvar wrote:
> > Userspace timestamps may decrease the accuracy by more than just 0.5
> > us. When I compare kernel timestamps and timestamps from gpsd, there
> > is a 20-40us difference, even
.
Of course, for 1ms requirement this doesn't matter.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
n able to successfully peer between chrony and ntpd
> though, but I don't really have spare hardware at moment to
> really test this out.
As chrony supports only version 3 of the NTP protocol, you might need
to add "version 3" to the chrony peer speci
om gpsd:
http://fedorapeople.org/~mlichvar/chrony/chrony_vs_ntp.png
With recent chrony, NTP and kernel versions the results might be
different though.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
ut it sure is terrible.
On a lightly loaded Gb LAN I'm seeing 2-15us jitter, so I think it's
rather a vendor/model problem than a flaw in Gb ethernet itself.
Disabling interrupt coalescing (ethtool -C on Linux) may help.
--
Miroslav Lichvar
On Tue, Sep 08, 2009 at 10:40:05AM -0700, Dave Hart wrote:
> On Tue, Sep 8, 2009 at 12:40 PM, Miroslav Lichvar wrote:
> > BTW, on current hardware the precision seems to be below the 100ns
> > MINSTEP limit as used in the default_get_precision routine. If the ntp
> > process w
t run forever.
Also, the calculation doesn't work correctly if the precision is below
resolution. The result is just a random value close to 100 ns. Maybe
get_systime should be called multiple times before calculating the
difference.
--
Miroslav Lichvar
in device died 3/13/09
>
> New replacement installed 3/27/09
>
> Second unit died this afternoon. Bummer. Guess I will have to keep one
> spare on hand.
I have a 18x LVC running here continuously for about 12 months.
Maybe your power supply if faulty?
--
Miroslav Lichvar
___
implemented and configured in kernel and that is hard
to find out in runtime.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
ng systems where temperature varies a lot, it
might help if NTP allowed to adjust the PLL time constant. I've
proposed a simple patch that adds a new "tinker shifttc" command here:
http://bugs.ntp.org/1202
The only other option (beside using a shorter poll interva
On Fri, Jun 26, 2009 at 11:34:11AM +, Ronan Flood wrote:
> The question remains why the Brandywine PTS device is claiming synch
> to LOCAL(O) with stratum 2.
Maybe the NTP implementation is just replying with the client's refid,
which is INIT first and then LOCAL(0).
--
Miros
ork.
I've seen a similar report. IIRC it was caused by server using refid INIT
in the replies which is interpreted in the client as a synchronization
loop. Check tcpdump output.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
43 us
Distribution plot:
http://fedorapeople.org/~mlichvar/chrony/chrony_vs_ntp.png
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
failing to understand here? The poll values reported in
> ntpq -p are 64, 64 and 1024 - as expected.
That's clock filter skipping samples, it may skip up to 7 consecutive
samples based on their dispersion. All samples are recorded in
peerstats.
--
Miroslav Lichvar
___
second patch implements a queue timer, it is more complex and
harder to maintain. In the Fedora CVS is maintained the first patch,
a version for the latest stable ntp release can also be found there.
--
Miroslav Lichvar
___
questions mailing list
quest
27;ve recently seen a similar problem on a PowerPC
machine where adjtime() called with delta smaller than 1ms was
ignored.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
201 - 280 of 280 matches
Mail list logo
