[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Some thing wrong in gettimeofday() ?



Hi,

There is (was) a bug in the gettimeofday() implementation
where it didn't detect underflow of the timer correctly
causing the time to go backwords etc.
This is fixed in our CVS some time ago, but I'm not sure 
if it's in the version on the developer web yet.

What version of the kernel did you use?
(cat /proc/version )

BTW: I have also improved the timing resolution
so you can get 67 ns resolution within a "jiffie" 
and thus get 1us resolution (instead of 52 us) 
in the gettimeofday() call.
The smallest time between gettimeofday() calls 
I have seen with my solution is 4 us.
Not checked in yet though...

/Johan


----- Original Message ----- 
From: Nguyen Thai <thai@xxxxxxx.se>
To: Jonas Holmberg <jonashg@xxxxxxx.com>
Sent: Tuesday, January 08, 2002 14:56
Subject: Some thing wrong in gettimeofday() ?


> Hi,
> 
> I have got an unknown error in gettimeofday, some time it gives incorect
> time. I made a test program like this: put the difference between current
> gettimeofday and a start value of gettimeofday into an array with increase
> index. That means when index of the array increasing, the time value should
> increase too. But some time, it didn't show that. Here are results in
> different runs:
> 
> [root@xxxxxxx./test
> Time cost for 10000 calls to gettimeofday: 131042; average: 13.104200
> 
>  Going to check results:
> Error 1 : traces[9276].time 121771, traces[9277].time 22481444,
> traces[9278].time 121979
> Number of errors: 1, minimum interval: 52, maximum interval: 625
> [root@xxxxxxx./test
> Time cost for 10000 calls to gettimeofday: 131093; average: 13.109300
> 
>  Going to check results:
> Number of errors: 0, minimum interval: 52, maximum interval: 521
> [root@xxxxxxx./test
> Time cost for 10000 calls to gettimeofday: 131198; average: 13.119800
> 
>  Going to check results:
> Error 1 : traces[7344].time 96771, traces[7345].time 22456444,
> traces[7346].time 96979
> Error 2 : traces[8099].time 106771, traces[8100].time 22466444,
> traces[8101].time 106927
> Error 3 : traces[8861].time 116771, traces[8862].time 22476444,
> traces[8863].time 116927
> Number of errors: 3, minimum interval: 52, maximum interval: 521
> [root@xxxxxxx./test
> Time cost for 10000 calls to gettimeofday: 131094; average: 13.109400
> 
>  Going to check results:
> Error 1 : traces[5492].time 72344, traces[5493].time 22432017,
> traces[5494].time 72500
> Error 2 : traces[8548].time 112344, traces[8549].time 22472017,
> traces[8550].time 112500
> Number of errors: 2, minimum interval: 52, maximum interval: 521
> [root@xxxxxxx./test
> Time cost for 10000 calls to gettimeofday: 131719; average: 13.171900
> 
>  Going to check results:
> Error 1 : traces[2343].time 30573, traces[2344].time 22390246,
> traces[2345].time 30729
> Number of errors: 1, minimum interval: 52, maximum interval: 729
> [root@Axis2 /var/tmp]52#
> 
> I was compile using gcc-cris:
> $ gcc-cris -v
> Reading specs from /usr/local/cris/lib/gcc-lib/cris/2.96/specs
> gcc version 2.96 20000427 (experimental)
> 
> And the program was running on LX developer board:
> thai@ash:~/axis/devboard_lx/apps/test$ gcc-cris -v
> Reading specs from /usr/local/cris/lib/gcc-lib/cris/2.96/specs
> gcc version 2.96 20000427 (experimental)
> 
> Is there any other way to get relative time which more accuracy?
> 
> Source file of the test is included in the attachment.
> 
> Best regards
> 
> Nguyen Thai
>