pc386 BSP uses slow hardware for nanoseconds time granularity

[Joel Sherrill]

OK, I've got it done. Instead of using HPET chips (I don't have ready
access to such a motherboard), I used the TSC register available on
Pentium-class CPUs. There are some pluses and minuses to that; high
precision, _if_ the BIOS doesn't alter the clock frequency for thermal
or power saving reasons.

Anyway, it's all attached for your perusal.

Summary of results:
Six varieties of code tested:

1) Unmodified ckinit.c

2) Un-modified ckinit.c, configured with
USE_TICKS_FOR_CPU_USAGE_STATISTICS=1

3) Just commented out I/O

4) Re-worked ckinit.c, with new switch CLOCK_DRIVER_USE_TSC = 1.

It uses the TSC register on Pentium-class processors.

5) Re-worked ckinit.c, with new switch CLOCK_DRIVER_USE_8529 = 1.

Equivalent to unmodified ckinit.c.

6) Re-worked ckinit.c, with neither ..._USE_TSC nor ..._USE_8529

defined. Equivalent to (3).

Test box is a 500 MHz AMD K6-2.

Context switches nSec per switch
per tick (1 KHz)

(1) 153 6,525
(2) 1,582 632
(3) 1,025 976
(4) 939 1,065
(5) 153 6,524
(6) 1,117 895

On Wed, 2008-11-19 at 08:42 -0600, Joel Sherrill wrote:

Michael South wrote:

Getting really bad context switch times on pc386 when
RTEMS_ENABLE_NANOSECOND_CPU_USAGE_STATISTICS is enabled. (Something
like a factor of ten on one of my desktops). I posted a discussion note
on the 4.9.0 release Wiki page.

I just saw the talk page this morning. Can you try a few
things and let's see where that takes us.

+ Send me your test program so I can check it on other

targets.

+ Temporarily change bsp_clock_nanoseconds_since_last_tick()

in /c/src/lib/libbsp/i386/pc386/clock/ckinit.c to return 0 and
not touch the hardware. Rerun and report results.

+ If above shows problem, provide alternative code that uses

the method you mention in the Wiki Talk page.

+ If we can't dynamically figure out if the alternative method

works, then we can make it a BSP configure time option
like using COM1 as console (see configure.ac in the pc386
directory). If you can provide the code, I can fix the configure.ac
if this turns out to be needed.

I have had concerns that the timespec math is expensive but
never thought that slow clock hardware would be an issue.

--
Michael South msouth@…
_
rtems-users mailing list
rtems-users@…
​http://rtems.rtems.org/mailman/listinfo/rtems-users

[Joel Sherrill]

Michael's Patch Kit and Test Program

[Joel Sherrill]

Updated version of patch

[Joel Sherrill]

correction to be laid on top of previous patch

[strauman]

More bugs need to be fixed, unfortunately. To be applied after previous patches.

[Joel Sherrill]

Closing.