On 2011-12-17T14:36:06-0800, Harlan Stenn wrote:
> Chad wrote:
> > Nov 20 15:30:06 ntpd[4969]: ntpd 4.2.2p1@1.1570-o Tue Feb 10 22:33:50 UTC
> > 2009 (1)
>
> This version of NTP was released in June of 2006. There have been 2
> major releases of NTP since then - 4.2.4 and 4.2.6. *Many* bugs ha
On 2011-12-14, Mark C. Stephens wrote:
> BSD sounds too good to be true!
When something sounds too good to be true then it generally isn't.
BTW ... what does this have to do with "New ntp server"?
--
Steve Kostecke
NTP Public Services Project - http://support.ntp.org/
__
Chad wrote:
> The scenario I'm worried about somewhat different from what has been
> described in this thread. I though I would add it to the chain as a use
> case developers should be aware of.
>
> I frequently see incorrect time after a system has been powered off or
> even just booted. The
On 2011-12-17, chad.far...@bull.com wrote:
> The scenario I'm worried about somewhat different from what has been
> described in this thread. I though I would add it to the chain as a use
> case developers should be aware of.
>
> I frequently see incorrect time after a system has been powered
On 12/17/2011 12:57 PM, David Malone wrote:
Dave Hart writes:
I did a bit of searching but of course this is an odd request: "help
me degrade the precision of my system clock, please" hasn't come up
much. If you have any suggestions, please speak up here, or privately
if you prefer.
On Fre
Miroslav Lichvar wrote:
Why not degrade the resolution of the clock directly in ntp sources?
Good idea.
In get_systime():
GET_SYSTIME_AS_TIMESPEC(&ts);
ts.tv_nsec /= 100;
ts.tv_nsec *= 100;
Ouch!
I'd far prefer a simple mask, getting rid of the bottom N bit
Dave Hart writes:
>I did a bit of searching but of course this is an odd request: "help
>me degrade the precision of my system clock, please" hasn't come up
>much. If you have any suggestions, please speak up here, or privately
>if you prefer.
On FreeBSD you could try selecting the "dummy" tim
On 12/16/2011 7:59 PM, chad.far...@bull.com wrote:
The scenario I'm worried about somewhat different from what has been
described in this thread. I though I would add it to the chain as a use
case developers should be aware of.
I frequently see incorrect time after a system has been powered off
On 12/17/2011 9:27 AM, David J Taylor wrote:
Folks,
I have noted that the logging of the initial drift value in ntp.4.2.4 -
messages like:
"frequency initialized 0.423 PPM from C:\Tools\NTP\etc\ntp.drift"
have been dropped from later versions of ntp (4.2.7 tested). I don't
recall the users bei
Folks,
I have noted that the logging of the initial drift value in ntp.4.2.4 -
messages like:
"frequency initialized 0.423 PPM from C:\Tools\NTP\etc\ntp.drift"
have been dropped from later versions of ntp (4.2.7 tested). I don't
recall the users being asked whether they wanted this change,
The scenario I'm worried about somewhat different from what has been
described in this thread. I though I would add it to the chain as a use
case developers should be aware of.
I frequently see incorrect time after a system has been powered off or
even just booted. The amount of time varies a
11 matches
Mail list logo
