Hi all
Beginning with this post, I discovered that on the machine I intend to use to drive a bridgemill and a lathe via parport based BOB, there were some modules loaded, that I did not understand why.
As I lack of time for now, I will leave the details to be added in this thread. I will edit this first post as I go, to keep interested readers lets say in birds view of what's to be expected.
Greez
chris
Edit Sep. 29th, 2020:
1. Background
The pc I intend to use for my bridgemill and lathe is a Dell OptiPlex 980 SFF. It controlled the mill and bridge well with LinucCNC 2.7.x. As 2.8.0 was released recently, an update was due. In order to get everything about right or as good as possible right from the start, I started looking into reasonably optimising latency , having in mind that we have purchased a Deckel FP2NC where we want to replace the Dialog 4 (still runningm but not as comfortavle) with a LinuxCNC based controller. I wrote the
script
to gather pc and test latency related data. My first attempt was to find a good pc. Prooved, the dell 980 is not bad. So I started in looking into optimising stuff for this machine.
2. Steps undertaken to optimes
a) Selecting the hw platform
I had to equal Dell OptiPlex 980 SFF, one of them doing just fine with wheezy based LCNC 2.7.x. However I could not find another at the time being to serve as a backup and is first gen core based. So I started to look around for something newer. Based on some posts in this forum and what was available in numbers plus probably a couple more years. I purchased a hp 8300 elite desktop and agreed with the seller that he reserve 3 more units for me. The test results
looked OK
. but the dealer did not keep the served units (Grrrr!) and elsewhere not a single unit was available anymore. Fujitsu Esprimo Q920s where widely available then. It gave very promising
test results
, but they do not have parallel ports. They also vanished from the market as a I looked again. I tested other pc's with deceiving results and then two more Dell 980 were available for no money. So be it then for now: Dell OptiPlex 980.
b) Bios
I tweeked the Bios settings, which I will post in another thread, yet to be opened later on. For the time being and to set focus on the stuff to be discussed in this thread, I disabled audio in the bios. Booting "stock" kernels, there were no "snd" modules loaded and while running lcnc-hw, there was no audio output (see
here
for the 4 core desktop version of the 980).
c) Os
I checked out the os to use. As tommylight pointed out
here
, debian has a bit better latency than mint. My rudimental tests confirmed this, also Himarc3D came to the same conclusion
here
. So I decided to stick with debian buster.
d) Kernel
Note: If I talk of stock kernels here, they are off course rt kernels as required for 2.8.0.
Then I started to look in to the best suited kernel. I tested some 5.x kernels with rather disappointing results if compared to 4.x kernels. Thus I decided to stick with 4.x kernels for the time being. BeagleBrainz came to the same conclusion
here
.
BeagleBrainz pointed me to his
kernels
and encouraged me to try these. BeagleBrainz's kernels are optimised by him for latency and aimed at Mint. As said before, I intend to stay with debian, but tommylight
hinted
they should run with debian too.
So I started to play with BeagleBrainz's kernels. My feeling is, they are promising. Thus I am interested and willing to help sort out some problems these kernels may have. I got some surprises which were not observed using stock kernels:
- real time delays on basethread,
see here
. after preventing the sound modules from being loaded (
see here
), the rt errors were gone, so I consider this solved. However partially only:
- a miraculously appearing audio device, :
At first, I was not able to track what was loading the module. "dmesg | | grep -Ei "snd|audio|sound"" just returned nothing. Proofed, dmesg was cluttered with "evbug" messages (see below). Once the loading of evbug was omitted, I could see the process loading the sound module in dmesg:
Code:
dmesg | grep -Ei "snd|audio|sound"
[ 0.334838] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio)
Tommylight
observed
that a hdmi onboard device cannot be disabled. Preventing the loading of the subsequently triggered kernel modules can be looked at as a solution, but it remains unclear what triggers the appearance ofthe device itself. I'd like to understand and solve this for good. Puzzling is also, that device is named "Lenovo" while everything in this machine is definitely *NOT* Lenovo!
- evbug module loaded
(see here)
. It can be blacklisted and BeagleBrainz promised bake new kernels without evbug module enabled, see below (thank you). So I consider this solved, too.
e) Desktop environment
For my daily duties, I use OpenSuSe with Kde/Plasma. Had that with wheezy based LCNC 2.7.x too. Reading up in the forum here, Xfce seemed to be proposed by many. Testing Mint, Mate came into play too. tommylight pointed out
here
, that Xfce provides better latency than mate under Mint. I assume he is right. I tested Xfce and Kde
here
and as I am used to Kde (though I know, not reall light weight) plus a bit better latency results, I will stick with Kde for now at least.
f) Remaining steps
Select the "best" kernel
Play with boot parameters
Clean up services (stop everything not needed)
Update as of Sep. 30th 2020
d) Kernel
As tommylight and BeagleBrainz indicated, rtai kernels are still around. I'll look into that.
