Linux: My computer is so fast ...

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

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

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

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

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

> Bert Freudenberg says:
>
>> 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.
>
> Ok, this is just a theory, but if I remember correctly,
> Parallels does not (yet) support video acceleration.  Therefore
> I question whether an OpenGL program would work well (or at all)
> under Parallels, especially if the software more or less
> insists that the accelerator hardware be there.
>
> I may be wrong here but...

> Bert Freudenberg says:
>
>> 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.
>
> Ok, this is just a theory, but if I remember correctly,
> Parallels does not (yet) support video acceleration.  Therefore
> I question whether an OpenGL program would work well (or at all)
> under Parallels, especially if the software more or less
> insists that the accelerator hardware be there.
>
> I may be wrong here but...