Any leap year issues caused by Ada yesterday?

Any leap year issues caused by Ada yesterday?

[Georg Bauhaus]

News travels the wires of the internet telling us about MS Azure outages
in several places. These were seemingly caused by a piece of software
handling calendar dates involving February 29, 2012.

 Which makes me think, presuming it is as simple as it looks,
is there a software setup that prevents this kind of damage by
definition?

(The bigger companies are too big fail just because of a software bug,
even if it is of the ravenous bugblatter beast of Traal kind.
Maybe a bug that was fixed is even generating attention.
But it might help the businesses surviving only if such things do not
happen ... again.)


From [1]:
"Yesterday, February 28th, 2012 at 5:45 PM PST Windows Azure operations
became aware of an issue impacting the compute service in a number of
regions.  The issue was quickly triaged and it was determined to be caused by
a software bug.  While final root cause analysis is in progress, this issue
appears to be due to a time calculation that was incorrect for the leap
year. Once we discovered the issue we immediately took steps to protect
customer services that were already up and running, and began creating a fix
for the issue.  The fix was successfully deployed to most of the Windows
Azure sub-regions and we restored Windows Azure service availability to the
majority of our customers and services by 2:57AM PST, Feb 29th."

http://blogs.msdn.com/b/windowsazure/archive/2012/03/01/windows-azure-service-disruption-update.aspx

via

http://www.forbes.com/sites/ciocentral/2012/02/29/microsoft-windows-azure-cloud-service-suffers-big-outage/

Re: Any leap year issues caused by Ada yesterday?

[tonyg]

On Mar 1, 1:06 pm, Georg Bauhaus <rm.dash-bauh...@futureapps.de>
wrote:
> News travels the wires of the internet telling us about MS Azure outages
> in several places. These were seemingly caused by a piece of software
> handling calendar dates involving February 29, 2012.
>
>  Which makes me think, presuming it is as simple as it looks,
> is there a software setup that prevents this kind of damage by
> definition?
>
> (The bigger companies are too big fail just because of a software bug,
> even if it is of the ravenous bugblatter beast of Traal kind.
> Maybe a bug that was fixed is even generating attention.
> But it might help the businesses surviving only if such things do not
> happen ... again.)
>
> From [1]:
> "Yesterday, February 28th, 2012 at 5:45 PM PST Windows Azure operations
> became aware of an issue impacting the compute service in a number of
> regions.  The issue was quickly triaged and it was determined to be caused by
> a software bug.  While final root cause analysis is in progress, this issue
> appears to be due to a time calculation that was incorrect for the leap
> year. Once we discovered the issue we immediately took steps to protect
> customer services that were already up and running, and began creating a fix
> for the issue.  The fix was successfully deployed to most of the Windows
> Azure sub-regions and we restored Windows Azure service availability to the
> majority of our customers and services by 2:57AM PST, Feb 29th."
>
> http://blogs.msdn.com/b/windowsazure/archive/2012/03/01/windows-azure...
>
> via
>
> http://www.forbes.com/sites/ciocentral/2012/02/29/microsoft-windows-a...

Personally I deal with it by using the ada.calendar package rather
than writing my own. I hope that answers your question.

Re: Any leap year issues caused by Ada yesterday?

[Shark8]

On Monday, March 5, 2012 5:07:29 AM UTC-6, tonyg wrote:
> On Mar 1, 1:06 pm, Georg Bauhaus <rm.dash-bauh...@futureapps.de>
> wrote:
> > News travels the wires of the internet telling us about MS Azure outages
> > in several places. These were seemingly caused by a piece of software
> > handling calendar dates involving February 29, 2012.
> >
> >  Which makes me think, presuming it is as simple as it looks,
> > is there a software setup that prevents this kind of damage by
> > definition?
> >
> > (The bigger companies are too big fail just because of a software bug,
> > even if it is of the ravenous bugblatter beast of Traal kind.
> > Maybe a bug that was fixed is even generating attention.
> > But it might help the businesses surviving only if such things do not
> > happen ... again.)
> >
> > From [1]:
> > "Yesterday, February 28th, 2012 at 5:45 PM PST Windows Azure operations
> > became aware of an issue impacting the compute service in a number of
> > regions.  The issue was quickly triaged and it was determined to be caused by
> > a software bug.  While final root cause analysis is in progress, this issue
> > appears to be due to a time calculation that was incorrect for the leap
> > year. Once we discovered the issue we immediately took steps to protect
> > customer services that were already up and running, and began creating a fix
> > for the issue.  The fix was successfully deployed to most of the Windows
> > Azure sub-regions and we restored Windows Azure service availability to the
> > majority of our customers and services by 2:57AM PST, Feb 29th."
> >
> > http://blogs.msdn.com/b/windowsazure/archive/2012/03/01/windows-azure...
> >
> > via
> >
> > http://www.forbes.com/sites/ciocentral/2012/02/29/microsoft-windows-a...
> 
> Personally I deal with it by using the ada.calendar package rather
> than writing my own. I hope that answers your question.

