latency-histogram meaning of values & performances problem

I have occasionally been working on linuxcnc for a few years, often I have done tests with latency-hystogram --nobase but without ever understanding the meaning of the values ... so I would ask some patient person to explain the video values ​​well from this example image:



Here we can see these value:

1. min(us)
2. sdev(us)
3. max(us)

Servo is on 0,5ms, and bisize is 0,1.

What is min(us), max and sdev value? What is bin (horizontal axis) and 1Ex (vertical axis)?

Not find any link about these simple explanation of represented value.

Thanks very much for those explanation.

min and max us are minimum an maximum deviations from the default period in microseconds

sdev is the standard deviation (68% of the periods will be between +- sdev microseconds)

So in these case I have realtime deviaton from 500usec from +/- 83usec and how can see that 68% of period is between +/- sdev of 4.2usec? Where can read 68% of deviation?

So for to have an usable SO and Hardware for 500usec realtime sdev must be "0"?

Very thanks for these explanation.

Yes, you have a period of 500 usec with a peak deviation of 83 usec
( minimum period = 416 usec maximum period = 583 usec)

The errors (both peak and standard deviation) will never be 0

The 68% comes from the definition of standard deviation, If you look at your chart, what this means is that ~68% of the samples will be between the 4 and -4 usec error labels on the x axis

You might want to look up:

"standard deviation"
and
"histogram"

1-Ok based on your experinces, what is a good "standard deviation" from period for to reach a good servo hardware?
2-An for an ethernet (with mesa ethernet board or with ethercat) servo?

3-For now newer see velocity issue with my old 7i76 1ms period board. So I think never use less than 1ms period, but I think make a test on 0.5ms period make more "stress" on hardware. These is right?

Very thanks for your response.

1. As long as you can always make the 1 ms servo thread deadline,
it really does not matter very much

2. Note that latency with Ethernet hardware will be somewhat worse that shown by the latency test

3. 1 ms is fine for most normal CNC machines, only very fast (say laser cutters) or
devices with combined high acceleration and high precision requirements need
a faster servo thread rate. A higher servo thread rate may also be required if a torque
mode drive is being controlled by LinuxCNC

Very thanks to PCW ....
Based on last uncomfortable result I try to install linux mint 19 with same RT and kernel (4.14.164-rt73) ... the result seems better but not understand as is possible obtain more better result .... (the histogram with 67500 elapse time, 8 glxgears, same as last try with ubuntu 18.04, but with 3 youtube video. Last time only 1 or 2.)


PCW said isolcpu is not interesting trik for decrease latency .... ACPI on bios is disable but not in xconfig menù of RT kernel ... smi i think is only an old trik not interesting, other suggest? Because I think these hardware and CPU can make somethings better than these poor result.

regards

isolcpus can give a slight latency decrease, if you choose the correct cores to disable. To work out which cores requires a bit of research concerning your particular cpu. I had some success with the Atomic Pi platform using this technique.

Remember there's no prizes or street cred for getting lowest latency, unlike a major cnc site that has a thing for the fastest rapids on hobby class machines.

If it runs your machine safely & reliably for hours on end. My machine has similar latency to your last screenshot and I haven't had a problem.

the problem is not winning somethings ... the problem is to better understand which settings on xconfig give the best results. I have some i3 cpu witch these latency and work from 5/4/3/2/1 years 24/24 24/16 or 24/8 hour day sometime 7/7 day at week without any issue. So I confirm your world. But I know for sure that with my hardware (which is not optimal but good) and with my i5 cpu even if with little chache, many get much better results. Being able to obtain them, instead of limiting the pc to cnc, one could actually use it safely for other things on a continuous basis ..... with this latency if I work on it too much (for example with a large vision system) there is a risk of create realtime errors.

There is no point attempting to optimise latency. Its either fast enough or it isn't.

CPU's have two kinds of interrupts; hardware interrupts and timer interrupts. When an interrupt occurs, the main processing thread is halted and the ISR (interrupt Service Routine) is executed and the main processing thread resumes. If an ISR is too long, bad things happen because the CPU is unable to do its own housekeeping.

Hardware interrupts are attached to a specific hardware pin. An example might be an Arduino servicing a hardware interrupt attached to an encoder. The ISR will be called when the state of the input changes. On a PC, the CPU is not really designed around hardware interrupts but there is generally a hardware reset pin that is sometimes used on high end debugging hardware to regain control if an endless loop is encountered.

Timer interrupts are much simpler to implement. The system itself has its own timer ISR's that do the housekeeping so all we need to do is tell the system to run our ISR and then chain to the system ISR's when we are done. If we want to only run our ISR say once every millisecond rather than on every tick of the CPU's clock, we just simply wait out the number of clock cycles until one millisecond has passed and then run our ISR. If we want to add extra ISR's, we can just add them to the execution chain. This chain is often called a thread (eg like a servo thread)

So Linuxcnc is basically one great big timer interrupt chain that typically fires every millisecond. Because we are using a real time operating system, we have confidence that our timer interrupt will run on time. Nothing is perfect so there is some variation or latency which is measured in the latency histogram. This summarises as max, min and Standard deviation (which is based on the statistics of a normal population (being deviations from the mean). But we will ignore the lesson in statistics for now.

As we add components in HAL, we are adding an extra ISR to the timer interrupt chain. By saying the servo thread fires every millisecond, we are giving the system 1 millisecond to service all of our components ( eg. ISR's). As long as everything is always serviced in that time frame, everything is perfect in the world of CNC. If the servo thread time period is ever exceeded, when executing our ISR chain, Linuxcnc reports the error.

It does not matter if the total execution time is 0.00000001 milliseconds or 0.9999 milliseconds, everything remains perfect in the world of CNC until the servo thread threshold is exceeded. (Linux CNC is just going to sit idle until the next invocation is fired anyway).

So lets say we have latency of 0.200 milliseconds and our execution time is 0.500 milliseconds (which is probably way overstated). We have confidence that we will never exceed 0.700 milliseconds so everything is perfect in the world of CNC. So lets say after 100 hours of effort, you manage to get the latency down to 0.020 milliseconds. What have you gained? Absolutely nothing!

So from the discussion above:
1. Optimising latency after it is adequate for our needs is pointless time wasting
2. Testing with a faster servo thread (eg 0.5 ms) than what we intend to use also serves no purpose.