rror and jitter significantly.
http://blog.dan.drown.org/beaglebone-black-timer-capture-driver/
It looks like this could be a really nice and cheap NTP/PTP server.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
xed number of points
and to some extent imitate ntpd. In my testing, when the number was
set to 40 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
ault minpoll is 6 and maxpoll 10, exactly the same as in ntpd.
> That the faq as an example uses 2 and 4 is I agree stupid. It is faq. I
> have no idea who wrote it.
I wrote it. What exactly is wrong with poll 4 on a LAN?
--
Miroslav Lichvar
___
s the real time?
The intersection interval determined in the source selection 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
__
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 s
ipline enabled in your ntpd config (flag3)
and which driver do you 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
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 recompi
zero though.
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.
--
Miroslav Lichvar
___
questions mailing list
questi
file or tcpdump output you could
share?
I've been trying 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
2.7e-08
6 1.3e-05 1.7e-08
On other systems (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
console. On exit it will save the x, y coordinates of the plot to the
file specified by -p and the plotallan script can be used to create a
nice graph with gnuplot.
--
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 s
octl call when setting the clock
and enabling the interrupt when reading the clock. When 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
7.22.2 ref sys_peer
>
> # a PPS source which should be trusted always
> server 127.127.22.3 trust always
This looks good, but shouldn't it be rather specified with a fudge
command?
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
t used, the pulses will be accepted only when the
clock is synchronized, first to another refclock or NTP server and
then possibly the PPS 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 t
e if it's possible to make it so
reliable that ntpd could 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: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.
>
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?
>
&g
fingers, does it.
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?
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
ality of prediction *would* already suffice to attempt
> 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
__
at the end of the months of December or June, depending on the
evolution of UT1-TAI."
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
the NTP server) can be used to correct the
offset.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
think support for frequency only sources wouldn't be very difficult
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 Lic
Am I misunderstanding something
> perhaps?
The older ntpd 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
the version you 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
econds! I'd suggest to
fix that first.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
ad on a program that is already larger and
> more complicated than many folks want?
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 ope
of the refid value is detection
of synchronization loops. To not break that, all NTP servers 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.
--
the quad-dotted notation.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
nts.
Please note that the data points are not equal. The point which is
used 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
_
ocol it would have to track the connections. For
a stateless operation a new NTP extension field would probably be needed.
Similarly to PTP, all NTP-aware routers and switches between NTP
server and client would increment a path delay correction.
--
Miroslav Lichvar
error code (for
> example: situations like server not reachable)
There is a bug filed for that:
https://bugs.ntp.org/show_bug.cgi?id=759
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
x * peers[i].peer->offset;
> > }
> > 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
27;t know why.
>
> Type 7 (which is used 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 requi
oved later in 4.2.7. The page about recommended configuration
doesn't mention it yet.
http://www.pool.ntp.org/en/use.html
Vendors should be careful with the pool command.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
ing
command seems to work 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
he delay is measured
independently (similarly to the NTP broadcast mode), so bad
measurements 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
91d5cb6f5d6f81adb419798
It was included in 2.6.38.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
as options to set
the local port and the remote port. If the local port is set to 0, the
port will be assigned randomly, effectively making it a client-only
mode (similar to ntpdate -u).
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
now of any way 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.
a different number of samples
in the filter.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
interesting, thanks! 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 maili
me.
ntpd can read the clock, much more slowly than the system clock, 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 s
ll much better than the delays
causing the error in the TX timestamp 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
__
you added a udev rule to load pps_ldisc
automatically when the serial device is created?
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
you have two pps devices, one for gpio
and the other for ldisc which 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
_
at the same time.
Isn't 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.or
9360 -1067
>
> 92650 -318
> 90634 -910
> 89455 -989
> 89511 -1080
> 88874 -693
> 88534 -1140
Cool. Are those numbers nanoseconds?
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
lay to measure the maximum packet 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.nt
Netherlands
83.98.201.134Netherlands
85.158.249.144 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
9
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 mor
ackets/second and then keeping a single packet at the end.
That seems excessive. Do they set the frequency directly 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
I didn't find anything 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
__
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 s
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
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
ones on system running
synchronized via NTP. But ntp/chrony could use the information about
leap seconds stored 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 a
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
it 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
ce/clocksource0/available_clocksource
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 *= 1000000;
--
Miroslav Lichvar
___
questions mai
etSystemTimeAdjustment function 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
_
They are milliseconds. If ntpd on Windows can really keep the clock
stable 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
sier to try a newer distro. For instance, Fedora 14 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@lis
On Thu, Dec 01, 2011 at 12:24:44AM +, Pete Ashdown wrote:
> Miroslav Lichvar 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.
On Wed, Nov 30, 2011 at 11:28:22PM +, unruh wrote:
> On 2011-11-30, Miroslav Lichvar 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
ens on every ntpd restart or
only shortly after the GPS unit was powered up.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
-adjust option with ntpd 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
ques
cy changes well. If you see in
the loopstats log long runs of offsets 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
invert it accurately, you need
to divide it by 1.000180 instead of multiply by 0.999820.
--
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 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 se
On Mon, Sep 05, 2011 at 03:04:54PM +, unruh wrote:
> On 2011-09-05, Miroslav Lichvar 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:
> >
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/tmp/18x_nmea.png
--
Miroslav Lichvar
___
questions mailing list
questions
0.179 -0.066
> 0.083
> *10.0.2.9.GPS.1 u 391 1024 3770.166 -0.084
> 0.051
Those 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
defaul
CALL ioctl(7,PPS_IOC_SETPARAMS,0x1052d204)
> 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
___
questi
ink you just need 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
00.0000.000 0.002
> *GPS_NMEA(0) .GPS.0 l7 16 3770.000 20.012 26.423
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 (
d later, so maybe it would help 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
: uart:16550A port:03F8 irq:4 tx:1422 rx:184849390 fe:4891 pe:31 RTS|DTR|CD
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
to always step on start.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
that while the huffpuff option works very well with large
temporary asymmetric delays, 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
io is when tinker step is larger than panic and
the initial offset 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
_
the PLL time constant, 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://
nit from 3.20 to 3.70 and it seems
the jitter has indeed improved, see:
http://i.imgur.com/6NFBA.png
The middle part is when the unit was upgraded.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
lgorithm:
I think the frequent source switching can happen with any number of
sources if the two best servers have similar synchronization distance.
With more servers you may have a better chance that the best server is
significantly better than the others thoug
or example:
tinker allan 7
HTH,
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
disp=9.456, refid=PPSE,
That has changed with ntp version 4, it doesn't increase stratum and
change leap to unsync, it will keep increasing the root dispersion
instead. When the distance reacheas a certain limit, the clients will
switch to another source.
--
Miroslav Lichvar
___
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
> >
and keep maximum number of samples which pass the test. For best
performance, I think it should correspond to the Allan intercept.
Thanks,
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
haven't searched for one either. Similarly while I
> believe it to be fixed in more recent versions, 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
--
#x27;t have
the reftime > xmt check, only the distance check, is that correct?
Thanks,
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
a private
key, etc.
I wasn't able 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
when undersampled and
by dropping and delaying the packets (up to maxdist, 1.5s 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
dab.0ab5b995 Wed, Mar 9 2011 6:06:19.041,
clock=d121ddab.5dd3a440 Wed, Mar 9 2011 6:06:19.366, peer=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
ny before
resorting to ntpdate, the timekeeping probably won't 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
de the
acceptable range and write a "your clock is broken" message to syslog?
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
etter results with a large window and traffic
shaping configured properly.
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
stat-0.2-sysvars.patch from here
http://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
p-dev. But it seems
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 mai
his command on your loopstats and we'll see if
the offset is random 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
o depend on the distribution 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
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 l
101 - 200 of 280 matches
Mail list logo
