This content has been marked as final. Show 3 replies
You are most likely missing the first deadline because it takes more than 3ms to get from when the thread is started to when it executes waitForNextPeriod. There can be various initialization related activities occurring during that time - classloading, initialization, JIT compilation etc. To remove these affects you need to generate pre-load/init and pre-compile lists to ensure those activities happen before the RT thread logic executes.
Or ... initially give your thread a larger period so that you don't miss this first deadline then change your period before calling waitForNextPeriod. That way you won't be in a rush to get to that first deadline, but can then have the short periods you are after.
Note that for really short periods you'll either need to use NoHeapRealtimeThreads or else tune the GC to make sure your thread will execute when expected.
Also that 1ns resolution from the real-time clock is pretty meaningless. If this is the OS reporting this then it's just an indicating of the resolution of clock updates, not an indication of the granularity of timing events that the clock supports.
Hope this helps.
Yes, it was indeed missing the first deadline, and bumping that period up a bit did the trick.
I'm trying to be careful to reuse objects for this test, so GC should not be a factor (yet). Average scheduling jitter is in the range of 4us, but worst case climbs to 100+us when kernel experiences other concurrent loads (Intel Atom processor).
We'll see how far the RT threads can take us, and then repeat with NHRT thread implementation. One of the goals of my investigation is to better understand the trade off between performance and programming effort
Thanks very much for your prompt assistance.