epicsThreadSleepQuantum() not accurate

Bug #541353 reported by Andrew Johnson
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Andrew Johnson

Bug Description

epicsThreadSleepQuantum() returns the system clock period on most architectures, but on many this is not the actual minimum sleep period, as measured by epicsThreadPerform.

Additional information:
Suggestion from J. Lewis Muir:

As a first step, I could see adding a function such as

  void epicsThreadSetSleepQuantum(double quantum);

If someone knows what the sleep quantum should be for their particular machine (by experiment or otherwise), they can set it explicitly (at IOC boot time or whenever). If this function is never called, epicsThreadSleepQuantum() behaves just as it does now. But if epicsThreadSetSleepQuantum() has been called, epicsThreadSleepQuantum() returns the explicitly set quantum.

A step beyond this first step might not be a good idea. But if one was to try to implement a step 2 by tackling the problem of automatically determining the actual sleep quantum, perhaps a function could be added with this signature:

  void epicsThreadCalibrateSleepQuantum(void);

This function would use an algorithm to determine the actual sleep quantum and set it via step 1's epicsThreadSetSleepQuantum(). If the user would like to potentially get a more accurate sleep quantum than what is reported by epicsThreadSleepQuantum(), he or she could call this function (at IOC boot time or whenever). Again, the default is the behavior we have now; the user would have to explicitly call this function to get this new behavior.

What algorithm to use is where things might become difficult. I could see it being difficult to come up with an algorithm that would correctly determine a good actual sleep quantum for the wide range of hardware and operating systems on which EPICS runs.

Original Mantis Bug: mantis-324

Revision history for this message
Jeff Hill (johill-lanl) wrote :

This is the sleep quantum result for 32 bit compatibility mode on windows vista 64. The result is different certainly compared to windows 2000 where the windows stubs were originally developed. MS may be allocating a hardware timer to schedule the wake up when one is available, or using a faster scheduling quantum?

testPriority main error expected from epicsThreadSetPriority
    id 004321D0 old 49 new 49
testPriority thread
    id 00432AD0 old 50 new 50
Estimating sleep quantum..........done
Estimating sleep quantum..........done
The epicsThreadSleepQuantum() call returns 0.015600 sec.
This doesnt match the quantum estimate of 0.001149 sec within 10%.
It takes 0.030687 micro sec to call epicsThreadGetIdSelf ()
epicsThreadPrivateGet() takes 0.017555 microseconds

Andrew Johnson (anj)
tags: added: codeathon
Revision history for this message
mdavidsaver (mdavidsaver) wrote :

I don't think there is any realistic way for epicsThreadSleepQuantum() to be accurate on non-RTOS systems, so any attempt at calibration/fudge factor should be limited to OSD code for RTEMS/vxWorks.

Changed in epics-base:
assignee: nobody → Andrew Johnson (anj)
status: New → Triaged
Revision history for this message
mdavidsaver (mdavidsaver) wrote :
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.