Cannot seem to get good latency numbers!

I have the same processor in a Gigabyte motherboard and my preempt_rt latency scores are way better. I'll run the tests again later this week and report back, but I recall it being the 20uS range for the base thread.

Another thing to keep in mind when trying all the usual BIOS settings along with isolcpus=   is that BIOSes tend to be broken. It is binary only firmware that gets cobbled together in an SDK and you build and pray that it works. Settings often don't do what you expect. ON may be OFF or OFF may not turn anything off at all.

This is all just to see how low a score we can get for base thread of 25uS and not at all necessary for your servo thread and Mesa card.

I would still make it a sticky, plenty of parallel ports are still being used, plenty of used PC's on sale at lower prices than a RPI3 or RPI4, and it works flawlesly.
Also keeps more people using LinuxCNC, some of those users with time become developers, etc.
I would just add a warning at the top about it being useful for parallel port systems and not to bother with it for Mesa or Pico systems.
It would be nice some other members to chime in as i might be biased, i like parallel ports and still use them, but i also have a lot of Mesa boards, a lot!

I 100% agree with that

To continue my LinuxCNC education, can someone either explain or point me to an explanation of how to read/understand the histogram and what exactly to look for when using a Mesa board? I see tons of posts where people post a screenshot of their histogram and someone will tell them it either looks good or to try this or that. But I would like to understand what exactly it is saying and what I should be looking for. That is, if there is an easy way to explain it. If it is too technical or complicated then I understand.

Also I understand that latency is not really a factor when using a Mesa board but I have read that the Servo Jitter can/does affect step rate. If this is true, wouldn't it behoove me to try to tune latency in order to get the optimal performance out of my machine? Wouldn't that be a bottleneck in some cases?

Servo jitter is basically irrelevant with Mesa (and probable other) external stepgen
hardware. The maximum steprate is determined by the external hardware, not
anything in LinuxCNC.

As I said before, as long as you don't get real time errors, the servo thread latency
is not important.

Its time to move on with LinuxCNC installation.

What matters is max jitter value. When people is told to try this or that, it's not so much after the information conveyed on latency-histogram screenshot, but after other info conveyed in the question, and the advice given comes from experience.

Fact is, you could be using latency-test instead. Latency-histogram lets you see how many times a jitter value has happened, Under the graphic you see jitter values; to the left, you see the logarythmic scale giving you how many times a jitter value has happened. The more times a jitter value has happened, the taller its line gets.

The number after the "e" gives you the amount of zeroes that have to be added. So 1e1=10 times; 1e6=1,000,000 times. Not so useful, since it doesn't give to you the reason why that jitter value happened. Moreover, what really matters is just your jitter remaining under some limit. There's a reason why latency-test is still the "official" test. But latency-histogram is much, much fancier, no doubt about it.

Actually, since latency-test puts less of a load into the system, you could get slightly better jitter simply by using it instead of latency-histogram.

With a Mesa card like you have, your system's software does not need to generate a shipload of lightning-fast, tightly-timed step pulses to make servos/steppers know what to do each, say, 20 microseconds. That's now the job of the dedicated hardware, and it can do it easily because it has chips designed to do it. Your system software is now a supervisor that needs just to give new instructions to the dedicated hardware, ideally each 1000 microseconds, that is to say, each millisecond. You can easily see that your system's workload is now two orders of magnitude lower.

This is why you have been told that, as long as you can reach a frequency about 1 KHz on your servo thread, all should be fine. It's no coincidence the period of a 1 KHz frequency is one millisecond.

To generate that shipload of step pulses is a whole mountain of work for the software on your PC, and since you got dedicated hardware to do that work, to generate them when they are not needed, is nonsense. This is why you have been told to use --nobase parameter with latency-histogram. This is also the reason why your max jitter got better with --nobase. Simply the system got much less work to do.

Should your jitter reach more than a millisecond, you'll get an overrun (aka a realtime error), Now you can see why a max jitter about 100 usec (this is a 10% of your servo thread period) is fine. 200 is still considered good. Even 300 could be acceptable, after what has been written on this forum. PCW even said that, if there are no overruns, you should be doing it well, and he probably knows better than many. IIRC, you reported a servo max jitter of about 112 usec, so you are near to be golden.

Now, should you be still unhappy with your max jitter, you could either follow the doctrine and get a new PC, to do what others are doing with salvaged-from-junk dual-core systems, or you could think the emperor has no clothes and use the kernel parameters, etc, that have been already explained to you. You'd be surprised to know how many people here, more or less secretly, worships isolcpus=.