Reducing latency on multicore pc's - Success!

Sounds promising

Don't forget anyone reporting results to put the full results on the wiki

wiki.linuxcnc.org/cgi-bin/wiki.pl?Latency-Test

Go to the 5th line down and a link called Basic Steps to see how to sign in to edit pages

I've added mine.

Although, interestingly enough, I have even "better?" results now.

As mentioned, I wanted to try a fast servo loop because I'm hoping to try out software commutation of my brushless servos.

So I tried another couple of tweaks to my machine configuration, and not finding anything that helped any more than the above listed scripts and IRQ reassignment, I gave a latency test with a fast servo loop a try:

# latency-test 25us 125us

... then I ran my "exercise" script, which starts up a few copies of glxgears and also runs totem playing a full motion video file (an example ogg theora clip from the mplayer site) in a continuous loop.

I'll check on it tonight when I get home (I like to run 24 hour tests), but so far it seems both threads have jitter around 2000. (not 20,000, *2000* ns).

I'm guessing this is because the shorter period on the servo thread means the thread code stays in the processor cache all the time? Has anyone else seen or tried this?

Thanks,
Erik

Final numbers after 24 hours for the above mentioned 25us/125us run:


126322 2803
27122 2298

Erik

Thanks!
Had about 35000, now it shows jittering of 3500.
Though if I put max jittering anywhere lower than 12000 it glitches (while accelerating speed goes up, then it starts to go down), but still - 12000 is much much better
Btw - is it normal that launch of any aplication produces enormous lag.. like 350000 and more? Any other sort of abuse doesn't do that.

Sure.

PC Hard disks are quite a bit slower than memory, and depending on the hardware involved in controlling them there may be a big burst of lag when you access them, like when any program starts.

Possible sources of delay include slow I/O hardware, disk controllers on the other side of a slow bus, a slow disk or a disk in a slow access mode (3 Gb instead of 6 Gb SATA, for instance) or even a failing hard disk that's generating errors.

You can test whether the disk is the problem by moving your program somewhere else to run it, like a RAMdisk if you have enough memory.

green751 wrote:

Sure.

PC Hard disks are quite a bit slower than memory, and depending on the hardware involved in controlling them there may be a big burst of lag when you access them, like when any program starts.

Possible sources of delay include slow I/O hardware, disk controllers on the other side of a slow bus, a slow disk or a disk in a slow access mode (3 Gb instead of 6 Gb SATA, for instance) or even a failing hard disk that's generating errors.

You can test whether the disk is the problem by moving your program somewhere else to run it, like a RAMdisk if you have enough memory.

Thanks, will check that. Didn't thought hdd might be a "blocking function".
Happy new year!

What about Debian 7 with linuxcnc 2.6.1? I installed it from binary.hybrid.iso and same method doesn't work, still 8000ns to 10000ns
Ubuntu 10.04 works well: 1300ns to 4800ns

Hello

I am completely new to this.

I managed everything of this description except the grub modification:

The Max Jitters are down to 4764 (1ms) and 8522 (25ms).

I use the standard configuration of linux CNC including debian linux.

I added the following two lines to grub

isolcpus=1
acpi_irq_nobalance noirqbalance

I tried to call update-grub afterwards. I receive the error message that update-grub cannot be found.
therefore I called it directly:

sudo /usr/sbin/update-grub

the response is:

/usr/sbin/grub-mkonfig:35/etc/default/grub: acpi_irq_nobalance not found.

What do I do wrong?

Furthermore the provided debian version has no software center. How do i figure out if irqbalance is running?
best wishes

Doc Alex.

I tried Spainman's scripts on my machine and they seem to improve my latency.

My machine:
Club3D ATI Radeon X300 256MB PCI-E Silent
Gigabyte GA-P35-DS4 rev1.0
Intel Core2Duo E8400
4x1GB Ram
WD IDE HDD

BIOS settings:
All peripherals set to OFF, except LAN and LPT
Every setting that seems to alter the clock for power saving or performance: OFF

Kernel parameters copied from Spainman's first post in this thread:
"isolcpus=1 acpi_irq_nobalance noirqbalance"

In the attached picture, you can see
- latency-plot
- 3x gxlgears
- 1080p Big Buck Bunny

It seems like the upstart script provided by Spainman doesn't work with debian, so i called his set-irq-affinity script manually.
In the plot, i highlighted the point in time when i called "set-irq-affinity 1"
As you can see the latency spikes are reduced after this.



Edit:
It seems like i was a bit lucky taking this screenshot. It is true, that setting irq-affinity 1 calms down the small spikes, but sadly the huge spikes of ~17k are still happening, even with irq-affinity 1.

@Doc Alex:

I added the following two lines to grub

isolcpus=1
acpi_irq_nobalance noirqbalance

I think this has to be one line. you have to add it to the line you already have.
For example:
GRUB_CMDLINE_LINUX_DEFAULT="isolcpus=1 acpi_irq_nobalance noirqbalance lapic quiet rootdelay=5"

@qthree:
The reason might be, that the upstart script doesn't work on debian (at least it doesn't work on my machine)
I have no idea how this upstart stuff works, so i hope someone here can help us with this