Re: Any leap year issues caused by Ada yesterday?

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Tue, 06 Mar 2012 16:46:35 +0000, Simon Wright wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> Under VxWorks you can read the TSC without assembly, there is a library
>> function for that (pentiumTscGet64).
>>
>>    type Timestamp is new Unsigned_64;
>>    procedure pentiumTscGet64 (Clock : out Timestamp);
>>    pragma Import (C, pentiumTscGet64, "pentiumTscGet64");
>>
>> should do the work.
> 
> Not sure if there was an equivalent for PPC.

AFAIK, PPC has a high resolution real time counter, which is better
designed than Intel's TSC.

>> The actual problem is to get the multiplier, the BIOS time, and keeping the
>> TSC synchronized with the system clock. Funnily Wind River did all that for
>> Pentium IV. But then they were too lazy to support it on more recent x86
>> processors. The most troublesome thing about VxWorks is that Wind River
>> adds and removes its parts at will. There is no such thing as backward
>> compatibility whatsoever.
> 
> The board manufacturer defined the multiplier for us, so no problems.

But there is still a problem of synchronizing it with the system time if
that uses a different source, e.g. counted timer interrupts etc.

>> As for multicore/sleep mode issues, AFAIK Intel fixed that, i.e. the TSC
>> frequency is never changed. I don't know anything about MacOS, but probably
>> they deploy the same lousy schema of getting time from the PIT timer or
>> something like that, so the problems.
> 
> I think I may have misunderstood the evidence here. Trying it again, the
> TSC runs at pretty close to the nominal 2.4 GHz, but it was unreasonable
> of me to try to *measure* it by looping for a second and seeing how much
> the TSC changed, and then be surprised at errors of the order of a few
> milliseconds.

Right, the multiplier is not a whole number. Then since the accuracy of
system clock is catastrophic under VxWorks, you would not know how long a
time interval actually was. The last time I tried something like that under
VxWorks, it didn't work.

For x86 the multiplier must be taken from the BIOS. It is somehow
determined by the frequencies of the front bus and the processor.

> But, as you say, you have to calibrate the TSC somehow.

If the sources of the TSC and of the system clock are different, then there
is a systematic error. I suppose this is the major reason why it did not
work under VxWorks. The system time must be derived from the same quartz.
Otherwise you have to compensate the deviation, which could well be as big
as 5 microseconds per second.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de