#1344 closed defect (fixed)

pc386 BSP uses slow hardware for nanoseconds time granularity

Reported by: Joel Sherrill Owned by: Joel Sherrill
Priority: normal Milestone: 4.10
Component: bsps Version: 4.10
Severity: normal Keywords:
Cc: strauman@… Blocked By:
Blocking:

Description

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

Attachments (4)

clockpatch.tgz (7.1 KB) - added by Joel Sherrill on Dec 1, 2008 at 5:10:59 PM.
Michael's Patch Kit and Test Program
pr1344-joel-clock.diff (12.4 KB) - added by Joel Sherrill on Dec 3, 2008 at 4:24:28 PM.
Updated version of patch
ck.diff (1.4 KB) - added by Joel Sherrill on Dec 4, 2008 at 4:58:01 PM.
correction to be laid on top of previous patch
rtems-PR#1344-x86-nsclock-p4.diff (2.5 KB) - added by strauman on Sep 15, 2009 at 10:52:59 PM.
More bugs need to be fixed, unfortunately. To be applied after previous patches.

Download all attachments as: .zip

Change History (7)

Changed on Dec 1, 2008 at 5:10:59 PM by Joel Sherrill

Attachment: clockpatch.tgz added

Michael's Patch Kit and Test Program

Changed on Dec 3, 2008 at 4:24:28 PM by Joel Sherrill

Attachment: pr1344-joel-clock.diff added

Updated version of patch

Changed on Dec 4, 2008 at 4:58:01 PM by Joel Sherrill

Attachment: ck.diff added

correction to be laid on top of previous patch

Changed on Sep 15, 2009 at 10:52:59 PM by strauman

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

comment:1 Changed on Sep 15, 2009 at 11:06:01 PM by strauman

Cc: strauman added

comment:2 Changed on Aug 6, 2010 at 9:31:09 PM by Joel Sherrill

Resolution: fixed
Status: newclosed

comment:3 Changed on Aug 6, 2010 at 9:36:40 PM by Joel Sherrill

Closing.

Note: See TracTickets for help on using tickets.