Harlan Stenn wrote:
The SHM refclock now supports nanoseconds, as I recall.
And I'd be happy to look at these issues for ntp4-5.0 too. How about a
bug report that refers to a topic in the Dev web for discussion?
Done. See:
Request for a more versatile shared memory (SHM) refclock driver
Michael Tatarinov schrieb:
2013/8/20, Martin Burnicki martin.burni...@meinberg.de:
Thus programs like gpsd can now write the nanoseconds in addition to the
microseconds. If there's an old version of ntpd running then it just
evaluates the microseconds, but new versions (ntp-dev for now) check
Martin Burnicki writes:
Harlan Stenn wrote:
The SHM refclock now supports nanoseconds, as I recall.
And I'd be happy to look at these issues for ntp4-5.0 too. How about a
bug report that refers to a topic in the Dev web for discussion?
Done. See:
Request for a more versatile shared
Rob wrote:
Aha, ok... that is a solution, but I think it is a good idea to draw
a new SHM specification that adds a lot of functionality like described
in the mailing list article, and make it the prime reference clock interface
for ntpd. ntpd can then focus on the main task: the network
Several people on the mail list have suggested that the nmea clock driver
estimate the accuracy of the time reading by the divergence of the indicated
location from the GPS device's true location. Right now the nmea driver
does not look at the lat/long readings.
You can find an accurate estimate
David Taylor wrote:
On 20/08/2013 13:25, Martin Burnicki wrote:
[]
There were 2 fields in the SHM segment which were previously unused and
are now used to take the nanoseconds from the refclock and from the
system time.
Thus programs like gpsd can now write the nanoseconds in addition to the
2013/8/23, Martin Burnicki martin.burni...@meinberg.de:
David Taylor wrote:
On 20/08/2013 13:25, Martin Burnicki wrote:
[]
There were 2 fields in the SHM segment which were previously unused and
are now used to take the nanoseconds from the refclock and from the
system time.
Thus programs
Sebastien WILLEMIJNS wrote:
Hello,
i installed meinberg release on windows 7 with default conf.
at startup, time is well clocked but after 2 minutes i decided to
change time (10 minutes later or 10 minutes less), poll and when values
seems to be frozen after this change
why time isn't now
On 2013-08-23, Charles Elliott elliott...@verizon.net wrote:
Several people on the mail list have suggested that the nmea clock driver
estimate the accuracy of the time reading by the divergence of the indicated
location from the GPS device's true location. Right now the nmea driver
does not
On Fri, Aug 23, 2013, at 15:27, Martin Burnicki wrote:
Hello,
This is a kind of test of run by beginners with NTP, but this doesn't
work as you expected.
yep you right but it is also a good test to check if time changes.
Maybe this question can be on any F.A.Q ? :)
@all, thanks for your
Michael Tatarinov wrote:
Yes, SHM driver is commented out but look at refclock_shm.c. The shm
refclock supports Windows and it's added over 15 year ago (according
to the BitKeeper).
ps. I don't know if it works?
Indeed. I've just enabled the SHM refclock in the config.h file for
Windows,
Answering both unruh and David Taylor here!
I haven't changed the configuration of NTP on the Raspberry Pi so it is still
using the default time servers:
server 0.debian.pool.ntp.org iburst
server 1.debian.pool.ntp.org iburst
server 2.debian.pool.ntp.org iburst
server 3.debian.pool.ntp.org
On 23/08/13 16:28, james.perou...@gmail.com wrote:
I'm suspecting that NTP has been told that the reference timer it is using has
a frequency of X MHz when it actually has a frequency of X*(1+2.5e-6)MHz. Where
would I look for such configuration information? I'm suspecting that it's in
one
On 2013-08-23, David Woolley david@ex.djwhome.demon.invalid wrote:
On 23/08/13 16:28, james.perou...@gmail.com wrote:
I'm suspecting that NTP has been told that the reference timer it is using
has a frequency of X MHz when it actually has a frequency of
X*(1+2.5e-6)MHz. Where would I look
Martin Burnicki martin.burni...@meinberg.de wrote:
Rob wrote:
Aha, ok... that is a solution, but I think it is a good idea to draw
a new SHM specification that adds a lot of functionality like described
in the mailing list article, and make it the prime reference clock interface
for ntpd.
On 23/08/2013 14:27, Martin Burnicki wrote:
[]
To see if NTP keeps adjusting the system time continuously and correctly
you could run ntpq -p repeatedly in a command line window on your
Windows machine, and watch how the reported offset (which is in
milliseconds) decreases until it reaches and
16 matches
Mail list logo
