Strange timing results

[Alexandre Constantino]

Thank you for your reply Joel.

I shouldn't have assumed the values were in microseconds, and after
looking at the pc386 timer.c things became clearer.

QEMU has some issues with the clock. On QEMU's forum some people
complained about some OSs running too fast or too slow. And AFAIK there
isn't any way to tune the clock ATM.
One interesting thing with QEMU was that setting a periodic timer to
sleep SEC seconds resulted in a sleep of SEC * 10.
I wrote a simple test that consisted on a sleep of 1 second, 6 times. So
that should take 6 seconds, but instead it took 60 seconds.
(I double checked the time settings, and made it print its sleep time,
to make sure I didn't add an extra zero)
But as to how QEMU works with the TSC register... I don't know either.



On another note it seems that my timings don't scale as they should. I
would assume this to be a consequence of caching and other eventual
features.
After running tmck.exe, 3 times, these were the values I got:
LOOP(        1,000)       9,139
LOOP(       10,000)      80,070
LOOP(      100,000)     900,070
LOOP(    1,000,000)   8,000,075
LOOP(   10,000,000)  80,000,067
LOOP(  100,000,000) 800,000,069
LOOP(1,000,000,000) 410,065,473   <- this one is very strange





Regarding time granularity, what kind of time resolutions should I
expect to obtain on a fast CPU like a 2,4 GHz ?

I ran a test where i had 2 tasks: one task was CPU bounded, the other
had a higher priority and slept for one tick, 1,000,000 times.
Using a tick of 50 microseconds, and a timeslice of 50 ticks (although i
would assume the timeslice to be irrelevant in this case since tasks
have different priorities) the sleeping task was unable to awake in time
on 19 iterations. That is, a fail rate of 0.000019%
I changed the microseconds per tick to 10, the fail rate was about the
same. With 5 microseconds per tick, the system "blocked".

A small resolution like 10 microseconds will inevitable lead to a huge
overhead by dealing with the tick routine... However I was expecting to
achieve some smaller granularity on a fast CPU. Or is this some PIC or
PIT issue?




Once again, thank you very much for your time.

Alexandre Constantino



>Hi,
>
>I've obtained the strangest results on the tmtests (timing tests 
>suites) on an i386 (AMD XP 2,4 GHz) with a pc386 BSP.
>
>For illustrations purposes, take the results for tm01:
>NOTE: all times are in microseconds
>rtems_semaphore_create                   926
>rtems_semaphore_delete                   618
>rtems_semaphore_obtain: available         92
>rtems_semaphore_obtain: not available     92
>rtems_semaphore_release                  180
>
>I have tested tm01 to tm10 and the time disparity is of the same 
>magnitude. I have results from 2x to 15x higher than the ones mentioned

>on the i386.pdf for a 16 Mhz CPU!
>
>  
>
The values reported by the timer driver may or may not be in
microseconds.  On some BSPs they are number of instructions, on others
they are machine cycles.  On the pc386 BSP on a CPU with the TSC
register, it is number of cycles from the TSC register. 

I think that makes the above times VERY VERY small.  I think that means
that the
92 above is about 38 nanoseconds -- assuming I did the math right.

FWIW I don't trust Bochs or qemu yet for timing on the pc386.  I just
don't know how accurate their timing is.  Maybe someone can comment on
this.

>Any clue on what might be wrong?
>Even stranger is the fact that the same executives where tested on 
>bochs
>(*) in the very same computer, and the time results were 4x to 2x 
>smaller than the ones i obtained while running the executives natively.
>(*) with a "tunned" IPS and clock settings - since i was able to get 
>some "close" delay values
>
>
>
>
>Thank you for your time.
>
>Alexandre Constantino
>  
>

--joel