Clock Tick Rollover

[lichla]

I have an application which uses the clock tick to measure time intervals.
Say A=clock( ) and B=clock ( ). Later on I get a latency measurement of
B-A=latency.
This operation has been working flawlessly until it reached about 47 days
from the begining of the process. I know the clock is suposed to roll back to 0 after about 49.7 days…(2^32) and I know I can get a negative number for latency when this occurs only once.
The problem is I can tell the latency measurement is no longer working because of some data files we log. The program does not crash. All variables used are unsigned long. The computer is in a remote location
and I can’t wait 49.7 days in the test lab for this to occur. Does anyone have an idea what is happening?
I would think the clock( ) tick would just go back to 0 and count up again but it appears this is not happenning.

[rgallen]

@lichla

I have an application which uses the clock tick to measure time intervals.
Say A=clock( ) and B=clock ( ). Later on I get a latency measurement of
B-A=latency.
This operation has been working flawlessly until it reached about 47 days
from the begining of the process. I know the clock is suposed to roll back to 0 after about 49.7 days…(2^32) and I know I can get a negative number for latency when this occurs only once.

From the QNX docs for clock():

“The clock() function simply returns the difference between the current
time and the time the program started, so it gives incorrect results if
the system time changes somewhere between.”

Therefore, once 49.7 days has elapsed, clock() is useless (i.e. “current time” - “time process started” > uint32_t).

The problem is I can tell the latency measurement is no longer working because of some data files we log. The program does not crash. All variables used are unsigned long. The computer is in a remote location
and I can’t wait 49.7 days in the test lab for this to occur. Does anyone have an idea what is happening?
I would think the clock( ) tick would just go back to 0 and count up again but it appears this is not happenning.

Simple solution: use ClockTime(). It measures nanoseconds in a 64 bit number, and therefore won’t rollover for 584 years.

[lichla]

Thanks so much for your explanation.
I will try your suggestion.

[lichla]

Actually I don’t see clockTime() available for QNX4. I am not so concerned about the correct time but the measurement interval which ranges from 70 ms to 800ms. Is it correct to say Clock() will not rollover back to 0 once it has reached its maximum value?

[rgallen]

@lichla

Actually I don’t see clockTime() available for QNX4. I am not so concerned about the correct time but the measurement interval which ranges from 70 ms to 800ms. Is it correct to say Clock() will not rollover back to 0 once it has reached its maximum value?

Ahhh, you didn’t mention you were using QNX4. QNX4 does not have ClockTime().

For your requirements, write a small process that creates a repetitive timer (say 1 ms) and have your process perform a receive. When it receives a pulse it increments a counter by one (and handles rollover when the counter goes over UINT_MAX) and when it receives a message (from one of your processes) it replies with this counter. This achieves the same effect as CLOCK_MONOTONIC in QNX6.

You still have to handle rollover (since there are no 64 bit ints in Watcom) but it won’t suffer from the problems of clock().

[lichla]

Thanks again !

[rgallen]

@lichla

Thanks again !

Oh, and I forgot to mention, you can supply an argument to this small program when you start it, to set the counter to a value other than 0. This will enable you to test that rollover is being handled correctly without waiting 49.7 days…

Rennie