LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Software
User Name
Password
Linux - Software This forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.

Notices


Reply
  Search this Thread
Old 07-08-2014, 07:16 AM   #1
GTrax
Member
 
Registered: Oct 2005
Location: UK
Distribution: Mint
Posts: 258

Rep: Reputation: 37
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?
 
Old 07-08-2014, 01:51 PM   #2
smallpond
Senior Member
 
Registered: Feb 2011
Location: Massachusetts, USA
Distribution: Fedora 34
Posts: 3,691

Rep: Reputation: 1074Reputation: 1074Reputation: 1074Reputation: 1074Reputation: 1074Reputation: 1074Reputation: 1074Reputation: 1074
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.
 
Old 07-08-2014, 05:08 PM   #3
Shadow_7
Senior Member
 
Registered: Feb 2003
Distribution: debian
Posts: 4,137
Blog Entries: 1

Rep: Reputation: 873Reputation: 873Reputation: 873Reputation: 873Reputation: 873Reputation: 873Reputation: 873
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.
 
Old 07-08-2014, 05:38 PM   #4
metaschima
Senior Member
 
Registered: Dec 2013
Distribution: Slackware
Posts: 1,982

Rep: Reputation: 491Reputation: 491Reputation: 491Reputation: 491Reputation: 491
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

Last edited by metaschima; 07-08-2014 at 05:41 PM.
 
Old 07-09-2014, 05:48 AM   #5
GTrax
Member
 
Registered: Oct 2005
Location: UK
Distribution: Mint
Posts: 258

Original Poster
Rep: Reputation: 37
My thanks to all of you.

Quote:
Originally Posted by smallpond View Post
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.
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.
 
Old 07-09-2014, 10:27 AM   #6
Shadow_7
Senior Member
 
Registered: Feb 2003
Distribution: debian
Posts: 4,137
Blog Entries: 1

Rep: Reputation: 873Reputation: 873Reputation: 873Reputation: 873Reputation: 873Reputation: 873Reputation: 873
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.
 
Old 07-09-2014, 05:14 PM   #7
jefro
Moderator
 
Registered: Mar 2008
Posts: 21,237

Rep: Reputation: 3451Reputation: 3451Reputation: 3451Reputation: 3451Reputation: 3451Reputation: 3451Reputation: 3451Reputation: 3451Reputation: 3451Reputation: 3451Reputation: 3451
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.
 
Old 07-10-2014, 05:34 AM   #8
GTrax
Member
 
Registered: Oct 2005
Location: UK
Distribution: Mint
Posts: 258

Original Poster
Rep: Reputation: 37
Quote:
Originally Posted by Shadow_7 View Post
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.
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
What are the options "Nosuid" "mode" "size" in /etc/fstab? tuxfiles.org does not help pstein Linux - Newbie 1 11-16-2012 01:58 AM
unpredictable "delete" "move to trash" or "cut" file menu option dorianrenato Linux - General 3 11-28-2011 07:41 PM
net working eth0 eth1 wlan0 "no connection" "no LAN" "no wi-fi" Cayitano Linux - Newbie 5 12-09-2007 08:11 PM
Standard commands give "-bash: open: command not found" even in "su -" and "su root" mibo12 Linux - General 4 11-11-2007 11:18 PM
LXer: Displaying "MyComputer", "Trash", "Network Servers" Icons On A GNOME Desktop LXer Syndicated Linux News 0 04-02-2007 09:31 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Software

All times are GMT -5. The time now is 12:31 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration