Harlan Stenn st...@ntp.org wrote:
If you disgree and think NTP should provide the file all the time, then:
- how do you propose we find out if the underlying API is really
provided in the currently-running kernel?
The source of the includefile does absolutely nothing in the ways of
solving
Sander Smeenk wrote:
Quoting Paul (tik-...@bodosom.net):
But i'm quite sure driver 22 is compiled in the binary i'm running.
Almost certainly not.
I was caught by the refclock strings that appear in the binary and the
--enable-all-clocks configure option being used. But the latter doesn't
To close this parenthesis I did the test for leap second only being propagated
by 1 of three servers and Bill’s hypothesis is confirmed with a couple of
precisions that I would like to share as it might just be a real life case.
a) To start off , in my test all three servers to my one client
Rob writes:
Harlan Stenn st...@ntp.org wrote:
If you disgree and think NTP should provide the file all the time, then:
- how do you propose we find out if the underlying API is really
provided in the currently-running kernel?
The source of the includefile does absolutely nothing in the
Martin Burnicki writes:
IMO the best approach would be to detect this at runtime.
That means we'd need a header file...
If I'm not mistaken (and it's getting late for me), if the header file
is missing we don't expect the API. If the header file is present we
expect it to do the right thing
Mike,
I think you are seeing the correct and expected behavior.
The root cause here is that the majority of the upstream servers are
*incorrectly* not advertising the leap second.
There have been problems before where a misconfigured server has
incorrectly advertised a non-existent leap-second,
I agree that it is expected. Just wanted to confirm for myself. Habit from my
admin/support days. Agreed that anyone needing the tai delta would load the
leap file, but ntpd could propagate that info as well. I haven’t checked the
code to see if it is supposed to, but in my test it wasn’t.
Harlan Stenn st...@ntp.org wrote:
Martin Burnicki writes:
IMO the best approach would be to detect this at runtime.
That means we'd need a header file...
If I'm not mistaken (and it's getting late for me), if the header file
is missing we don't expect the API. If the header file is present
On Mon, 8 Dec 2014, Phil W Lee wrote:
In theory, this wouldn't be expensive if done at the mass production
stage, but clock stability isn't high enough on the design priorities
for designers to put it into mass market machines.
It's been awhile since I've heard this whine on c.p.t.n.
Harlan Stenn st...@ntp.org wrote:
Rob writes:
Harlan Stenn st...@ntp.org wrote:
If you disgree and think NTP should provide the file all the time, then:
- how do you propose we find out if the underlying API is really
provided in the currently-running kernel?
The source of the
Harlan Stenn wrote:
Martin Burnicki writes:
IMO the best approach would be to detect this at runtime.
That means we'd need a header file...
It shouldn't be a problem to add this to the NTP code base.
If I'm not mistaken (and it's getting late for me), if the header file
is missing we
On Dec 12, 2014 12:39 AM, Harlan Stenn st...@ntp.org wrote:
It's an OS-specific file that should be provided by the OS if the
underlying API exists.
To repeat what I reminded you of last time. Linux *doesn't* have the API.
The macros in timepps provide the RFC compliant API. The NTP
On 12/12/14 12:40, Martin Burnicki wrote:
Harlan Stenn wrote:
Martin Burnicki writes:
IMO the best approach would be to detect this at runtime.
That means we'd need a header file...
It shouldn't be a problem to add this to the NTP code base.
NTP doesn't control this interface. The de
On Fri, Dec 12, 2014 at 9:47 AM, David Woolley
david@ex.djwhome.demon.invalid wrote:
NTP doesn't control this interface. The de facto interface is defined by
the kernel code.
I don't understand this.
___
questions mailing list
On 12/12/14 16:28, Paul wrote:
On Fri, Dec 12, 2014 at 9:47 AM, David Woolley
david@ex.djwhome.demon.invalid wrote:
NTP doesn't control this interface. The de facto interface is defined by
the kernel code.
I don't understand this.
My misunderstanding. I thought this was doing the job of
On 2014-12-12, Rob nom...@example.com wrote:
Harlan Stenn st...@ntp.org wrote:
Rob writes:
Harlan Stenn st...@ntp.org wrote:
If you disgree and think NTP should provide the file all the time, then:
- how do you propose we find out if the underlying API is really
provided in the
On 2014-12-12, Harlan Stenn st...@ntp.org wrote:
Mike,
I think you are seeing the correct and expected behavior.
The root cause here is that the majority of the upstream servers are
*incorrectly* not advertising the leap second.
There have been problems before where a misconfigured server
Rob writes:
Harlan Stenn st...@ntp.org wrote:
Martin Burnicki writes:
IMO the best approach would be to detect this at runtime.
That means we'd need a header file...
If I'm not mistaken (and it's getting late for me), if the header file
is missing we don't expect the API. If the
Rob writes:
Harlan Stenn st...@ntp.org wrote:
Rob writes:
Harlan Stenn st...@ntp.org wrote:
If you disgree and think NTP should provide the file all the time, then:
- how do you propose we find out if the underlying API is really
provided in the currently-running kernel?
The
Paul writes:
--001a11c12566ef4fbd050a04ed7c
Content-Type: text/plain; charset=ISO-8859-1
On Dec 12, 2014 12:39 AM, Harlan Stenn st...@ntp.org wrote:
It's an OS-specific file that should be provided by the OS if the
underlying API exists.
To repeat what I reminded you of last time.
Martin,
Martin Burnicki writes:
Harlan Stenn wrote:
Martin Burnicki writes:
IMO the best approach would be to detect this at runtime.
That means we'd need a header file...
It shouldn't be a problem to add this to the NTP code base.
If I'm not mistaken (and it's getting late for
William Unruh writes:
On 2014-12-12, Harlan Stenn st...@ntp.org wrote:
Mike,
I think you are seeing the correct and expected behavior.
The root cause here is that the majority of the upstream servers are
*incorrectly* not advertising the leap second.
There have been problems
On 2014-12-13, Harlan Stenn st...@ntp.org wrote:
Martin,
...
It might very well be that we can separate some of these parts into an
internal and an external file, but again, we've been down this path
before with the MOD_NANO and STA_NANO stuff; why would we want to
*invite* this kind of
On 2014-12-13, Harlan Stenn st...@ntp.org wrote:
William Unruh writes:
On 2014-12-12, Harlan Stenn st...@ntp.org wrote:
Mike,
I think you are seeing the correct and expected behavior.
The root cause here is that the majority of the upstream servers are
*incorrectly* not advertising
On Fri, Dec 12, 2014 at 7:23 PM, Harlan Stenn st...@ntp.org wrote:
In how many places should that be documented? Where should it be
documented in the NTP distribution, or on any of the websites?
Not to be (too) flip but I'd create a file called :README.1ST with some
text like:
Much of the
William Unruh writes:
On 2014-12-13, Harlan Stenn st...@ntp.org wrote:
Martin,
...
It might very well be that we can separate some of these parts into an
internal and an external file, but again, we've been down this path
before with the MOD_NANO and STA_NANO stuff; why would we want
Bill,
I'm done trying to have a productive discussion with you about this.
H
William Unruh writes:
On 2014-12-13, Harlan Stenn st...@ntp.org wrote:
William Unruh writes:
On 2014-12-12, Harlan Stenn st...@ntp.org wrote:
Mike,
I think you are seeing the correct and expected
27 matches
Mail list logo
