[croquet] Linux: My computer is so fast ...

Bert Freudenberg bert at freudenbergs.de
Tue Jan 23 21:45:16 UTC 2007


Well, I got a request by one desperate Linux user who felt nobody  
from the Croquet community was able to help him get Croquet running  
under Linux. I do not have a real Linux box anymore (well, except for  
the $100-laptop), so I tried to run it in my Parallels install. It  
did not work, the red "connecting" screen does not seem to  finish.  
So I tried running the Croquet unit tests, which worked fine except  
for this strange behaviour.

The clock values are actually fine when not doing I/O, so I still  
suspect the VM to be faulty.

- Bert -

Am Jan 23, 2007 um 22:19  schrieb David P. Reed:

> The Linux SqueakVM may run strangely under parallels - Linux has a  
> complex way of using the various Intel hardware clocks, and the  
> Parallels IntelVM emulates the hardware clocks.   In particular the  
> TSC (high res) clock runs at a rate dependent on the cpu frequency,  
> which changes dynamically under OS X, but that dynamic change  
> cannot easily be detected in a virtualized Intel machine.    
> Wondering why you don't use the OS X vm?
>
> Ken Causey wrote:
>> 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 -



More information about the Squeak-dev mailing list