Perhaps a time correction through an NTP daeomon or the like?

Ken

P.S. Of course that only makes sense if the clock used is the actual
time and not something like a clock time independent value like
milliseconds since program start.  Maybe.  I'm not sure how that is
calculated either, truth be told.

On Tue, 2007-01-23 at 20:43 +0100, Bert Freudenberg wrote:
> ... that it finishes before it even started.
> 
> I just ran Croquet's tests on a MacBook Pro with Ubuntu Linux in the  
> Parallels PC emulator:
> 
> 	CroquetVMTests new quickLatencyTest
> 
> results in
> 
> 	#(2.451390797266446e6 1073741822 0.023 3)
> 
> which is a test failure. The first value is supposed to be the  
> average number of milliseconds for a local network roundtrip, the  
> second the maximum. Strange values. Looking at the actual test runs,  
> here are the results sorted by occurrence, values in hex:
> 
>   a SortedCollection(63481->'16r0' 4374->'16r1' 131->'16r2' 61- 
>  >'16r3FFFFFFE' 45->'16r3FFFFFFD' 44->'16r3' 29->'16r4' 20- 
>  >'16r3FFFFFFC' 10->'16r7' 3->'16r6' 3->'16r5' 2->'16r8' 1- 
>  >'16r3FFFFFFB')
> 
> The method to measure the runtime is [...] timeToRun. How could that  
> possibly answer a negative amount?! Only if the millisecond clock  
> turns backwards. The new Apple machines indeed are very fast, but  
> *that* fast?
> 
> - Bert -
> 
> 
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20070123/801cfeb9/attachment.pgp