Opened on Dec 1, 2008 at 5:10:59 PM
Closed on Aug 6, 2010 at 9:31:09 PM
Last modified on Aug 6, 2010 at 9:36:40 PM
#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)
Change History (7)
Changed on Dec 1, 2008 at 5:10:59 PM by Joel Sherrill
Attachment: | clockpatch.tgz added |
---|
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
correction to be laid on top of previous patch
Changed on Sep 15, 2009 at 10:52:59 PM by strauman
Attachment: | rtems-PR#1344-x86-nsclock-p4.diff added |
---|
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: | new → closed |
Michael's Patch Kit and Test Program