Re: To synchronize system time witn NTP-server with no winter time shift whole year - how to?
On 2009-03-31_08:25:57, Ron Johnson wrote:
> On 2009-03-30 21:47, Paul E Condon wrote:
>> On 2009-03-30_18:57:33, Ron Johnson wrote:
> [snip]
>>>
>>> Whoever decided on an epoch of 1970-01-01 00:00:00 was extraordinarily
>>> shortsighted, though. The OpenVMS epoch gives much more
>>> flexibility...
>>
>> I'm not familiar with the OpenVMS epoch, but I don't believe
>> flexibility in a definition of a epoch can make it better. Where can I
>> read a discussion of the value of making a epoch flexible? And what on
>> earth does it mean to make an epoch flexible?
>
> The VMS epoch is fixed at 17-Nov-1858 00:00:00.0000000.
> http://vms.tuwien.ac.at/info/humour/vms-base-time-origin.txt
>
> "Flexible" is probably the wrong word. "More useful" is a better phrase,
> since is able to represent, and thus do arithmetic on 110 more years, in
> 100ns ticks instead of 1s ticks, than the Unix epoch.
100ns is comparable to the period of the clocking of the CPU. No OS
can produce time-stamps to the accuracy of a single period of the
clocking of the CPU on which it is running. The logic of a lot of the
processing of files is based on checking mtimes of the files. For
this to continue to work correctly, some logic will have to be
introduced to eliminate or ignore the jitter in these time data. This
is added complexity, not improvement. Perhaps a tick period that is
shorter than 1s might be justified some time in the future, jacking up
the precision of the recording, without a concurrent program for a
corresponding improvement in the accuracy of the clock, is madness, IMHO.
As an example of the difficulties, consider a quad core CPU chip, with
each core "independently" managing some files. There are race conditions
in such a situation. Checking time stamps will surely not be an adequate
way to resolve these race conditions. Extend this to a world wide network
of a global corporation. There will be race conditions. By itself 100ns
tick will not help in resolving these. In fact it will divert attention
from viable solutions.
We are on a clear path to having 64bit Unix clocks universally
deployed well before they will actually be needed, so the added time
span of the open nonsense proposal is inferior to what can easily be
done within the Unix tradition.
Just my $.02
--
Paul E Condon
pecondon@mesanetworks.net
Reply to: