Platform independent calendar

Platform independent calendar

[Mike H]

I am working (solo) on a signalling related application for a UK 
preserved railway. The system needs to be as near to totally platform 
independent as possible. As I see it, this rules out use of package 
Calendar.

Rather than re-invent a wheel, I would prefer to use a pre-existing 
solution and would be grateful for suggestions.
-- 
Mike Hopkins

Re: Platform independent calendar

[RasikaSrinivasan]

On Dec 7, 10:43 am, Mike H <newsrea...@ada-
augusta.demon.co.uk.INVALID> wrote:
> I am working (solo) on a signalling related application for a UK
> preserved railway. The system needs to be as near to totally platform
> independent as possible. As I see it, this rules out use of package
> Calendar.
>
> Rather than re-invent a wheel, I would prefer to use a pre-existing
> solution and would be grateful for suggestions.
> --
> Mike Hopkins

hm

really curious why you would think Calendar package is ruled out?
regards, srini

Re: Platform independent calendar

[Mike H]

In message 
<d26ba59d-734a-48dd-b984-48b7fd70edc8@w35g2000yqm.googlegroups.com>, 
"RasikaSrinivasan@gmail.com" <RasikaSrinivasan@gmail.com> writes
>really curious why you would think Calendar package is ruled out?
>regards, srini

It will be a pair of embedded micro-controllers communicating with each 
other on a peer to peer basis with logging, archiving and control on a 
PC. Date-stamps on records produced by one machine need to be 
interpreted on another. That means a confirmed mix of hardware and a 
possible mix of Ada compilers. They must be programmed in Ada for two 
reasons. Firstly, I know no other language and secondly the finished 
product will be subject to scrutiny by the UK railway inspectorate. In 
such circumstances platform independence would seem to be a convenient 
road to go down.

Having come out of retirement at the age of 75 I admit to the 
possibility of being out of touch. So if you would like to try to 
persuade me otherwise, I shall be happy to listen.
-- 
Mike Hopkins
Project Rheilffordd Eryri
WHR <http://www.welshhighlandrailway.net/>

Re: Platform independent calendar

[Gene]

On Dec 7, 12:40 pm, Mike H <newsrea...@ada-
augusta.demon.co.uk.INVALID> wrote:
> In message
> <d26ba59d-734a-48dd-b984-48b7fd70e...@w35g2000yqm.googlegroups.com>,
> "RasikaSriniva...@gmail.com" <RasikaSriniva...@gmail.com> writes
>
> >really curious why you would think Calendar package is ruled out?
> >regards, srini
>
> It will be a pair of embedded micro-controllers communicating with each
> other on a peer to peer basis with logging, archiving and control on a
> PC. Date-stamps on records produced by one machine need to be
> interpreted on another. That means a confirmed mix of hardware and a
> possible mix of Ada compilers. They must be programmed in Ada for two
> reasons. Firstly, I know no other language and secondly the finished
> product will be subject to scrutiny by the UK railway inspectorate. In
> such circumstances platform independence would seem to be a convenient
> road to go down.
>
> Having come out of retirement at the age of 75 I admit to the
> possibility of being out of touch. So if you would like to try to
> persuade me otherwise, I shall be happy to listen.

Just in case you're unfamiliar, you'll probably want to check out
global clock/timestamp sychronization/ algorithms.  There are many
references, for example http://portal.acm.org/citation.cfm?id=305619.305631

Re: Platform independent calendar

[Per Sandberg]

????
The Calendar package is the same all known platform as far as i know 
since that is defined by the standard.
But if you by platform independent mean using the same binary 
representation for data (to be sent between machines) which is a 
complete different story.
I would use XML as data carrier and use some platform independent middle 
ware for transmitting data.

/Per



Mike H wrote:
> I am working (solo) on a signalling related application for a UK 
> preserved railway. The system needs to be as near to totally platform 
> independent as possible. As I see it, this rules out use of package 
> Calendar.
> 
> Rather than re-invent a wheel, I would prefer to use a pre-existing 
> solution and would be grateful for suggestions.