Indeed, given the needed amount of work put into timing* (for tasks), it would seem VERY odd if the Ada.Calendar package did not deal with leap-year; also, given that it deals with leap-seconds, not dealing w/ leap-year's 29Feb would be inconsistent.

* Granted, for real-time systems the leap-year/leap-second thing is quite undesirable, giving rise to the monotonic time of the Real_Time package.

Re: Any leap year issues caused by Ada yesterday?

[Dmitry A. Kazakov]

On Mon, 5 Mar 2012 07:59:30 -0800 (PST), Shark8 wrote:

> On Monday, March 5, 2012 5:07:29 AM UTC-6, tonyg wrote:

>> Personally I deal with it by using the ada.calendar package rather
>> than writing my own. I hope that answers your question.
> 
> Indeed, given the needed amount of work put into timing* (for tasks), it
> would seem VERY odd if the Ada.Calendar package did not deal with
> leap-year;

No package can actually. The duration of the day (stellar, solar etc) is
not constant due to various factors. Therefore corrections are necessary,
time to time. These corrections are unknown in advance.

> * Granted, for real-time systems the leap-year/leap-second thing is quite
> undesirable, giving rise to the monotonic time of the Real_Time package.

Leap seconds do not influence durations, which is the only thing relevant
for control systems. Systems that use time stamps are not much influenced
by leap seconds either because they too use durations (from some epoch)
rather than local political time.

BTW, I would not wonder to see Real_Time.Time and Calendar.Time same or
correlated.

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

Re: Any leap year issues caused by Ada yesterday?

[Simon Wright]

"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?

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,
so you were always related to the actual clock. A different compiler (or
a different OS) might use a different design.

AdaCore accepted the bug report (after we pointed out the "shall" in
ARM95 D.8(32)).

http://www.adaic.org/resources/add_content/standards/95lrm/ARM_HTML/RM-D-8.html

Re: Any leap year issues caused by Ada yesterday?

[Dmitry A. Kazakov]

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.

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.

> 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.]

> 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.

> 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.

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

Re: Any leap year issues caused by Ada yesterday?

[Simon Wright]

"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?

>> 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).

>> 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).

It should have been easy enough on VxWorks: taskDelay(period + 1); (but
there may be all sorts of complicated reasons why that wouldn't be
enough).

Re: Any leap year issues caused by Ada yesterday?

[Dmitry A. Kazakov]

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

Re: Any leap year issues caused by Ada yesterday?

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> 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 (:-))

Our (VxWorks) solution was to use the PowerPC timebase register; at each
clock tick, store the Ada clock and the current tb; in between, use the
tb to interpolate. On the hardware we were using, that gave us 40 ns
resolution (a microsecond would have been fine!)

I couldn't show you that code even if I still had access, it's
proprietary, but there's something at [1].

An Intel equivalent used to work, but (a) most OSs give microsecond
resolution anyway, (b) it certainly doesn't work on Mac OS X with dual
cores where the core is slowed right down if it has nothing to do! (my
interpretation of the observed behaviour).

[1] http://booch95.svn.sourceforge.net/viewvc/booch95/trunk/src/bc-support-high_resolution_time-clock.adb-ppc32?revision=1415&view=markup

Re: Any leap year issues caused by Ada yesterday?

[Dmitry A. Kazakov]

On Tue, 06 Mar 2012 09:20:55 +0000, Simon Wright wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> 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 (:-))
> 
> Our (VxWorks) solution was to use the PowerPC timebase register; at each
> clock tick, store the Ada clock and the current tb; in between, use the
> tb to interpolate. On the hardware we were using, that gave us 40 ns
> resolution (a microsecond would have been fine!)

I know that PowerPC is so much better in that respect than x86.
Unfortunately it showed an astonishingly poor performance when we run our
initial tests about 2 years ago, so we switched to x86.

> I couldn't show you that code even if I still had access, it's
> proprietary, but there's something at [1].
> 
> An Intel equivalent used to work, but (a) most OSs give microsecond
> resolution anyway,

Not VxWorks, not Windows (I didn't checked Windows 7, though). Under
Windows we use the performance counter and a background thread which
synchronizes it with the system clock. This works perfectly well, but
requires statistical processing and is too slow for 10kHz cycles we have to
run under VxWorks.

> (b) it certainly doesn't work on Mac OS X with dual
> cores where the core is slowed right down if it has nothing to do! (my
> interpretation of the observed behaviour).
>
> [1] http://booch95.svn.sourceforge.net/viewvc/booch95/trunk/src/bc-support-high_resolution_time-clock.adb-ppc32?revision=1415&view=markup

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.

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.

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.

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

Re: Any leap year issues caused by Ada yesterday?

[Georg Bauhaus]

On 06.03.12 11:07, Dmitry A. Kazakov wrote:
> The actual problem is to get the multiplier, the BIOS time, and keeping the
> TSC synchronized with the system clock.

Why isn't there a chip that does just one thing:
signal regularly, at sufficiently high frequency,
and totally independent of its electrical surroundings,
autonomous,
unaffected by software,
and having its own power supply?
Ping - ping - ping - ping - ...
Into some memory location, maybe?

Or is there?

Re: Any leap year issues caused by Ada yesterday?

[Dmitry A. Kazakov]

On Tue, 06 Mar 2012 11:51:31 +0100, Georg Bauhaus wrote:

> On 06.03.12 11:07, Dmitry A. Kazakov wrote:
>> The actual problem is to get the multiplier, the BIOS time, and keeping the
>> TSC synchronized with the system clock.
> 
> Why isn't there a chip that does just one thing:
> signal regularly, at sufficiently high frequency,
> and totally independent of its electrical surroundings,
> autonomous,
> unaffected by software,
> and having its own power supply?
> Ping - ping - ping - ping - ...
> Into some memory location, maybe?
> 
> Or is there?

The TSC is, except for being off without power.

The problem is to figure out what year is 764223417. Counter is not yet a
clock. A clock ultimately gives something like 764223417ns since 1 January
2011 00:00 UTC or a method to convert a number into a date and back. Not a
trivial problem, even when ignoring the relativity theory...

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

Re: Any leap year issues caused by Ada yesterday?

[Simon Wright]

"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.

> 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.

> 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. But, as you say, you have to calibrate the TSC somehow.

Re: Any leap year issues caused by Ada yesterday?

[Dmitry A. Kazakov]

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

Re: Any leap year issues caused by Ada yesterday?

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> 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.

Yes, the Time Base.

Ours was a 32-bit implementation, so you get to read the lower and upper
halves of the timebase separately, which would cause problems at
rollover. So read the TB using an internal Clock like this

   function Clock return Time is

      type Half is (High, Low);
      type High_Low is array (Half) of Interfaces.Unsigned_32;

      Upper, Lower, Upper_Again : Interfaces.Unsigned_32;

      function To_Time is new Ada.Unchecked_Conversion (High_Low, Time);

      use type Interfaces.Unsigned_32;

   begin

      loop
         System.Machine_Code.Asm
           ("mftbu %0" & ASCII.LF & ASCII.HT &
              "mftb %1" & ASCII.LF & ASCII.HT &
              "mftbu %2",
            Outputs =>
              (Interfaces.Unsigned_32'Asm_Output ("=r", Upper),
               Interfaces.Unsigned_32'Asm_Output ("=r", Lower),
               Interfaces.Unsigned_32'Asm_Output ("=r", Upper_Again)),
            Volatile => True);
         exit when Upper_Again = Upper;
      end loop;

      return To_Time ((High => Upper, Low => Lower));

   end Clock;

The timebase ran off the same crystal as the decrementer, so all were
internally sync'd. Internally, our synchronised time was
(Ada.Calendar.Clock (at last clock interrupt, of course) + high-res time
since last clock interrupt). We added the external sync offset on
sending a time off-board, and subtracted it on receiving one.

(I've never used VxWorks on x86).

Re: Any leap year issues caused by Ada yesterday?

[Shark8]

On Tuesday, March 6, 2012 11:37:35 AM UTC-6, Dmitry A. Kazakov wrote:
> 
> 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.

Really? I thought the whole point of using Quartz crystals was because they vibrate at a precise rate; or is the problem analogous to the "beats" that you hear when two musical instruments* are slightly out of tune?

(*Guitar comes immediately to mind; especially as it uses that as part of the tuning process.)

Re: Any leap year issues caused by Ada yesterday?

[Dmitry A. Kazakov]

On Tue, 06 Mar 2012 17:59:04 +0000, Simon Wright wrote:

> The timebase ran off the same crystal as the decrementer, so all were
> internally sync'd. Internally, our synchronised time was
> (Ada.Calendar.Clock (at last clock interrupt, of course) + high-res time
> since last clock interrupt).

You could improve that a bit by putting Ada.Calendar.Clock into a loop.
When it returns a different value, you exit the loop and take that value
for the time base.

If the quartz is same you need not to synchronize it anymore. Since the
multiplier is known you simply add the RTC minus its value at the base
multiplied by the factor and converted to Duration (or Time_Span) to the
base and use that instead of the original Ada's Clock.

Did you check the kernel settings? It has a variable that sets the time
source to the RTC. This might work on your PPC's BSP. The effect is that
the system clock is changed each time when queried rather than upon timer
interrupts.

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

Re: Any leap year issues caused by Ada yesterday?

[Dmitry A. Kazakov]

On Tue, 6 Mar 2012 11:08:37 -0800 (PST), Shark8 wrote:

> On Tuesday, March 6, 2012 11:37:35 AM UTC-6, Dmitry A. Kazakov wrote:
>> 
>> 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.
> 
> Really? I thought the whole point of using Quartz crystals was because
> they vibrate at a precise rate; or is the problem analogous to the "beats"
> that you hear when two musical instruments* are slightly out of tune?

I am not a physicist, but we actually measured TSC of two identical
computers (same motherboard, processor, manufacturer etc). The deviation
was microseconds per second.
 
> (*Guitar comes immediately to mind; especially as it uses that as part of the tuning process.)

In that analogy it is like two strings having different tension or
diameter.

But what I meant was not oscillators of almost same period, but rather ones
having absolutely unrelated periods, e.g. the BIOS clock and the TSC. x86
has many clocks spread in abundance all over the motherboard. They are
physically different, unsynchronized etc.

OS designers carefully select the least accurate and most unreliable of
them for the time source... (:-))

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

Re: Any leap year issues caused by Ada yesterday?

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Tue, 06 Mar 2012 17:59:04 +0000, Simon Wright wrote:
>
>> The timebase ran off the same crystal as the decrementer, so all were
>> internally sync'd. Internally, our synchronised time was
>> (Ada.Calendar.Clock (at last clock interrupt, of course) + high-res time
>> since last clock interrupt).
>
> You could improve that a bit by putting Ada.Calendar.Clock into a loop.
> When it returns a different value, you exit the loop and take that value
> for the time base.

Ada.Calendar.Clock was basically the POSIX gettimeofday() (?) from
VxWorks; which was (epoch + ticks/clockrate). So it was updated at clock
interrupt.

> If the quartz is same you need not to synchronize it anymore. Since the
> multiplier is known you simply add the RTC minus its value at the base
> multiplied by the factor and converted to Duration (or Time_Span) to the
> base and use that instead of the original Ada's Clock.

Didn't want to mess with the RTS use of Ada.Calendar.Time for delays. No
point in using Ada.Real_Time.Time because (then) it was the same as
Ada.Calendar.Time. So we had AC.Time (for internal use only),
<Project>.Calendar.Time for both internal & external use (but not, of
course, for delays).

> Did you check the kernel settings? It has a variable that sets the time
> source to the RTC. This might work on your PPC's BSP. The effect is that
> the system clock is changed each time when queried rather than upon timer
> interrupts.

Don't remember that one.

Re: Any leap year issues caused by Ada yesterday?

[tmoran]

> Otherwise you have to compensate the deviation, which could well be as big
> as 5 microseconds per second.
  Where do you find PCs with such a good clock?  PCs of my acquaintance
typically have a performance counter error of a few seconds/day, which
is more like 5 times that bad.

Re: Any leap year issues caused by Ada yesterday?

[Simon Wright]

tmoran@acm.org writes:

>> Otherwise you have to compensate the deviation, which could well be as big
>> as 5 microseconds per second.

>   Where do you find PCs with such a good clock?  PCs of my acquaintance
> typically have a performance counter error of a few seconds/day, which
> is more like 5 times that bad.

We used this - http://defense.ge-ip.com/products/2113 - the clock
deviation on the datasheet was 50 ppm AFAICR.