About unexpected realtime delay ...

I do not use stepconfig, i edited hal file manualy

l2-max wrote: I do not use stepconfig, i edited hal file manualy

Then I'm confused by your question "why LinuxCNC reads second parport if no pins are connected for reading?"
The answer is it doesn't, it only reads them if you tell it to with the "addf addf parport.N.read base−thread" or "addf parport.read−all base−thread"

No confuse. My logic was - despite function is loaded, if no pins are configured for read, then there is nothing to read.

P.S. I understand that linuxcnc is implemented how it is implemented. No complains.

Hal files are simple scrips they don't check if something is used or not, they just do what they are told, and halpins such as the parallel port input pins can be read and used by other things independent of the hal file.

By what things they can be read and used?

A custom M-code could use them without a hal file reference.
A python userspace component can look up the value of a hal pin.

Okay. Will check that. You gave me the point.

Thanks

Moved parport.X.read functions to servo thread and got stable 31000nS base period for two parports generating pulses for 5 joints at 32kHz.

l2-max wrote: Hi Guys,

After tweaking LinuxCNC on my ASROCK-J3455-ITX board, I got really good latency not exceeding 5000nS. However, the minimum BASE_PERIOD I can set without getting unexpected realtime dalay is 39500nS. That gives me confident 25.3kHz pulse rate. If I go less than 39500nS then as close I approach ~32000nS as sooner after starting LinuxCNC I get the error. I also noticed, that I needed to increase BASE_PERIOD after I added second parallel port. With one parallel port BASE_PERIOD was set to 37500nS and no error was seen.

My question is "Is that CPU speed limits BASE_PERIOD in my case?"

CPU J3455 1.5GHz.

Maksym

I have the same motherboard as you and I'm trying to solve some latency issues.
Would you mind posting your bios settings ans what tweaks you have made to achieve such low latency numbers?
I'm at about 30-50us normally, with spikes up to over 100-120us on latest Debian 9 and RT kernel..
Have you been successful in disabling SMI, with Smictrl or some other method? It doesn't work at all for me.

I do not think my tweaks will help you much as you and I running different Debian releases.

Initially, latency test on this mother board shown 16uS with official RTAI 2.7.14 ISO image. Then I switched to 2.8 master branch. Latency remain exactly the same as with official release despite kernel changed to preempt-rt. If you cannot reach such latency with clean 2.7.14 RTAI on the motherboard then I am not sure my BIOS setup will help you much.

Sorry, I do not have LinuxCNC machine by hand thus, what I recall, I disabled "INTEL speed step" (-3uS) to run processor at constant speed and may be, not sure disabled virtualization (not sure it had some impact on latency). I also isolated CPU on 2 cores only (that tweak helped a lot -8uS) and latency dropped down to 5uS.

That is it, from what I remember had noticeable impact on latency. Try booting from 2.7.14 RTAI flash drive and run latency test to see if it will be different from what you have now.