Re: Short EPICS event waits under RTEMS

["Wells, Alex \(DLSLtd,RAL,TEC\) via Tech-talk" <tech-talk at aps.anl.gov>]

Hi all,

Thank you for the quick replies!

We are using EPICS 7.0.7, with a couple of commits from later releases patched ontop of it. We're using RTEMS 5.1 at the moment.

I must admit I am uncertain why 100Hz was picked, but it is the current standard at Diamond and shared across all IOCs. I will have to find out next week when people are back from holiday why this was chosen.

If I understand correctly, due to our shortened tick timer we fall foul of the "correction" done inside EPICS that subtracts half the quantum. I guess in my case this means I am effectively requesting a timeout of zero, which would explain my observations.

Thanks again,

Alex Wells

---

From: Johnson, Andrew N. <anj at anl.gov>
Sent: Friday, August 28, 2026 4:15 PM
To: Rivers, Mark L. <rivers at cars.uchicago.edu>; Wells, Alex (DLSLtd,RAL,TEC) <alex.wells at diamond.ac.uk>
Cc: Jack Harper STFC UKRI via Tech-talk <tech-talk at aps.anl.gov>
Subject: Re: Short EPICS event waits under RTEMS

 

Hi Alex,

Mark is probably referring to this commit which appeared in 7.0.10, but it doesn't affect IOCs running on VxWorks or RTEMS.

Why aren’t you running your clock at 1KHz on RTEMS to match VxWorks?

This is a long-known issue with the EPICS timers on our embedded OSs, which both use ticks for their timer calls. It could be fixed by having the EPICS code check the nanosecond clock and retry the OS operation when that returns early with a timeout, but nobody has taken up and implemented that change. It would be a good Codeathon project for someone working with an embedded OS.

- Andrew

-- 

Complexity comes for free, Simplicity you have to work for.

On 8/28/26, 9:59 AM, "Tech-talk" <tech-talk-bounces at aps.anl.gov> wrote:

What version of base are you using? There have been recent changes.

Mark

Sent from my iPhone

On Aug 28, 2026, at 9:49 AM, Wells, Alex (DLSLtd,RAL,TEC) via Tech-talk <tech-talk at aps.anl.gov> wrote:



Hi TechTalk,

I'm having some difficulties when migrating from VxWorks to RTEMS around how timeouts seem to be handled for very short periods. 

Under VxWorks, I set a clock speed of 1000, i.e. 1kHz. I then had some events that had a timeout of 10 "ticks", so a wall time of 10ms. This event was triggered when the associated hardware finishes its read/write cycle - it would send an interrupt, and in the handler I signal the waited-on event. Interrupts were also often turned off, to save CPU time, so the events would just timeout but this caused no issues as the hardware read/write would complete inside the 10ms. 

Under RTEMS, I have a different clock speed of 100Hz. I set the same timeout of 10ms (0.01s). I also have interrupts disabled so that the Event will never be signalled. I see different behaviour - some of my reads/writes now report errors, as though they are attempting to execute too fast and not actually waiting the 10ms for the hardware to act.

This seems to be backed up by using EPICS' nanosecond timing functions. Using "epicsTimeGetCurrent" before and after the "epicsEventWaitWithTimeout" function, and then calling "epicsTimeDiffInNS" gives a mean and median duration of ~5ms between the before and after times. I suspect this means the EPICS Event Wait function is not actually waiting at all.

Is this somehow to do with the fact I'm trying to wait for exactly one tick? Or is there some other explanation for why my wait time is not being reached?

Thank you for any help,

Alex Wells

This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom.

This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom.