Skip to content

Create ping component#4087

Draft
hdiethelm wants to merge 1 commit into
LinuxCNC:masterfrom
hdiethelm:ping_component_v2
Draft

Create ping component#4087
hdiethelm wants to merge 1 commit into
LinuxCNC:masterfrom
hdiethelm:ping_component_v2

Conversation

@hdiethelm

@hdiethelm hdiethelm commented May 30, 2026

Copy link
Copy Markdown
Contributor

This component does basically the same as icmp ping. However, it runs in the linuxcnc realtime environment, so it can be used to tune network latency.

I created it for network tuning due to sudo taskset 8 chrt 90 ping -i .001 -q 192.168.1.121 is a bit cumbersome to use and has no histogram option.

Feel free to merge if you think this is useful for everyone.

TBD

  • Integrate into latency-test and/or latency-historgam?
  • Create example file?
  • Is there a way to create userspace only components? So I could get rid of this silly #if defined(__KERNEL__) -> Only report an error and quit

This component does basically the same as icmp ping. However, it runs
in the linuxcnc realtime environment, so it can be used to tune network
latency.
@hdiethelm
hdiethelm force-pushed the ping_component_v2 branch from 8a31849 to 70f36f3 Compare July 22, 2026 20:48
@BsAtHome

Copy link
Copy Markdown
Contributor

Are you sure it is a good idea to do ping in RT? It just feels wrong.

If you want histograms and such, you should create a standalone program that runs its own thread in RT and generates that kind of data. Running it together with LCNC may not produce the result you expect. Interleaving the normal RT thread(s) with ping may not be very stable for the RT thread or other functions. You also use the standard kernel network API, which gives no guarantees afaik. There may also be unexpected interactions with the normal traffic that is being sent (like ordering).

@hdiethelm

Copy link
Copy Markdown
Contributor Author

Are you sure it is a good idea to do ping in RT? It just feels wrong.

If you want histograms and such, you should create a standalone program that runs its own thread in RT and generates that kind of data. Running it together with LCNC may not produce the result you expect. Interleaving the normal RT thread(s) with ping may not be very stable for the RT thread or other functions. You also use the standard kernel network API, which gives no guarantees afaik. There may also be unexpected interactions with the normal traffic that is being sent (like ordering).

The idea is to use this together with an UI to create something similar to latency-histogram. Just using ping + hal-histogram -> latency-histogram-ping.

The reasoning behind is that with hm2_eth, the biggest latency source is the network.

When I initially set up my machine, it failed. After some digging in the forum, I found the chrt ping ... command which showed network issues. Future digging and I discovered that I had to install an other network card driver / set interrupt priorities / assign the interrupts to the isolated core / set some magic ethtool parameters and so on. Such a tool + good doc would have helped a lot. Also document all this and create a kernel cmdline + network parameter tool is on the bucket list but one step at a time.

Ping latency went down from > 1000us to now ~60-80us.

As much as I know, there is no reltime socket with PREEMT_RT. Also hm2_eth uses just standard sockets with firewall + peresistent ARP.

Firewall / ARP is missing here. I will add ARP but firewall would add a lot of copy-paste code and is not necessary as long as you don't do dumb stuff.

However, this component will not behave idealy with Xenomai3/4 which have dedicatet network sockets. I have to add a warning now that there is a way to query which type is running.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants