Well, that wouldn't turn back the clock a hundred times in 5 seconds,
would it?
But something is causing it. I logged the value of "Time
millisecondClockValue" in a process parallel to the latency test. It
frequently jumps back one or two milliseconds. It is *not* jumping
back if instead of running the socket I/O tests, I just calculate
something for five seconds.
This sounds very much like a VM problem, I'm taking this to the VM-
Dev list. Reply-To set.
- Bert -
Am Jan 23, 2007 um 21:41 schrieb Ken Causey:
> 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 -
>>
>>
>>
>>
Locked
