[RTEMS Project] #2271: Improved Timekeeping

RTEMS trac trac at rtems.org
Fri Mar 13 12:24:28 UTC 2015


#2271: Improved Timekeeping
-----------------------------+------------------------------
 Reporter:  sebastian.huber  |       Owner:  sebastian.huber
     Type:  enhancement      |      Status:  accepted
 Priority:  normal           |   Milestone:  4.11.1
Component:  cpukit           |     Version:  4.11
 Severity:  normal           |  Resolution:
 Keywords:                   |
-----------------------------+------------------------------

Comment (by AlexKrEB):

 == Current status ==

 Several tests were executed to compare the performance figures of FreeBSD
 timecounters and the current rtems nanoseconds extension. The
 multiprocessor system those tests are based on, is a Freescale T4240RDB
 Evaluation board which features 24 processor cores.
 Four exemplary plots will be given in the following, categorized in two
 different sections: tests with hardware periphery and tests without
 hardware periphery.
 The tests with hardware periphery feature the real process of obtaining
 the timestructures for FreeBSD timecounters and RTEMS clock uptimes,
 whereas without periphery, dummy values are returned instead which is only
 supposed to test the correct mechanism.
 The test environment was set up to call and execute the corresponding time
 obtaining functions as often as possible without doing any other tasks.
 Simulation times were 1 second.

 ''' Plots with hardware periphery '''

 [[Image(bintime_requests.png)]]
 [[Image(uptime_requests.png)]]

 All plots feature a box plot ([http://en.wikipedia.org/wiki/Box_plot])
 which is derived from the amount of individual requests each active
 working core comes up with as well as an indicator for the sum of
 individual requests. In case of the FreeBSD binuptime requests, the sum of
 requests increases continuously in clusters. From one processor to three,
 the amount nearly triples, whereas, it nearly increases by factor 5 once
 all processors are exhausted. For one processor, it starts at about 6
 millions and tops out at about 28 million requests for all processors.
 In contrast, the RTEMSUptime requests do not increase for an elevated
 amount of processors and shows a tendency to decrease once more processors
 are utilized. The sum of requests drops from 2.4 millions for one
 processor down to 2.2 million requests when all processors are used.

 ''' Plots without hardware periphery '''

 [[Image(bintime_requests_wo.png)]]
 [[Image(uptime_requests_wo.png)]]

 These tests were executed to check the correct mode of operation without
 any influence of hardware effects. For the bintime requests dummy values
 were returned once timekeeping functions were called. In case of the
 RTEMSUptime requests, the corresponding nanoseconds extension was
 initially set to 0.
 The amount of bintime requests increases in a linear manner from 16
 million from one processor to 500 million for all 24 processors.
 In contrast, the RTEMSUptime requests show similar characteristics as
 before when hardware was used. For one processor, the sum of requests
 equals about 5 million calls, but once more processors are used, this sum
 decreases. Until all processors are integrated, the behaviour shows little
 aberrations with a tendency of a slight decrease.

 == Conclusion ==

 Based on the findings of the previous two sections, it can be stated that
 FreeBSD shows much better performance figures than current RTEMS
 nanosecond extensions. Whereas FreeBSD shows continuously increasing sums
 of requests per active working processors, RTEMS nanosecond extensions
 show a slight decrease in requests in the same scenario.

--
Ticket URL: <http://devel.rtems.org/ticket/2271#comment:2>
RTEMS Project <http://www.rtems.org/>
RTEMS Project


More information about the bugs mailing list