Using "normal", vs "low-latency" vs "real-time RT" kernels
 

The application software runs in Linux, with some graphical interface for the user, but essentially to deliver commands via ethernet ports to motion control hardware.

These commands are sent at a modest rate, perhaps 20 per second at most, and even a full-blown Linux Mint with all the features seems to be able to do this without other services and threads causing delays.

The networking to the hardware uses a ethernet-based scheme called EtherCAT, which is supported by available software, which offer a RT kernel (kernel version 3.4) in the bundle. Current distros ship with version 3.5.

https://en.wikipedia.org/wiki/EtherCAT

I notice that a "low-latency" kernel can simply be downloaded via Synaptic for (say) this desktop distro (Mint).

Is there a difference between what is called "low-latency" and what is known as "RT"? (real-time)

If the regular kernel is "fast enough", does one need to start changing kernels anyway??

if the current kernel version is newer, can one simply expect that network software (like EtherCAT) will still function OK?

Here are definitions of the two terms:

https://help.ubuntu.com/community/Ub...RealTimeKernel

Without knowing your application I would guess that low-latency is good enough.

I don't know about ethercat, but the low latency kernels poll for input more often. This makes a system appear more responsive to the user. And is useful for audio as the normal kernel could have latencies in the double digits of miliseconds for things like midi events. So when you push a key on the keyboard a sound appears to generate almost instantly with a low latency kernel. Verus a potential in proximity of a full note or beat later at fast-ish tempos and even on decent hardware with a normal kernel.

If this is dedicated hardware, then you may want the low latency kernel. If not, then the normal kernel should work fine. Latency and throughput are directly related.

high latency = high throughput = data server
medium latency = medium throughput = desktop (runs smoothly even under load)
low latency = low throughput = media server (midi), embedded
real-time is ultra low latency = embedded, military, industrial robots, aviation

My thanks to all of you.

The impression I get from this reading is that one can actually disadvantage oneself in in simply going for a RT real-time kernel without understanding that while it allows the user to force a single (maybe critically important) thread to have priority, the responsibility is then on the user to ensure this does not severely block up other throughput.

In a control application, dedicated to little else, this might be OK, but if other nice things are needed, like (say) remote access, then RT might not be wise.

The pre-emptive schedulling, and other clever stuff that comes with kernels is there for good reasons. A low-latency kernel might be useful where unsynchronized inputs, such as maybe a music keyboard touch is happening, but to have the kernel polling everything in a 1KHz loop (instead of 300Hz) might compress the interval available for other threads (such as ethernet traffic).

I was surprised that the application (satellite tracking) seems to be able to do all it has to do, even when tested using a full-blown desktop distro (Mint) with a generic kernel, and deliberately loaded with apps and traffic. I will use a low-latency kernel if I have to. I am thinking a real-time setup is not really necessary, and maybe RT could itself become a problem.

Using the low latency or realtime kernels is more critical on lower spec'd gear. Or if you need things to sync events in realtime, i.e. music. The pros and cons are most noticed while under load. Which is harder to max out on higher end gear.

For some reason I think linux gave up efforts on a true realtime kernel. Too many other issues going on to get it working on a common system and with drivers and apps. There are commercial products for limited industrial use that do work good.

I'd stay away from real time and consider low latency which is or should be stable.

This application does indeed require to sync to events in real-time, and definitely will be using higher end gear. Probably an Intel i7 where the 4 cores can run 8 threads, and 16G RAM. I know some Linux distros can be persuaded to run entirely in RAM. Also, a modern SDD for boot-up, and for some things that absolutely have to be kept. Like a server, this kit may have to run a year or two between re-boots.

"Sync to events in real-time" is a relative thing. "How close do you need to get"? is the question. In this case, the point position has to found and followed, not only to a certain accuracy, but at a particular time calculated forward from Unix Time (Julian Date in 1970). The Earth shifts and wobbles about underneath a satellite peturbed by the Moon, and Sun, and various other drags, but this has all been tolerably well modeled.

The Linux PC uses (ntp) to a local network time server locked with GPS, and any result is known by 300 microseconds late in real time, out of only one thread. It only has to supply these at (say) 200 per second, that leaves most of a whole 5 milliseconds for the same thread to do something else. Then, the other 7 threads can be computing other things at full speed anyway.

Computing answers deliberately set into the future by the same amount as the latent delays gets you there. The computing part is extremely quick compared to downstream mechanical considerations. So far, the pre-emptive schedulling Linux kernel seems to be doing it OK despite all the advice I have had to go for an RT kernel.

Having an RT module where the real-time OS thread can never be pre-empted by the non-real-time Linux gives a feeling of security, but it is hard to see that an 8-thread i7 would ever be challenged by this. Maybe the only thing left is to choose a nice distro that one can fit and forget for some years.