Re: Any leap year issues caused by Ada yesterday?

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

On Mon, 05 Mar 2012 20:56:09 +0000, Simon Wright wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Mon, 05 Mar 2012 18:30:46 +0000, Simon Wright wrote:
>>
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>> 
>>>> BTW, I would not wonder to see Real_Time.Time and Calendar.Time same
>>>> or correlated.
>>> 
>>> We were surprised and disappointed to find that earlier releases of GNAT
>>> did have them the same. What happens to your precise timing if you get
>>> an NTP update in the middle of it?
>>
>> Nothing, because I would expect the NTP client to leave alone the clock
>> readings and the arithmetic of. It should rather adjust Split and Time_Of.
> 
> Some people would arrange time sync such that if:
> 
> a) you read the clock
> b) time sync sets the clock back 1 second
> c) after 1 second you read the clock again
> 
> that the time read at a) and c) would be the same. 
> 
>> In our setups we are using a different schema anyway. Instead of
>> adjusting clocks we do the time stamps when sending them from host to
>> host.
> 
> Because of the GNAT bug we couldn't use Ada.Real_Time. So we left
> Ada.Calendar untouched and made our own <project>.Calendar with offsets,
> as you say. Fun with I/O of time,
> 
>>> OK, this is slightly GNAT-related, since (at that time, anyway) "delay
>>> 0.5" translated under the hood into "delay until now + 0.5" on VxWorks,
>>
>> Yes, but NTP should not mingle in that. [I don't know how the VxWorks NTP
>> client works.]
> 
> I don't understand? What else would it do but change the value of
> Ada.Calendar.Clock?

It would be difficult to do. The most straightforward and efficient
implementation of Time is a 64-bit number (N) taken directly from the
corresponding machine register, e.g. the performance counter. Why would you
change it (provided any machine support for doing that existed)? You would
rather leave it as is and adjust the epoch instead (and, unlikely, the
multiplier) when calculating the calendar time:

   Epoch time + N * Multiplier

This is needed only in operations dealing with year, month etc, e.g. Split.
Granted there could issues with delay until <many-days-ahead>, but this is
negligibly comparing to the problems when the performance counter were
indeed adjusted.

>>> so you were always related to the actual clock.
>>
>> VxWorks clock on i7 is a garbage. It is driven by the timer interrupts,
>> i.e. to get 1ms resolution you need 1000 interrupts per second.
>>
>> We keep on asking Wind River to fix the mess, but without much success so
>> far. GNAT simply uses that clock. So delay 0.001 may mean absolutely
>> anything under VxWorks. To fix that one should rewrite the time driver.
> 
> We were quite happy with 1 ms ticks. So delay 0.001 meant "delay at
> least 1 and no more than 2 ms" (like always).

If you set the timer at 1ms rate, you would have 1ms delays. The problem is
that the time stamps would have only 1ms accuracy! For 10kHz measurements
and control we are doing, this is a bit dire. So we are setting the timer
interrupts at 0.01ms (which is our humble contribution to the "man-made"
climate change (:-))

>>> AdaCore accepted the bug report (after we pointed out the "shall" in
>>> ARM95 D.8(32)).
>>
>> Well, I would not blame AdaCore for that, it is Wind River's fault,
>> IMO.
> 
> This was *Ada* running on VxWorks; so it needed fixing. We didn't care
> who fixed it (well, as far as we were concerned, who didn't fix it,
> actually).

Yes, but AdaCore has neither the resources nor desire to patch crappy OSes.
They will have enough to do fixing the problems introduced with the
implementation of Ada 2012...

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