Re: Platform independent calendar

[sjw]

On Dec 7, 5:14 pm, Per Sandberg <per.sandb...@bredband.net> wrote:
> ????
> The Calendar package is the same all known platform as far as i know
> since that is defined by the standard.
> But if you by platform independent mean using the same binary
> representation for data (to be sent between machines) which is a
> complete different story.
> I would use XML as data carrier and use some platform independent middle
> ware for transmitting data.

Sounds as though you'll need a mechanism so that all the computers
involved agree what the time is.

We used (S)NTP (broadcast, though that's not necessary) and a package
modelled on Ada.Calendar, where the underlying time is the particular
computer's Ada.Calendar.Clock but there's a private offset which
brings the time from/to the common system time whenever a time value
goes on/off board. Update the offset on receipt of (S)NTP update. Does
depend on UDP networking, of course. See
https://sourceforge.net/project/showfiles.php?group_id=135558&package_id=168849
for an Ada implementation of SNTP - uses GNAT.Sockets

Re: Platform independent calendar

[Dmitry A. Kazakov]

On Sun, 7 Dec 2008 15:43:49 +0000, Mike H wrote:

> I am working (solo) on a signalling related application for a UK 
> preserved railway. The system needs to be as near to totally platform 
> independent as possible. As I see it, this rules out use of package 
> Calendar.
> 
> Rather than re-invent a wheel, I would prefer to use a pre-existing 
> solution and would be grateful for suggestions.

Oh,well. This is a huge issue. We are developing a portable middleware in
Ada 2005 with the heterogeneous nodes synchronized over the network. For
that we need UTC time stamps.

Our investigation has shown that presently there is no way to make it. To
start with, Ada.Calendar is obviously unusable. You should always use
Ada.Real_Time. With the latter you should take care of clock resolution, it
is quite possible that it turns miserable, and you will need to attune the
OS and/or replace the standard Ada library, as we did. For each platform
write a clock test. Note that your workaround will likely depend on the
processor family. We must have written replacements for Pentium IV and PPC.
Further, Ada.Calendar.Time_Zones is ill-specified and thus unusable as
well. I posted a proposal to fix it to Ada comments, but for now you have
no better choice than to look into the implementation your compiler
provides and then to act accordingly.

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

Re: Platform independent calendar

[Maciej Sobczak]

On 7 Gru, 20:15, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> We are developing a portable middleware in
> Ada 2005 with the heterogeneous nodes synchronized over the network.

Not related to the original question, but I would like to ask.
Why do you want to synchronize the nodes over the network?

What is wrong with existing solutions for clock synchronization (NTP)?

> For
> that we need UTC time stamps.

Why?

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Database Access Library for Ada: www.inspirel.com/soci-ada

Re: Platform independent calendar

[Dmitry A. Kazakov]

On Sun, 7 Dec 2008 14:26:36 -0800 (PST), Maciej Sobczak wrote:

> On 7 Gru, 20:15, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>> We are developing a portable middleware in
>> Ada 2005 with the heterogeneous nodes synchronized over the network.
> 
> Not related to the original question, but I would like to ask.
> Why do you want to synchronize the nodes over the network?

Have you radio or GPS clock in mind? This is not always an option for our
customers, or rather, always not an option. (:-))

> What is wrong with existing solutions for clock synchronization (NTP)?

Nothing wrong, the design provides a possibility to use a physical clock
synchronization, like NTP or radio clock does. But normally we don't touch
the clocks, we translate the time stamps instead.

>> For that we need UTC time stamps.
> 
> Why?

Because we distribute time-stamped data...

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

Re: Platform independent calendar

[Jeffrey R. Carter]

Mike H wrote:
> I am working (solo) on a signalling related application for a UK 
> preserved railway. The system needs to be as near to totally platform 
> independent as possible. As I see it, this rules out use of package 
> Calendar.
> 
> Rather than re-invent a wheel, I would prefer to use a pre-existing 
> solution and would be grateful for suggestions.

