Achim Gratz via devel :
> Matthew Selsky via devel writes:
> > On Tue, Jun 29, 2021 at 04:41:30PM -0400, Eric S. Raymond via devel wrote:
> >
> >> Well, first, the historical target for accuracy of WAN time service is
> >> more than an order of magnitude higher than 1ms. The worst-case jitter
> >>
Hal Murray via devel writes:
> I'd like to move the current kernel mode PLL to user space. I think modern
> CPUs are fast enough for that to make sense. I haven't done any
> experimentation.
That doesn't buy you what you seem to think it does.
This in-kernel PLL (at least on Linux) benefits f
Richard Laager via devel writes:
> On 6/29/21 3:41 PM, Eric S. Raymond via devel wrote:
>> Well, first, the historical target for accuracy of WAN time service is
>> more than an order of magnitude higher than 1ms.
>
> My two NTP servers are +- 0.1 ms and +- 0.2 ms as measured by the NTP
> pool moni
Matthew Selsky via devel writes:
> On Tue, Jun 29, 2021 at 04:41:30PM -0400, Eric S. Raymond via devel wrote:
>
>> Well, first, the historical target for accuracy of WAN time service is
>> more than an order of magnitude higher than 1ms. The worst-case jitter
>> that could add would be barely abov
On Wed, Jun 30, 2021, at 11:59 AM Hal Murray wrote:
>
>
> > The build epoch has been replaced with a hardcoded timestamp which will be
> > manually updated every nine years or so (approx 512w). This makes the
> > binaries reproducible by default.
>
> What source file holds that timestamp?
libntp
> The build epoch has been replaced with a hardcoded timestamp which will be
> manually updated every nine years or so (approx 512w). This makes the
> binaries reproducible by default.
What source file holds that timestamp?
Where is it used?
One place is the version string. Where else?
--
T
On Wed, Jun 30, 2021, at 5:17 AM Hal Murray via devel wrote:
>
>
> e...@thyrsus.com said:
> > The remaining blocker is that the NTP packet format would need to be
> > redesigned.
>
> No, we just have to play the wrap around game when converting from network
> time to unix time. If the network tim
e...@thyrsus.com said:
> The remaining blocker is that the NTP packet format would need to be
> redesigned.
No, we just have to play the wrap around game when converting from network
time to unix time. If the network time is before the build time add 1<<32
seconds. And drop the high bits whe
Richard Laager via devel :
> Not particularly. Presumably it's just because of GPS PPS + good network?
Having a good local clock can explaiin it, yes.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
devel mailing list
devel@ntpsec.
Hal Murray via devel :
> There is the 32bit time_t problem. We've got a few more years.
I've been thinking forward about that. One of my objectives in the
big cleanup was to make the time width easier to change, and now it
would be internally. The remaining blocker is that the NTP packet
format
10 matches
Mail list logo
