Re: gettimeofday problem

Salvatore D'Angelo
2002-06-24T13:57:00Z

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 majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>