[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
|