Re: gettimeofday problem

[Salvatore D'Angelo]

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