Installing LinuxCNC On HP T610 Thin Client

Joco wrote:

Scripts that I used/adjusted for this test.

This includes the hog cpu script and the linuxcnc wrapper script that needs to be used. This wrapper starts linuxcnc on core 2 then moves the UI task to Core 1. This needed to ensure a balance of UI responsiveness while the RT tasks own Core 2.

Cpu hog on core 2 ensures clock speeds are maxed while linuxcnc is running. A quirk of this architecture seems to be that maxing core 2 also maxes core 1. But the opposite is not true. An alternative setup is to use idle=poll on the kernwl boot. In which case cou hog is not needed. However the cpu will run hot. I was seeing 70C which is deemed “hot” by this cpu with 100C as critical.
The advantage of cpu hog is if you stop lcnc the wrapper kills hog and the cpu will start to cool.

You will also see from the h/w test file that kernel 4.19 was used. I also tests with 4.9.0-13 and noticed that clock speeds seemed to be maxed irrespective of using idle=poll on kernel boot or not.

Cheers - J
 

J
I have run several tests using graphical and text mode latency test. I am pretty sure, they are different. I just had a short glimpse on your scripts. I feel, when getting time for it, I might get a punch on improving my attempt to propose a - kinda - standardized testing environment for hardware and latency. Would you mind me talking part of your scripts into my effort?
Or even better: Join efforts?
Greez
chris

This is originally a tommylight script from:
forum.linuxcnc.org/18-computer/39370-scr...-of-computer-latency

So if you are looking for the latest and want to work improvements etc suggest you work there.

The other scripts I had in the mix are offered as is where is.

You want to use/improve them, knock your socks off.  

 

Ah.  Wasn't sure from the way the start of the thread was written. So essentially .. have at it! 

For interest I installed Bullseye and then MX21 on this machine.  Neither will show the onboard NIC. I didn't bother going any further as I basically had a "F you Debian" moment.  How stupid is an OS that sees the onboard NIC just fine during install, even uses it to update latest packages and then when boots post install refuses to see said NIC anymore.  Ok - rant off.  Now I remember why I went to Arch Linux on these for py3.

If anyone has some magic sauce on how to make it see the onboard NIC under Bullseye or derivative I would love to know.

Cheers.
 

tommylight wrote:

Then since you use QtPyVCP a lot, see here:
www.qtpyvcp.com/install/bullseye.html

Don't mind me laughing Tommy. Joco wrote those instructions! 

According to modinfo tg3 supports that NIC.

One thing you may want to check after boot is to check if the kernel is recognising the NIC and if there is any missing firmware.

firmware: tigon/tg3_tso5.bin
firmware: tigon/tg3_tso.bin
firmware: tigon/tg3.bin

If you just want the firmware these may just be the ones:
anduin.linuxfromscratch.org/sources/linux-firmware/tigon/
Apparently they should live here:
/lib/firmware/tigon/



If you want to leave it for a couple of days mine should be arriving by post and I can have a quick look to see what's happening.

Wasn't dave having no luck with Bullseye ?

On a hunch I did an apt update/upgrade on MX21 and rebooted.  tg3 (which was loading before) is now recognising the nic.  Didn't get that joy on Bullseye (non free xfce version).  But I will "give it another crack" just to prove to myself I haven't missed the point.

Cheers - J.