[Info-vax] Clock running very slow on an Alpha

[Mark Berryman]

On 8/25/10 6:13 PM, Richard B. Gilbert wrote:
> Mark Berryman wrote:
>> On 8/25/10 2:12 PM, Richard B. Gilbert wrote:
>> .
>> .
>> .
>>>
>>> The maximum error that a standard NTP can correct is 43 seconds per day!
>>>
>>
>> That is not at all correct. NTP is capable of correcting any amount of
>> error. You simply set parameters that define how much error is fixed
>> by slewing the clock vs when the clock is corrected in a single step.
>>
> Alright! 43 seconds per day is the largest error correctable without
> stepping the clock or tampering with the parameters used by NTPD.
> 43 seconds per day represents a slew rate of 500 PPM, the largest slew
> rate that the stock NTPD will use.

NTPD will slew adjust the clock as long as the offset is less than the 
step threshold which, by default and without changing any parameters in 
the config file, is 128ms.  Any offset outside of that is step adjusted. 
  With completely default parameters, NTP will still fix errors of more 
than 43 seconds per day because, by default and without any changes to 
its parameters, it uses a mix of slew and step adjustments as required.

>
>> I have had systems come up with a date several years wrong because the
>> TOY clock does not keep year information and a backup had just been
>> restored. NTP updated the clock just fine in these cases.
>>
> Startup is a special case. You can tell NTPD to figure out what time it
> is and set that time. Once the system is running, stepping the clock and
> especially stepping it backward can wreak havoc with programs that
> expect that time will be monotonically increasing.

Running NTP guarantees that the system time will not change on a 
strictly monotonic basis as NTP will cause the clock to increment by 
varying amounts.  Save for realtime systems, programs neither know nor 
care whether the time changes monotonically since they have no control 
over how they are scheduled (i.e. between the time slices in which they 
are actually executing they neither know nor care by what steps the 
clock was incremented).  There are a decreasing number of programs that 
do not like the clock to move backwards.  However, systems that run such 
programs either do not change the clock for daylight savings or have 
some manual process in place for handling it.  Such issues are outside 
the scope of NTP.

>
>> NTP routinely corrects errors of 3600 or more seconds twice a year for
>> many systems. That is why the sanity timer usually defaults to a value
>> of 4000.
>
> If you are thinking of the switch from daylight savings to standard time
> and vice versa. NTPD does NOT do this, does not know about it, and
> doesn't care about it. Remember NTPD deals with UTC only. Daylight time
> is, in effect a shift in time zone, even though we don't call it that.

That is not at all correct.  While NTP exchanges messages in UTC it most 
definitely knows about systems that use local time rather than UTC and 
adjusts the clock when the local time changes.  If it did not know this, 
it would keep trying to change the clock to UTC rather than whatever the 
local timezone is.  At the daylight savings change, the local timezone 
offset from UTC changes, NTP recognizes this and adjusts the clock.  I 
have a very large number of systems that do just this and have been for 
many years.

In fact, here is a comment from the ntp.conf file:

;Specify how large a time correction is allowed before the server will
;refuse and exit rather than make it.  If your time zone uses
;Daylight Savings Time, this value should be left at its default value,
;or set larger, but never set to a smaller value.  DST requires a
;change of 3600 seconds for most, if not all, time zones, and the sanity
;check value should be set a bit larger in case the clock is off
;at the time.

If NTP did not know how to handle the change for daylight savings, I do 
not think a comment of this nature would be present (and the systems I 
have that use NTP to adjust the clock at daylight savings transitions 
wouldn't get their clocks adjusted).

Mark Berryman

--- news://freenews.netfront.net/ - complaints: news at netfront.net ---