Phil W Lee wrote:
David Taylor david-tay...@blueyonder.co.uk.invalid considered Tue,
16 Dec 2014 14:26:49 + the perfect time to write:
It would be helpful if the output from ntpq -crv showed the OS on which
NTP was running, as well as the OS on which it was built. I've
mentioned this
Phil W Lee wrote:
Martin Burnicki martin.burni...@meinberg.de considered Tue, 16 Dec
2014 12:56:15 +0100 the perfect time to write:
William Unruh wrote:
The importance of trades is usually a before/after. And UTC TAI, GPS all
have exactly the same definition of before and after. Of course if
Martin Burnicki martin.burni...@meinberg.de wrote:
The main problem is that the underlying system time (often POSIX, which
just counts seconds since an epoch) has the *same* time stamp art the
beginning and end of the leap second.
In order to do the conversion correctly you need to know if
Phil W Lee wrote:
Martin Burnicki martin.burni...@meinberg.de considered Tue, 16 Dec
2014 14:23:15 +0100 the perfect time to write:
Harlan Stenn wrote:
An alternative is that we get enough support to advance NTF's General
Timestamp API, and then we can run systems on either TAI or UTC and
Harlan Stenn wrote:
Martin Burnicki writes:
Harlan Stenn wrote:
An alternative is that we get enough support to advance NTF's General
Timestamp API, and then we can run systems on either TAI or UTC and
these conversions will happen automatically.
Since timescale files in the GTSAPI are
Phil W Lee wrote:
Martin Burnicki martin.burni...@meinberg.de considered Tue, 16 Dec
2014 12:48:57 +0100 the perfect time to write:
However, there is an important limitation: the tzdata version of the
leap second file is missing an expiration date, so even if a program
like ntpd could use this
Rob wrote:
Martin Burnicki martin.burni...@meinberg.de wrote:
The main problem is that the underlying system time (often POSIX, which
just counts seconds since an epoch) has the *same* time stamp art the
beginning and end of the leap second.
In order to do the conversion correctly you need to
Martin Burnicki martin.burni...@meinberg.de wrote:
Imagine you set up an event for April 2015 today, but you just don't
know if DST will be in effect at that time, or not, just because the
politicians haven't made the decision today. How will you handle this?
It may not be helpful if you
Martin Burnicki martin.burni...@meinberg.de wrote:
Unfortunately, the same mechanism isn't used for leap seconds.
There would be no problem at all when the system time ticked in TAI
and the addition of the leap seconds is done via some rule table similar
to the local time rules. ntpd would
David Taylor writes:
On 16/12/2014 13:48, Martin Burnicki wrote:
William Unruh wrote:
[]
And since at build time, one has things called configure which CAN run
tests on the build system, one could easily enable or disable it then.
But since as we all know ntpd tends to built on one
Rob wrote:
Martin Burnicki martin.burni...@meinberg.de wrote:
Unfortunately, the same mechanism isn't used for leap seconds.
There would be no problem at all when the system time ticked in TAI
and the addition of the leap seconds is done via some rule table similar
to the local time rules.
Phil W Lee writes:
Leap seconds seem to be a real mess in the IT world.
It would be useful if the way of inserting a leap-second was set in a
standard, in such a way that time continued at a set rate (maybe by
slewing at a set percentage or PPM). If that could be achieved, it
would remove
Phil W Lee writes:
Martin Burnicki martin.burni...@meinberg.de considered Tue, 16 Dec
2014 14:23:15 +0100 the perfect time to write:
Harlan Stenn wrote:
An alternative is that we get enough support to advance NTF's General
Timestamp API, and then we can run systems on either TAI or UTC
Harlan Stenn wrote:
Martin Burnicki writes:
Harlan Stenn wrote:
David Taylor writes:
I have a newly installed 64-bit Linux Debian 7.7 system where I am
trying to bring up NTP with PPS support. Using ppstest /dev/pps0 I get
the expected assert messages. I have gpsd configured and working.
I'd love to see discussion about what should the default number of
servers queried be for the 'pool' directive?
There is clearly a tradeoff, and I'm inclined to say that between 5 and
9 is probably a good number. It's certainly easy enough for folks to
join the pool, and I'd like to make that
Martin Burnicki writes:
This is just a subset of the information you get from ntpq -c rv, e.g.:
associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,
version=ntpd 4.2.6p5@1.2349-o Jul 30 11:55:08 (UTC+02:00) 2012 (2),
processor=x86, system=Windows, leap=00, stratum=2,
Martin Burnicki martin.burni...@meinberg.de wrote:
IMO the GPS system designers have made quite a number of wise decisions,
e.g. letting the GPS time simply increase monotonically, which is, from
a technical/usage point of view, similar to TAI.
That decision was wise. The decision to
Martin Burnicki writes:
Rob wrote:
Unfortunately, the same mechanism isn't used for leap seconds.
There would be no problem at all when the system time ticked in TAI
and the addition of the leap seconds is done via some rule table similar
to the local time rules. ntpd would not even be
Harlan Stenn st...@ntp.org wrote:
Paul writes:
On Tue, Dec 16, 2014 at 10:10 AM, Martin Burnicki
martin.burni...@meinberg.de wrote:
OK, but what is the problem in using these IOCTLs directly from within
ntpd, via wrapper functions or directly? Several refclock drivers do so.
You'll
Rob writes:
Harlan Stenn st...@ntp.org wrote:
Paul writes:
On Tue, Dec 16, 2014 at 10:10 AM, Martin Burnicki
martin.burni...@meinberg.de wrote:
OK, but what is the problem in using these IOCTLs directly from within
ntpd, via wrapper functions or directly? Several refclock drivers
Harlan Stenn st...@ntp.org wrote:
Rob writes:
Harlan Stenn st...@ntp.org wrote:
Paul writes:
On Tue, Dec 16, 2014 at 10:10 AM, Martin Burnicki
martin.burni...@meinberg.de wrote:
OK, but what is the problem in using these IOCTLs directly from within
ntpd, via wrapper functions or
Rob wrote:
Martin Burnicki martin.burni...@meinberg.de wrote:
Imagine you set up an event for April 2015 today, but you just don't
know if DST will be in effect at that time, or not, just because the
politicians haven't made the decision today. How will you handle this?
It may not be helpful
Rob wrote:
Martin Burnicki martin.burni...@meinberg.de wrote:
IMO the GPS system designers have made quite a number of wise decisions,
e.g. letting the GPS time simply increase monotonically, which is, from
a technical/usage point of view, similar to TAI.
That decision was wise. The decision
On Wed, Dec 17, 2014 at 12:04:04PM +, Harlan Stenn wrote:
I'd love to see discussion about what should the default number of
servers queried be for the 'pool' directive?
The How do I use pool.ntp.org? page [1] is pretty clear, quoting:
Be friendly. Many servers are provided by
On Wed, Dec 17, 2014 at 7:04 AM, Harlan Stenn st...@ntp.org wrote:
I'd love to see discussion about what should the default number of
servers queried be for the 'pool' directive?
I don't think it matters. Properly configured systems and sub-nets will
have little impact and poorly configured
Martin Burnicki martin.burni...@meinberg.de wrote:
Rob wrote:
Martin Burnicki martin.burni...@meinberg.de wrote:
IMO the GPS system designers have made quite a number of wise decisions,
e.g. letting the GPS time simply increase monotonically, which is, from
a technical/usage point of view,
Harlan Stenn wrote:
Martin Burnicki writes:
Rob wrote:
Unfortunately, the same mechanism isn't used for leap seconds.
There would be no problem at all when the system time ticked in TAI
and the addition of the leap seconds is done via some rule table similar
to the local time rules. ntpd
On 2014-12-16 10:28, Phil W Lee wrote:
Martin Burnicki martin.burni...@meinberg.de considered Tue, 16 Dec
2014 12:48:57 +0100 the perfect time to write:
Brian Inglis wrote:
It would be interesting to know what percentage of the pool servers even
use a leapseconds file, and how many of those
On 17/12/2014 08:52, Martin Burnicki wrote:
[]
This is just a subset of the information you get from ntpq -c rv, e.g.:
associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,
version=ntpd 4.2.6p5@1.2349-o Jul 30 11:55:08 (UTC+02:00) 2012 (2),
processor=x86, system=Windows, leap=00,
This is about receiving a pps signal via one of the gpio pins of the
raspberry pi and then feeding it to ntp.
Did a test for a while: every 5 minutes I would look at the output of
ntpq -c pe -n for jitter of the pps source.
This pps source was measured either in the kernel (this newly added
gpio
Is the Rpi overclocked? When overclocked it will dynamically change the
CPU frequency. You could potentially underclock it or heatsink the SoC
to keep the CPU frequency from changing.
Also, which version of the RPi? A, B or B-plus?
On 2014-12-17 12:22, folkert wrote:
This is about receiving
Rob writes:
Harlan Stenn st...@ntp.org wrote:
Rob writes:
Harlan Stenn st...@ntp.org wrote:
Paul writes:
On Tue, Dec 16, 2014 at 10:10 AM, Martin Burnicki
martin.burni...@meinberg.de wrote:
OK, but what is the problem in using these IOCTLs directly from withi
n
ntpd,
Miroslav Lichvar writes:
On Wed, Dec 17, 2014 at 12:04:04PM +, Harlan Stenn wrote:
I'd love to see discussion about what should the default number of
servers queried be for the 'pool' directive?
The How do I use pool.ntp.org? page [1] is pretty clear, quoting:
Be friendly. Many
Martin Burnicki writes:
Harlan Stenn wrote:
Martin Burnicki writes:
Rob wrote:
Unfortunately, the same mechanism isn't used for leap seconds.
There would be no problem at all when the system time ticked in TAI
and the addition of the leap seconds is done via some rule table similar
to
34 matches
Mail list logo
