[lkml]   [2002]   [Jun]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: gettimeofday problem
On 2000000 call -> 189 times I found the problem (0.00945%)
On 20000000 call ->1956 found I found the problem (0.00978%)

Probably you're right my previous percentage is too high (the one above
should be the correct one).

But do you think that this behaviour is normal?

Matti Aarnio wrote:

>On Mon, Jun 24, 2002 at 12:20:02PM +0200, Salvatore D'Angelo wrote:
>>In this piece of code I convert seconds and microseconds in
>>milliseconds. I think the problem is not in my code, in fact I wrote the
>>following piece of code in Java, and it does not work too. In the for
>>loop the 90% of times b > a while for 10% of times not.
>> long a = System.currentTimeMillis();
>> long b = System.currentTimeMillis();
>> if (a > b) {
>> System.out.println("Wrong!!!!!!!!!!!!!");
>> }
> So in 10% of the cases, two successive calls yield time
> rolling BACK ?
> I used gettimeofday() call, and compared the original data
> from the code.
> At a modern uniprocessor machine I never get anything except
> monotonously increasing time (TSC is used in betwen timer ticks
> to supply time increase.) At a dual processor machine, on
> occasion I do get SAME value twice. I have never seen time
> rolling backwards.
> Uh.. correction: 216199245 0:-1 -- it did step backwards,
> but only once within about 216 million gettimeofday() calls.
> (I am running 2.4.19-pre8smp at the test box.)
>/Matti Aarnio
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to
>More majordomo info at
>Please read the FAQ at

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:27    [W:0.079 / U:9.024 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site