Latency test.... cache...

So I have been running a latency test on a Dell Precision T3400 and was getting a max jitter on the servo thread of ~43k ns and on the base thread a max jitter of 12k-15k ns.

In reading about getting latency down I came across this page ( wiki.linuxcnc.org/cgi-bin/wiki.pl?RealTime ) and did the grub mod and saw no improvement.

Once I did the 2 window thing it dropped to a max jitter of 2333ns on the servo thread and 2531 on the base thread. So far... been running for about 30 min, I will let it run overnight with glxgears running.

So... low jitter numbers... great!

BUT, what do I do with this test? Do I have to open a terminal window and run the do nothing script before starting linuxcnc?

My plan is for this to be a dedicated system and I will likely have it boot directly into linuxcnc.

Help me understand this better.

-Richard

EDT: on a side note, is there a better load other than glxgears I should be running? I know the latency section said abuse it but what can I run unattended?

Hi

Your base thread max jitter before you started is perfectly useable @ 12 - 15K so bear that in mind.

In the sticky header to this section are 2 FAQs that should help you understand the problem better

www.linuxcnc.org/index.php/english/forum...-the-latency-problem
www.linuxcnc.org/index.php/english/forum...me-latency-solutions

You have found the cpu hog, but that is not a solution, just a demonstration of where the problem lies

The isolcpus kernel parameter should have an effect if the cpuhog did, assume that is what you mean by 'the GRUB thing'.
The other parameter to try is nohalt which improves interrupt wakeup latency and proved very effective when we were testing xenomai kernels

You appear to have a dual core processor, so the line should be isolcpus=1 (note it is plural)
You can test if it is working by running mpstat -P ALL in a terminal (you may have to install mpstat)

EDIT: in fact cat /proc/interrupts will give all the basic info, you will show some historical activity on the other cores, but the increases should all be on core 0

Whilst you achieved a very low latency score with the cpu hog running, did you try to do anything like open Firefox whilst it was running. I would suspect it would run like glue through sand.
You can get very artificially low figures but the computer is effectively unusable outside of RT

I normally test with 4 instances of glxgears running, open Firefox and surf the web, making sure I keep bringing up new links and run something like a refresh on the find database to get heavy disk IO going.
That will test graphics, networking and disk access.

The other things to check are the BIOS settings

Switch off any form of power control, temperature sensed fan control and particularly hyper-threading if it is an Intel processor

Have a good read through, you should find something to trim down the latency but leave it usable

regards

Some results...

Max jitter is 3997 (servo) and 3579 (base) this morning. I opened a few more glxgears and a few more instances of firefox and it's rock stable.

And, yes, I added the isolcpus=1 to the grub file (GRUB_CMDLINE_LINUX) and ran the update-grub command.

The processor is a dual core intel E4600 (so no HT).

MY plan is to run a mesa 5i23 and a couple of 7i29's to control the servos. Even after reading quite a bit I was not really able to determine which jitter number is important (servo vs base).

My background is as a windows based admin, but I do have a fair bit of exposure to linux... certainly not enough to be a linux admin but I know my way around.

I tried to run the mpstat program but as you guessed it is not installed. I tried to use apt-get ti install it but mpstat is apparently not the name of the package.

I will run the suggested cat /proc/interrupts and post the results here....

Richard

EDT: Here is the output for /proc/interrupts. It seems it's still using both cores...

CPU0 CPU1
0: 88 0 IO-APIC-edge timer
1: 2 4 IO-APIC-edge i8042
4: 1 1 IO-APIC-edge
7: 1 1 IO-APIC-edge parport0
8: 0 0 IO-APIC-edge rtc0
9: 0 0 IO-APIC-fasteoi acpi
12: 3 3 IO-APIC-edge i8042
16: 15526 196 IO-APIC-fasteoi uhci_hcd:usb3, HDA Intel
17: 0 0 IO-APIC-fasteoi uhci_hcd:usb4, uhci_hcd:usb7
18: 565 25 IO-APIC-fasteoi uhci_hcd:usb8
22: 0 2 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb5
23: 2 0 IO-APIC-fasteoi ehci_hcd:usb2, uhci_hcd:usb6
28: 769341 1241 PCI-MSI-edge ahci
29: 426 22107709 PCI-MSI-edge radeon
30: 35 61272 PCI-MSI-edge eth0
NMI: 0 0 Non-maskable interrupts
LOC: 25610708 16759308 Local timer interrupts
SPU: 0 0 Spurious interrupts
PMI: 0 0 Performance monitoring interrupts
PND: 0 0 Performance pending work
RES: 19960872 702513 Rescheduling interrupts
CAL: 0 113 Function call interrupts
TLB: 4 0 TLB shootdowns
TRM: 0 0 Thermal event interrupts
THR: 0 0 Threshold APIC interrupts
MCE: 0 0 Machine check exceptions
MCP: 214 214 Machine check polls
ERR: 1
MIS: 0


EDT2: I just re-read and noticed that the isolcpus=1 should be on the default line... I made the change and will get back to you.

EDT3: So, the isolcpus thing did not change the max jitter (43k/12k) but did make the system dog slow to load an app... I am trying nohalt now

EDT4: nohalt had a similar effect as isolcpus.... dog slow loading of apps (if they ever load) and still the same max jitter (42k/12k).

MY plan is to run a mesa 5i23 and a couple of 7i29's to control the servos. Even after reading quite a bit I was not really able to determine which jitter number is important (servo vs base).

Base thread is the critical one for steppers with software generated pulses, but for servos and mesa cards everything is much more relaxed.

You will probably be fine with your initial figures, I'll leave PCW or Andy to jump in.

regards

ArcEye wrote:

MY plan is to run a mesa 5i23 and a couple of 7i29's to control the servos. Even after reading quite a bit I was not really able to determine which jitter number is important (servo vs base).

Base thread is the critical one for steppers with software generated pulses, but for servos and mesa cards everything is much more relaxed.

You will probably be fine with your initial figures, I'll leave PCW or Andy to jump in.

regards

Cool. Most of the initial documentation seems to be geared toward stepper config so sometimes it hard to know what rules apply to what and what statements apply to.

I really like the idea of LinuxCNC and am moving forward on it.

My mill was sorta working on Mach3 till I tried to make some changes to the control. Now everything in the control doesn't seem to work...

It was done poorly anyway and it was an excuse to re-do it.

Richard

on a side note... my mesa stuff just showed up! Yeay... I get to play....

Richard