Odd behaviour of System.Environment.TickCount

  • Thread starter Thread starter Steve Wilkinson
  • Start date Start date
S

Steve Wilkinson

We are currently running the Compact Framework V1 on a
CE.NET 4.2 platform. The platform has all of the latest
QFE's applied.

We have noticed odd behaviour with
System.Environment.TickCount. We have a thread which
loops continuously, sleeping for 100ms on every
itteration of the loop. Inside this loop
System.Environment.TickCount is called and its value is
recorded. Normally we see the tick count value
incrementing by approximately 100 on each pass, however
at random intervals the tick count value increments by a
massive amount. We have left this routine on soak test
over night and have found that the tick count value will
generally jump 3 times during the night. The amount of
the jump is equivalent to about 19 minutes of time.

According to the CE.NET API, the GetTickCount() function
which I presume System.Environment.Tick wraps, will
eventually rollover approximatly once every 24 days.
However the values we are getting are nowhere near the
uint limit.

What is going on here ?

Regards

Steve
 
A couple of things to check:

1. Are you calling Sleep( 100 ) *exactly* or might you be calculating how
long to sleep? If you are calculating, maybe you have a bug there.

2. Do you have a C program that shows the same problem or is C 100%
reliable. This will tell us where to look. I'm guessing that C does the
same thing and theres a bug in your kernel code, but it could be a .NET CF
problem.

Paul T.
 
Paul,

I'm calling Sleep with a fixed value.

I'll knock up a quick C/C++ test app and call the
GetTickCount() API function.

I'll also P/Invoke the same function, just to see if I
get the same behaviour.

Thanks

Steve
 
That should point out the culprit...

Paul T.

Steve Wilkinson said:
Paul,

I'm calling Sleep with a fixed value.

I'll knock up a quick C/C++ test app and call the
GetTickCount() API function.

I'll also P/Invoke the same function, just to see if I
get the same behaviour.

Thanks

Steve
 
The kernel code is probably not correctly dealing with the OSCR register
wrap of the processor. Due to the frequency of that tick, it wraps about
every 19 minutes.
 
Back
Top