We are using the clock() function for the measurement of small time
differences. Unfortunately the value of clock() stops after 49 days with the
value 0xFFFFFFFF and does not turn around as we expected.
Since our software runs more likely 49 weeks rather than 49 days, we’re
looking for any alternatives that do not have such restrictions.
| STN ATLAS Marine Electronics GmbH
| Dipl.-Ing. Heinz-Dieter Sander
| Software Navigation Systems, Dept. MST 21
| Kurfuerstenallee 130
| D-28211 Bremen, Germany
|
| Phone : +49 421 457 3511
| Fax : +49 421 457 2026
| eMail : Heinz-Dieter.Sander@sam-electronics.de
Heinz-Dieter Sander <HDSander@is-bremen.de> wrote:
: We are using the clock() function for the measurement of small time
: differences. Unfortunately the value of clock() stops after 49 days with the
: value 0xFFFFFFFF and does not turn around as we expected.
: Since our software runs more likely 49 weeks rather than 49 days, we’re
: looking for any alternatives that do not have such restrictions.
You’ve reached the maximum number of ticks that can fit in a clock_t,
so the function returns -1.
Note: The number of ticks used to “roll over” when it reached the maximum
(approximately every 49 days, as you’ve found), but this was a coding
error that has been fixed.
Steve McPolin once described clock() as brain-dead; you’re better off
using times() instead.
Steve Reid stever@qnx.com
TechPubs (Technical Publications)
QNX Software Systems
I like to use the non-portable solution:
struct _timesel volatile far *tp = 0;
struct _osinfo info;
if ( qnx_osinfo( 0, &info ) == -1 ) {
return -1;
}
tp = (struct _timesel volatile far *) MK_FP( info.timesel, 0);
And you can now read time through tp->nsec and tp->seconds ;
I prefer this solution to clock() or time() as there is not kernel call
involved!
“Steve Reid” <stever@qnx.com> wrote in message
news:908bpr$q4l$1@nntp.qnx.com…
Heinz-Dieter Sander <> HDSander@is-bremen.de> > wrote:
: We are using the clock() function for the measurement of small time
: differences. Unfortunately the value of clock() stops after 49 days with
the
: value 0xFFFFFFFF and does not turn around as we expected.
: Since our software runs more likely 49 weeks rather than 49 days, we’re
: looking for any alternatives that do not have such restrictions.
You’ve reached the maximum number of ticks that can fit in a clock_t,
so the function returns -1.
Note: The number of ticks used to “roll over” when it reached the maximum
(approximately every 49 days, as you’ve found), but this was a
coding
error that has been fixed.
Steve McPolin once described clock() as brain-dead; you’re better off
using times() instead.
Steve Reid > stever@qnx.com
TechPubs (Technical Publications)
QNX Software Systems
In article <908bpr$q4l$1@nntp.qnx.com>, stever@qnx.com says…
Heinz-Dieter Sander <> HDSander@is-bremen.de> > wrote:
: We are using the clock() function for the measurement of small time
: differences. Unfortunately the value of clock() stops after 49 days with the
: value 0xFFFFFFFF and does not turn around as we expected.
: Since our software runs more likely 49 weeks rather than 49 days, we’re
: looking for any alternatives that do not have such restrictions.
You’ve reached the maximum number of ticks that can fit in a clock_t,
so the function returns -1.
Note: The number of ticks used to “roll over” when it reached the maximum
(approximately every 49 days, as you’ve found), but this was a coding
error that has been fixed.
Steve McPolin once described clock() as brain-dead; you’re better off
using times() instead.
Sorry to hear of Steve’s departure; I always enjoyed his droll remarks. BTW:
who owns Proc now?
Steve Reid > stever@qnx.com
TechPubs (Technical Publications)
QNX Software Systems
“Dean Douthat” <ddouthat@faac.com> wrote in message
news:908rcu$bim$1@inn.qnx.com…
In article <908bpr$q4l$> 1@nntp.qnx.com> >, > stever@qnx.com > says…
Heinz-Dieter Sander <> HDSander@is-bremen.de> > wrote:
: We are using the clock() function for the measurement of small time
: differences. Unfortunately the value of clock() stops after 49 days
with the
: value 0xFFFFFFFF and does not turn around as we expected.
: Since our software runs more likely 49 weeks rather than 49 days, we’re
: looking for any alternatives that do not have such restrictions.
You’ve reached the maximum number of ticks that can fit in a clock_t,
so the function returns -1.
Note: The number of ticks used to “roll over” when it reached the maximum
(approximately every 49 days, as you’ve found), but this was a
coding
error that has been fixed.
Steve McPolin once described clock() as brain-dead; you’re better off
using times() instead.
Steve hasn’t been working for QSSL for over a 1.5 year now.
All parties involved wanted to keep it quiet reduce the commotion,
for obvious reason. But as Delahipetelama would say
“cimitary are full of irreplaceble people” 
Sorry to hear of Steve’s departure; I always enjoyed his droll remarks.
BTW:
who owns Proc now?
\
Steve Reid > stever@qnx.com
TechPubs (Technical Publications)
QNX Software Systems
Previously, Steve Reid wrote in qdn.public.qnx4:
Heinz-Dieter Sander <> HDSander@is-bremen.de> > wrote:
: We are using the clock() function for the measurement of small time
: differences. Unfortunately the value of clock() stops after 49 days with the
: value 0xFFFFFFFF and does not turn around as we expected.
: Since our software runs more likely 49 weeks rather than 49 days, we’re
: looking for any alternatives that do not have such restrictions.
You’ve reached the maximum number of ticks that can fit in a clock_t,
so the function returns -1.
Note: The number of ticks used to “roll over” when it reached the maximum
(approximately every 49 days, as you’ve found), but this was a coding
error that has been fixed.
Yikes! I was using clock() for the same reason. I’m glad we haven’t shipped product yet. 
There’s nothing in the online documentation for clock() (or in K&R’s C book, for that matter) that warns of this possibility. It would be really helpful if any future revs of the online docs contained a warning about this…
Pete DiMarco <peted.NOSPAM@nospam.ifsreg.com> wrote:
: Yikes! I was using clock() for the same reason. I’m glad we haven’t shipped product yet.
: There’s nothing in the online documentation for clock() (or in K&R’s C book, for that matter) that warns of this possibility. It would be really helpful if any future revs of the online docs contained a warning about this…
Already done here, but I don’t know when an update to the docs was last
released. It could be a nasty surprise.
Steve Reid stever@qnx.com
TechPubs (Technical Publications)
QNX Software Systems
Mario Charest wrote:
I like to use the non-portable solution:
struct _timesel volatile far *tp = 0;
struct _osinfo info;
if ( qnx_osinfo( 0, &info ) == -1 ) {
return -1;
}
tp = (struct _timesel volatile far *) MK_FP( info.timesel, 0);
And you can now read time through tp->nsec and tp->seconds ;
I prefer this solution to clock() or time() as there is not kernel call
involved!
You could be in for a nasty surprise if you don’t have a way (=kernel
call) to read the
two values atomically, causing you perceived time to be off by a second!
(Imagine tp->nsec overflows to tp->seconds in the (short) window between
the reading of the values)!
My preferred clock() replacement (which does indeed overflow as most of
us have expected - yes, I’ve been burnt by the 2^32-1 ms limit, too)
follows
Caveat: This version does NOT start at 0 at task start)
#include <time.h>
clock_t clock()
{
timespec tp;
if ( clock_gettime( CLOCK_REALTIME, &tp ) < 0 )
return ~0;
return tp.tv_sec * 1000 + tp.tv_nsec / 1000000;
}
cheers
Anders Larsen
–
Windoze is a 24x7 system – up for 24 days, 7 hours per day
“Anders Larsen” <nospam@invalid.nil> wrote in message
news:3A282B5A.CAA00CFA@alarsen.net…
Mario Charest wrote:
I like to use the non-portable solution:
struct _timesel volatile far *tp = 0;
struct _osinfo info;
if ( qnx_osinfo( 0, &info ) == -1 ) {
return -1;
}
tp = (struct _timesel volatile far *) MK_FP( info.timesel, 0);
And you can now read time through tp->nsec and tp->seconds ;
I prefer this solution to clock() or time() as there is not kernel call
involved!
You could be in for a nasty surprise if you don’t have a way (=kernel
call) to read the
two values atomically, causing you perceived time to be off by a second!
This has been discussed earlier (I took it for granted that everyone whould
remember or have read it, sorry ) you just have to read the values in a
while
loop until they are equal.
(Imagine tp->nsec overflows to tp->seconds in the (short) window between
the reading of the values)!
My preferred clock() replacement (which does indeed overflow as most of
us have expected - yes, I’ve been burnt by the 2^32-1 ms limit, too)
follows
Caveat: This version does NOT start at 0 at task start)
#include <time.h
clock_t clock()
{
timespec tp;
if ( clock_gettime( CLOCK_REALTIME, &tp ) < 0 )
return ~0;
return tp.tv_sec * 1000 + tp.tv_nsec / 1000000;
}
cheers
Anders Larsen
–
Windoze is a 24x7 system – up for 24 days, 7 hours per day
Is this sol’n affected by time changes via the date utility?
I just wrote a small test program and on 4.24 (didn’t feel like rebooting
in 4.25) the value is affected.
“Brown, Richard” <brownr@aecl.ca> wrote in message
news:90g0mp$jqp$1@inn.qnx.com…
Is this sol’n affected by time changes via the date utility?
Is there any way to get notified when a time change has occurred so that one
could compensate?
“Mario Charest” <mcharest@void_zinformatic.com> wrote in message
news:90g657$dni$1@nntp.qnx.com…>
I just wrote a small test program and on 4.24 (didn’t feel like rebooting
in 4.25) the value is affected.
“Brown, Richard” <> brownr@aecl.ca> > wrote in message
news:90g0mp$jqp$> 1@inn.qnx.com> …
Is this sol’n affected by time changes via the date utility?
Thanks for the heads up.
I don’t remember seeing the original thread, and if I hadn’t seen this, our
customers would have started to see intermittent problems after running for
several weeks.
I’m also glad we haven’t started shipping yet.
Pete DiMarco <peted.NOSPAM@NOSPAM.ifsreg.com> wrote in message
news:Voyager.001201131829.401A@node1…
Previously, Steve Reid wrote in qdn.public.qnx4:
Heinz-Dieter Sander <> HDSander@is-bremen.de> > wrote:
: We are using the clock() function for the measurement of small time
: differences. Unfortunately the value of clock() stops after 49 days
with the
: value 0xFFFFFFFF and does not turn around as we expected.
: Since our software runs more likely 49 weeks rather than 49 days,
we’re
: looking for any alternatives that do not have such restrictions.
You’ve reached the maximum number of ticks that can fit in a clock_t,
so the function returns -1.
Note: The number of ticks used to “roll over” when it reached the
maximum
(approximately every 49 days, as you’ve found), but this was a
coding
error that has been fixed.
Yikes! I was using clock() for the same reason. I’m glad we haven’t
shipped product yet. >
There’s nothing in the online documentation for clock() (or in K&R’s C
book, for that matter) that warns of this possibility. It would be really
helpful if any future revs of the online docs contained a warning about
this…
No that I’m aware of, you would probably have to
do it yourself.
“Brown, Richard” <brownr@aecl.ca> wrote in message
news:90g8fc$nvj$1@inn.qnx.com…
Is there any way to get notified when a time change has occurred so that
one
could compensate?
“Mario Charest” <mcharest@void_zinformatic.com> wrote in message
news:90g657$dni$> 1@nntp.qnx.com> …
I just wrote a small test program and on 4.24 (didn’t feel like
rebooting
in 4.25) the value is affected.
“Brown, Richard” <> brownr@aecl.ca> > wrote in message
news:90g0mp$jqp$> 1@inn.qnx.com> …
Is this sol’n affected by time changes via the date utility?