Even though there sometimes is some extra delay it run fine. Each time 
update(...) function is called I use
clock_gettime(...) and print to a file, this is how I measure execution time.

Remove receive(...) from the update function jitter is below one millisecond, 
with spikes up to almost 50 µs. It
feels good enough with some margin.

Use wireshark to capture then Ethernet frames are sent I have seen spikes up to 
around 200µs and this also feels
good enough. Receive frames spikes up to around five to ten milliseconds happen 
and this is a bit worse.


Will take a look at IRQ coalescing as several person suggested. Acountis real 
time Ethernet driver might also be
an option. Feedback within 20 milliseconds or so is probably good enough so run 
receive in another thread is also
an option. There is som kind of buffer so sending of Ethernet frames are 
sometimes delayed a little bit after
they have been timestamped by Wireshark?


Regards Nicklas Karlsson



tor 2026-09-17 klockan 14:23 -0700 skrev John Dammeyer:
> I wonder if I'm having the same problem.
> I have a MESA 7i92H on a PC.  I boot, I home all axis. Maybe jog around a 
> bit.  Then hit the ESTOP to remove power to the drives, turn off monitor and 
> leave the shop.  The PC stays running.  A day or two later I come back and 
> everything is fine.
> Or...
> I get this message as shown in the attached latency.txt file.
> 
> Unexpected realtime delay on task 0 with period 1000000
> This Message will only display once per session.
> Run the Latency Test and resolve before continuing.
> 
> This error may not show up for days and never really when I'm working with 
> the system either running G-code or doing something manually.
> 
> Suggestions?
> Thanks
> John
> 
> > -----Original Message-----
> > From: Nicklas SB Karlsson [mailto:[email protected]]
> > Sent: September 17, 2026 1:31 PM
> > To: [email protected]
> > Subject: Re: [Emc-users] Ethernet send packets jitter
> > 
> > Nailed it down to recv(...) function call. Measured with 1 �s resolution 
> > this
> > call usually take around 1 �s but
> > sometimes it take up several thousand micro seconds. Previously measured
> > these delays of several milliseconds
> > seems to happen with a periodicity of 16 to 17 milliseconds corresponding
> > to a frequency of around 60 Hz. Rule
> > out noise from power grid since this is 50 Hz in Sweden.
> > 
> > Have not had time to try what you suggest yet but have a lot more time
> > tommorow.
> > 
> > Anybody have any about cause of these extra delays on recv(...) ??
> > Rule blocking call since data i sent in an Ethercat ring from a single 
> > thread.
> > With no Ethernet frames sent it
> > should either block or receive.
> > 
> > Nicklas Karlsson
> > 
> > 
> > tor 2026-09-17 klockan 07:28 -0700 skrev Peter Wallace:
> > > On Thu, 17 Sep 2026, andy pugh wrote:
> > > 
> > > > On Wed, 16 Sept 2026 at 21:20, Nicklas SB Karlsson <[email protected]>
> > wrote:
> > > > 
> > > > > Running Linuxcnc and send receive Ethernet jitter is small for most
> > packets but sometimes there is delay of well
> > > > > above on millisecond, running for maybe a minute or so worst case is
> > between 6...7 milliseconds.
> > > > 
> > > > Maybe you need to disable IRQ coalescing? It's mentioned briefly in
> > > > the hm2_eth docs, but also might be relevant to EtherCAT.
> > > > https://linuxcnc.org/docs/stable/html/man/man9/hm2_eth.9.html
> > > > 
> > > > (It's at least a google-able phrase for further investigation)
> > > 
> > > At least for hm2_eth, basic Network latency improvement methods are:
> > > 
> > > 
> > > On Intel (and some less common others like broadcom), disable IRQ
> > coalescing
> > > 
> > > On Realtek, install the DKMS driver (the stock Linux driver has multi-ms
> > > random latencies)
> > > 
> > > On all, use isolcpus (or whatever the newer scheme is called) to isolate 
> > > the
> > > last CPU, and then pin the Ethernet IRQ to that CPU.
> > > 
> > > Use the latest kernel (I have a test system that always got random
> > timeouts,
> > > say once a day, with 6.x kernels, this was totally fixed with a 7.X kernel
> > > 
> > > 
> > > > 
> > > > --
> > > > atp
> > > > "A motorcycle is a bicycle with a pandemonium attachment and is
> > > > designed for the especial use of mechanical geniuses, daredevils and
> > > > lunatics."
> > > > ? George Fitch, Atlanta Constitution Newspaper, 1912
> > > > 
> > > > 
> > > > _______________________________________________
> > > > Emc-users mailing list
> > > > [email protected]
> > > > https://lists.sourceforge.net/lists/listinfo/emc-users
> > > 
> > > Peter Wallace
> > > Mesa Electronics
> > > 
> > > 
> > > _______________________________________________
> > > Emc-users mailing list
> > > [email protected]
> > > https://lists.sourceforge.net/lists/listinfo/emc-users
> > 
> > 
> > _______________________________________________
> > Emc-users mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/emc-users
> _______________________________________________
> Emc-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/emc-users


_______________________________________________
Emc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-users

Reply via email to