linux-rt-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Epler <jepler@unpythonic.net>
To: "Stéphane Ancelot" <sancelot@numalliance.com>
Cc: linux-rt-users@vger.kernel.org
Subject: Re: realtime ethernet
Date: Wed, 3 May 2017 16:33:09 -0500	[thread overview]
Message-ID: <20170503213309.GA27055@unpythonic.net> (raw)
In-Reply-To: <d3ca141e-916f-d7f1-e840-c1a450921f36@numalliance.com>

In LinuxCNC, we are successfully using rt preempt for realtime
networking.  You can find the code in our public git:
https://github.com/LinuxCNC/linuxcnc/blob/master/src/hal/drivers/mesa-hostmot2/hm2_eth.c
(GPL2+ license).  This talks to an FPGA board from Mesa Electronics,
which is running its own embedded realtime software stack.

Depending on the setup, this generally consists of 2 UDP packets
transmitted + 1 packet received, at a repetitive rate between 500Hz and
4kHz, with most users selecting 1kHz as far as we're aware.  The packets
aren't that big overall, without looking I bet it's under 1kB per period
all told.  (so the bandwidth utilization is not high)

On the Linux end we are generally using a dedicated gigabit NIC, and my
testing personally has been with Intel PCI-E nics like 82574L.  Most
users attach a single FPGA board (that board has a 100-megabit NIC) but
it's also possible to attach several boards via a dedicated gigabit
switch.

(The packet data consists of information from a CNC machine such as
motor position and other machine state, and commands to the machine
consist of things like motor torque commands or step waveform frequency
commands; LinuxCNC closes the position loop and performs other machine
logic)

As usual, not all mainboards and NICs are suitable, but we certainly
have success with specific Intel NICs. (and maybe some realteks?)

There are some tunables like RX IRQ coalesce that need to be, er, tuned
but I don't have that info on hand and it looks like it isn't in our
documentation. :(

I wish the tricks like manual ARP pinning and firewall manipulation
weren't necessary, but in our situation they seem to be somewhere
between helpful and necessary.  In particular, needing to ARP the other
NIC is not great for latency.

I've used hm2_eth with a range of RT kernels from 3.2 to 4.9 (usually
debian -rt kernels).

Disclaimer: I was compensated for the work I'm describing here

Jeff

  reply	other threads:[~2017-05-03 21:33 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <568ec603-8a01-3726-dd8e-6cf04e055767@numalliance.com>
2017-05-02  9:25 ` realtime ethernet Stéphane Ancelot
2017-05-03 21:33   ` Jeff Epler [this message]
2017-05-04  7:54     ` Stéphane Ancelot
2017-05-05 15:52       ` Jeff Epler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170503213309.GA27055@unpythonic.net \
    --to=jepler@unpythonic.net \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=sancelot@numalliance.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).