You should probably use Ada.Real_Time rather than Ada.Calendar for such an 
application.

If your platform independence requires passing values between heterogeneous 
processors or code from different compilers, I'd suggest you use a 
platform-independent representation, such as text.

-- 
Jeff Carter
"I'm a kike, a yid, a heebie, a hook nose! I'm Kosher,
Mum! I'm a Red Sea pedestrian, and proud of it!"
Monty Python's Life of Brian
77

Re: Platform independent calendar

[Mike H]

In message <5pZ_k.470338$yE1.89079@attbi_s21>, Jeffrey R. Carter 
<spam.jrcarter.not@spam.acm.org> writes
>You should probably use Ada.Real_Time rather than Ada.Calendar for such 
>an application.
Over ten years away from Ada and still using Barnes 9X for reference, I 
am clearly well out of touch! Where is a spec. of Ada.Real_Time?

-- 
Mike Hopkins
Project Rheilffordd Eryri
WHR <http://www.welshhighlandrailway.net/>

Re: Platform independent calendar

[Jeffrey R. Carter]

Mike H wrote:
> Over ten years away from Ada and still using Barnes 9X for reference, I 
> am clearly well out of touch! Where is a spec. of Ada.Real_Time?

http://www.adaic.org/standards/05rm/html/RM-D-8.html

Also exists in Ada 95.

-- 
Jeff Carter
"I'm a kike, a yid, a heebie, a hook nose! I'm Kosher,
Mum! I'm a Red Sea pedestrian, and proud of it!"
Monty Python's Life of Brian
77

Re: Platform independent calendar

[Mike H]

In message <Ig%_k.470467$yE1.1151@attbi_s21>, Jeffrey R. Carter 
<spam.jrcarter.not@spam.acm.org> writes
>http://www.adaic.org/standards/05rm/html/RM-D-8.html
>
>Also exists in Ada 95.
>
Many thanks for a pointer to an up to date LRM.

I am coming to the conclusion that we do not have a real problem. In 
this application the need for time-stamping is related to logging data 
and any granularity of time much less than 100 milliseconds is probably 
overkill.
-- 
Mike Hopkins
CSME <http://www.cheltsme.org.uk>
5" gauge (2 1/2" scale) Alice class Hunslet

Re: Platform independent calendar

[sjw]

On Dec 7, 11:56 pm, "Jeffrey R. Carter"
<spam.jrcarter....@spam.acm.org> wrote:
> Mike H wrote:
> > I am working (solo) on a signalling related application for a UK
> > preserved railway. The system needs to be as near to totally platform
> > independent as possible. As I see it, this rules out use of package
> > Calendar.
>
> > Rather than re-invent a wheel, I would prefer to use a pre-existing
> > solution and would be grateful for suggestions.
>
> You should probably use Ada.Real_Time rather than Ada.Calendar for such an
> application.

At least Ada.Calendar refers to externally-visible time (even though
there may be problems related to eg time zones which are not likely to
be a bother in Mike's application).

I would have thought Real_Time had even less applicability in a
distributed system than Calendar. Real_Time doesn't refer to real time
such as you might read on your watch, it's related to hard real time
control systems; are your signal requirements like that?

In (older?) GNATs, Real_Time and Calendar were the same, I think this
may have changed now (hope so, cos it meant that Real_Time might not
be monotonic).

If you never let the OS change its time sync, Calendar would do just
fine.

Re: Platform independent calendar

[Dmitry A. Kazakov]

On Sun, 07 Dec 2008 23:56:49 GMT, Jeffrey R. Carter wrote:

> If your platform independence requires passing values between heterogeneous 
> processors or code from different compilers, I'd suggest you use a 
> platform-independent representation, such as text.

For absolute UTC we are using FILETIME. It is has the precision of 100ns
and a sufficient range (it is 64 bit). But we do not propagate absolute
time stamps most of the time. Usually we do only the increments packed in
chain code (also variable length). That sufficiently reduces the network
traffic. (We need to be fast in order of tens of microseconds.)

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