Script for automated testing of computer latency.

Johnny
Thx for the flowers!
If you are not getting >significant< amelioration (say > 15%) altering the "GRUB_CMDLINE_..." , stick with what you've got. Tommy usually states, that long (long in the sense of definitely considerably more than 2 hours {Tommy, please correct me, if I am wrong}). But: I guess, you know: we are working with potentially dangerous machines, are experienced enough and do what all god cnc-boys do: apply a good grain of cautiousness!
Greez
chris

Now that I have the best I've been able to get in a short run I will start a long run once the thunder storms stop

Thanks
John.

It seems that the vimeo page doesn't exist.... Anyone else have this problem? (I could probably search back through the past 14 pages lol )

flyingbrick wrote:

It seems that the vimeo page doesn't exist.... Anyone else have this problem? (I could probably search back through the past 14 pages lol )
 

It is listed on the todo list quite high, among with amd and raspberry temperatures.
I hope to get that done by end of this year
greez
chris

My current todo:
See attachment (can't see how to add a table in here, pointers welcome :-]), rename it to .ods instead of .gz and you should be able to read it.
Greez
chris
 

Hey, thanks for the effort to make this whole latency testing more reproducable.

The problem I face is that I can't interpret the results of this script, as I'm not very deep into this topic.
So a few questions:

1) As far as I understand the base thread is mostly used for software step generation. As most setups use mesa cards with their fpga step generation, do I have to worry about base thread latency at all? What about mesa cards connected to the parport?

2) Why is the standard deviation important? If I have a pretty narrow curve with a few large deviations, my standard deviation would be relatively small but because of the few large deviations, my system would still be unusable right?

3) The wiki states that the most important thing is the jitter. If I understand correctly, thats the maximum deviation of the period. So If I get a result of min=-30uS and max=20uS, my jitter would be 30uS. Is that correct? 

4) What jitter is considered okay for LinuxCNC when not using software stepping (e.g. using a mesa card)?

Thank you for putting so much work into this community project

If you are using a Mesa card, whether the interface is Ethernet, SPI or EPP (Parallel Port) only a servo thread is required. In a basic explanation the Mesa card is getting the info required to move the steppers and generating the timing. Same info just a different physical interface.
When soley using the Parallel Port linuxcnc is generating the step pulses, and this requires a base thread.
I just start with a base thread such as 25us and then adjust it up or down until it’s stable when running a config.
Essentially the Mesa route doesn’t require a lot of tuning, Parallel Port may require some or a lot depending on the machine.

klopp wrote:

Hey, thanks for the effort to make this whole latency testing more reproducable.

The problem I face is that I can't interpret the results of this script, as I'm not very deep into this topic.
So a few questions:

1) As far as I understand the base thread is mostly used for software step generation. As most setups use mesa cards with their fpga step generation, do I have to worry about base thread latency at all? What about mesa cards connected to the parport?

2) Why is the standard deviation important? If I have a pretty narrow curve with a few large deviations, my standard deviation would be relatively small but because of the few large deviations, my system would still be unusable right?

3) The wiki states that the most important thing is the jitter. If I understand correctly, thats the maximum deviation of the period. So If I get a result of min=-30uS and max=20uS, my jitter would be 30uS. Is that correct? 

4) What jitter is considered okay for LinuxCNC when not using software stepping (e.g. using a mesa card)?

Thank you for putting so much work into this community project