Minimum "on-time" for hal toggle pin

zdenek wrote:

Why > 2 and not > 1 ?
 

>1 gives no margin for jitter
 
I chose 2 based on my experience with our Ethernet connected devices
(and the default timeout values used)

zdenek wrote:

All that said, pragmatically and defensively speaking, you do have to be aware of the jitter. Linuxcnc is not a hard real time system -- you could see an occasional surprising departure from the 1ms nominal time. Consequently, a 1.2T pulse would be statistically better than a 1.1T pulse and of course a 2T pulse would improve the chances further, but so would 2.5T and my point was that the 2 factor appeared rather arbitrary. More importantly, I wanted to observe that I don't see anything algorithmic or design-based implying [precisely] 2 over any other factor greater than 1.
 

I think the "Unexpected realtime delay" warning is issued if jitter of >1T occurs, i.e. an interval >2T, so from that POV it makes sense to use 2T, further increasing the period length won't buy you much -- you shouldn't run a machine where "Unexpected realtime delay" warnings are occuring. 

You have to be a little bit careful here. When doing a kernel trace on a modestly specced PC, we found the servo thread usually got it's job done in about 0.2 T then slept for about 0.8T.  So there is a lot of time that Linuxcnc is not looking. Some cycles will have more work to do than others. While the start of the period is defined by the servo thread frequency, no such timing is applied to when the thread goes to sleep. It just needs to be asleep before 1T +- jitter is up.

But in this instance, it's required to  interface with a userspace pin so there is no T to control timing. I'm not sure how long would be required but I suspect 2T would not be enough to guarantee it's actioned reliably.

For real time signals, 2T should be good enough (as rmu indicated you should not
run a system that gets real time errors)

In fact most LinuxCNC real time components (like software stepgens or the software encoder
component) depend of this being true.

If you have non-real time functions, there is no upper bound on response time so you
would be safer using some kind of handshaking.

@rmu You are absolutely right, by the time you have a jitter ~1T you got bigger problems to worry about, and you should not run a machine under those conditions.

My original assumption (possibly a wrong one) was that @beefy was questioning how to interface a microcontroller to a correctly configured and functioning HAL real-time thread. Obviously for some definition of "correctly" and "functioning" which I would suggest means Jitter << 1T. I maintain that the answer is pulse > 1T where the ">" represents the aggregated uncertainties within the system, which I am assuming to be well << 1T. Note that >1T is algorithmic, with pulse = 2T being perhaps the obvious first choice.

When discussing the subject we all moved the focus on the system jitter. On that subject, while I do agree with @rmu that we should avoid large jitter, I want to point out that it is not so simple, since LinuxCNC does not run on a hard real-time OS. Consequently, in the absence of a *guarantee* all we can do is to run one of the latency* tools for "a while" and hope that we get good-enough representative data.

The bottom line is that the pulse = 2T is a good suggestion.
Perhaps what threw me off was the ">" sign in the original ">2T" suggestion which I (perhaps wrongly) interpreted as an algorithmic suggestion rather than "make it 2T and you are good, and if it's more that is OK, too".

Cheers