* realtime ethernet
[not found] <568ec603-8a01-3726-dd8e-6cf04e055767@numalliance.com>
@ 2017-05-02 9:25 ` Stéphane Ancelot
2017-05-03 21:33 ` Jeff Epler
0 siblings, 1 reply; 4+ messages in thread
From: Stéphane Ancelot @ 2017-05-02 9:25 UTC (permalink / raw)
To: linux-rt-users
Hi,
I would like to know if it is possible to use rt preempt for realtime
ethernet purposes ?
Regards,
S.Ancelot
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: realtime ethernet
2017-05-02 9:25 ` realtime ethernet Stéphane Ancelot
@ 2017-05-03 21:33 ` Jeff Epler
2017-05-04 7:54 ` Stéphane Ancelot
0 siblings, 1 reply; 4+ messages in thread
From: Jeff Epler @ 2017-05-03 21:33 UTC (permalink / raw)
To: Stéphane Ancelot; +Cc: linux-rt-users
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: realtime ethernet
2017-05-03 21:33 ` Jeff Epler
@ 2017-05-04 7:54 ` Stéphane Ancelot
2017-05-05 15:52 ` Jeff Epler
0 siblings, 1 reply; 4+ messages in thread
From: Stéphane Ancelot @ 2017-05-04 7:54 UTC (permalink / raw)
To: Jeff Epler; +Cc: linux-rt-users
Hi,
In any cases, I understand that the classic linux nic driver needs
modifications to be realtime. (refer to rtnet work)
because of the NAPI stack not really suitable for realtime.
So, I understand that these modifications are not parts of the rt
preeempt patch today.
for some nics, yes, there are some not well documented timeouts
registers to be "hacked" in order being realtime too.
Regards,
S.Ancelot
Le 03/05/2017 à 23:33, Jeff Epler a écrit :
> 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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: realtime ethernet
2017-05-04 7:54 ` Stéphane Ancelot
@ 2017-05-05 15:52 ` Jeff Epler
0 siblings, 0 replies; 4+ messages in thread
From: Jeff Epler @ 2017-05-05 15:52 UTC (permalink / raw)
To: Stéphane Ancelot; +Cc: linux-rt-users
On Thu, May 04, 2017 at 09:54:36AM +0200, Stéphane Ancelot wrote:
> Hi,
>
> In any cases, I understand that the classic linux nic driver needs
> modifications to be realtime. (refer to rtnet work)
>
> because of the NAPI stack not really suitable for realtime.
>
> So, I understand that these modifications are not parts of the rt preeempt
> patch today.
We are working without any additional RT networking patches except those in the
debian -rt kernels.
Jeff
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2017-05-05 15:52 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[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
2017-05-04 7:54 ` Stéphane Ancelot
2017-05-05 15:52 ` Jeff Epler
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).