Changes between Initial Version and Version 1 of Projects/SixtyFourBitTimestamps


Ignore:
Timestamp:
Jan 26, 2010, 3:42:00 AM (12 years ago)
Author:
JoelSherrill
Comment:

New page.

Legend:

Unmodified
Added
Removed
Modified
  • Projects/SixtyFourBitTimestamps

    v1 v1  
     1= SixtyFourBitTimestamps =
     2
     3
     4
     5[[TOC(Projects/SixtyFourBitTimestamps, depth=2)]]
     6
     7
     8'''Status:''' Implemented. Needs evaluation on various architectures.
     9
     10Prior to the RTEMS 4.8 Releases, RTEMS based all timing on clock ticks.
     11At each clock tick, the current time of day was updated.  This meant
     12that the granularity of all time stamps and statistics on per-thread
     13CPU usage were constrained to that of the clock tick.  In RTEMS 4.8.0,
     14the lowest level of RTEMS -- the SuperCore (e.g. rtems/cpukit/score)
     15was converted to use POSIX ''struct timespec'' as the format for all
     16timestamps.  In conjunction with the addition of the ability of a BSP
     17to report "nanoseconds since last clock tick", RTEMS could now provide
     18nanosecond accurate timestamps and CPU usage statistics.
     19
     20Unfortunately, performing mathematical operations on ''struct timespec''
     21is painful and slow.  This project will consist of the following work:
     22
     23 *  Baseline Testing
     24  *  (DONE) Verify all test cases work as baseline.
     25  *  Capture execution times of RTEMS Timing Tests on reference hardware.
     26  *  Capture sizes of sample tests.
     27
     28 *  (DONE) Add a SuperCore object "ScoreTimestamp". 
     29  *  This is an opaque class which will be used by all SuperCore time related functions.
     30  *  Includes methods will be provided to convert timespec and other standard time formats to and from ScoreTimestamp.
     31  *  RTEMS has a class to operate upon timespec's so this will be implemented in terms of this.
     32  *  Direct operations on timespec's will be eliminated throughout RTEMS except as necessary near API calls which operate upon ''struct timespec'' arguments.
     33  *  Initial implementation will be using ''struct timespec'' and all methods should be simple pass throughs or wrapper of existing functionality in the Timespec math helper class. Note that by adding the class "ScoreTimestamp", we have added a class whose implementation can be changed.
     34
     35 *  (DONE) Verify all existing test cases still work.
     36
     37 *  (DONE) Implement alternate version of SuperCore object "ScoreTimestamp" which uses unsigned sixty-four bit integers to represent nanoseconds since the POSIX epoch.
     38  *  This implementation should be fairly simple as you can do direct math on 64-bit integers.
     39  *  Do not destroy ''struct timespec'' alternative.  The goal is to be able to pick the implementation is for each port to a new CPU architecture to select its preferred method.
     40  *  Provide configuration similar to other configure/build time parameters in RTEMS to let user select implementation.
     41  *  Make sure both implementations work. :-D
     42
     43 *  Post Testing
     44  *  Verify all test cases work as they did baseline.
     45  *  Capture execution times of RTEMS Timing Tests again on reference hardware for both implementations.
     46  *  Capture sizes of sample tests.
     47
     48 *  Select proper implementation for each target architecture
     49 *  Evaluation
     50  *  We anticipate that most of the target architectures RTEMS supports will benefit from using the 64-bit integer version.  But RTEMS supports over a dozen architectures so this is certainly not guaranteed.
     51  *  Work with RTEMS Community to run tests on as many targets as possible to decide which is best choice on each architecture.
     52  *  Simulators are available for most of the primary target architectures so we will be able to judge the impact of your work.