Back
[07:18:15] <jepler_> two more tests occurred to me: (A) you can of course modify linuxcnc (or, with a bit more difficulty, rtai kernl/latency) to bind to a different CPUID
[07:19:16] <jepler_> (B) you can write a hal component that hogs about half the time (i.e., if period is 1ms then it busy-waits 500ms before returning), then (using taskset to run a compute-bound program on each core) you can see what linux cpu number an rtai cpu number corresponds to
[08:03:47] <archivist> could our process measure its start time and then delay for diff to reduce peak variation
[08:20:22] <jepler_> I performed test (B), again on my qemu -smp 4 machine
[08:20:31] <jepler_> component "busywait" busy-waits for a half a period
[08:20:58] <jepler_> then I ran a userspace program that takes about 2.5s normally on each cpu: for c in 0 1 2 3; do echo; echo $c; taskset -c $c time python shamble.py; done
[08:21:15] <jepler_> for c=3 the elapsed time was doubled
[08:22:01] <jepler_> so it feels like the rtai cpuid numbering and the userspace cpuid numbering match
[08:23:48] <jepler_> http://pastie.org/9473257 http://pastie.org/9473258
[08:30:45] <jepler_> taskset shows that a fair number of processes are still allowed to schedule on core 3. For example, kpsmoused's affinity list is 0-3.
[08:43:45] <CaptHindsight> I'm considering setting up a hardware latency test rig to measure actual IO latency
[09:05:41] <CaptHindsight> I'll try comparing idle=poll as well later
[09:10:55] <CaptHindsight> how much tuning is worth the effort to reduce latency if it doesn't impact actual IO?
[09:11:04] <cradek> none
[09:13:10] <CaptHindsight> I wonder how close we are
[09:14:25] <CaptHindsight> on a 4 core cpu I don't see why RTAI should be sharing a core with any other processes
[09:43:57] <jepler_> CaptHindsight: I think it would be interesting to modify linuxcnc so that it binds rtai cpuid 2 and test on your system with isolcpus=2 and isolcpus=3
[09:45:02] <jepler_> CaptHindsight: I can provide a patch to do that, or you can just find the call to rt_task_init_cpuid and change the arugment from rt_cpu to 2
[09:46:45] <jepler_> because the other theory that fits the observations nearly as well as "off by one" is that it's helpful to isolate the other core that shares the same module
[09:47:12] <jepler_> since those two cores share L1i cache and decode resources
[09:47:41] <jepler_> this theory would be confirmed if linuxcnc on cpuid 2 performs better with isolcpus=3 than with isolcpus=2
[09:48:20] <jepler_> and the off-by-one theory would be confirmed if it performs better with isolcpus=1 than with isolcpus=2
[09:50:29] <CaptHindsight> jepler_: I'll be happy to test any patch, if it's not lots of work for you.
[09:50:52] <jepler_> CaptHindsight: I was hoping my prose description was enough .. hold on
[09:51:47] <jepler_> http://pastie.org/9473416 -- obviously not for pushing
[09:53:34] <CaptHindsight> the test system has a drive with 5-6 Linuxcnc installs on different distros
[09:54:35] <CaptHindsight> no tool chains or dev tools on them except for what the install might have added
[09:57:51] <KGB-linuxcnc> 03Jeff Epler 05jepler/hardcode-cpuid-for-ch ad8d425 06linuxcnc 10src/rtapi/rtai_rtapi.c Hard-code cpuid (CPU#) for rtai realtime * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ad8d425
[09:58:08] <jepler_> CaptHindsight: eventually, buildbot will build this branch and provide debs you can install
[09:58:51] <jepler_> the deb'll go in here:
http://buildbot.linuxcnc.org/dists/wheezy/scratch-rt/binary-i386/
[09:59:53] <jepler_> seb_kuzminsky: I just noticed that the buildbot front page doesn't list wheezy scratch-rt as an option
[10:00:45] <jepler_> seb_kuzminsky: also, it doesn't mention wheezy-rt for 2.6, which should probably be moved up above 2.5 and marked as "stable", while 2.5 should be downgraded to "old release"
[10:00:50] <jepler_> nit: picked
[10:09:24] <cradek> we sure need some web stuff updated
[10:09:58] <cradek> andy has some thoughts too (and of course he's right)
[10:29:15] <linuxcnc-build> build #122 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/122 blamelist: Jeff Epler <jepler@unpythonic.net>
[10:35:57] <linuxcnc-build> build #2315 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2315 blamelist: Jeff Epler <jepler@unpythonic.net>
[10:36:25] <seb_kuzminsky> i've got a bad feeling about this
[10:37:13] <seb_kuzminsky> not sure why that bonked
[10:37:40] <seb_kuzminsky> i was fearing a kernel panic, but the machine is up and seems fine
[10:37:47] <cradek> if you bind to cpu 2 but you don't have a cpu 2, what happens?
[10:38:03] <seb_kuzminsky> fuck if i know
[10:38:23] <seb_kuzminsky> that may be the only rtai buildslave with 2 cpus, i bet all the others have 1
[10:38:45] <cradek> I think 2 would be the third cpu
[10:39:42] <seb_kuzminsky> yeah, my lucid & precise rtai buildslaves have 1 cpu, wheezy-rtai has 2
[10:40:22] <seb_kuzminsky> logger[psha]:
[10:40:22] <logger[psha]> seb_kuzminsky: Log stored at
http://psha.org.ru/irc/%23linuxcnc-devel/2014-08-14.html
[10:40:30] <cradek> http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=commitdiff;h=ad8d4255d6bd543c9cff69d345d8865b8b72b911
[10:41:19] <cradek> so it might just be broken for <3 cpus
[10:41:23] <seb_kuzminsky> jepler_: i've made a note to update the buildbot links, may get to it tonight
[10:41:44] <seb_kuzminsky> cradek: but work on UP
[10:41:49] <seb_kuzminsky> yeah, could be
[10:41:51] <seb_kuzminsky> bbl
[11:02:34] <seb_kuzminsky> the buildslave had a bunch of rtai kernel modules loaded after it terminated the test, i rebooted it
[11:02:50] <seb_kuzminsky> wheezy-rtai
[11:26:56] <jepler_> argh, well, I guess buildbot's not going to give a package for that
[11:27:07] <jepler_> CaptHindsight: so you'll have to build linuxcnc yourself if you want to test
[11:27:41] <jepler_> seb_kuzminsky: sorry to cause the trouble
[11:28:05] <jepler_> or I could try writing rt_data->cpu > 2 ? 2 : rt_data->cpu
[11:32:25] <CaptHindsight> jepler_: ok, testing with idle=poll right now
[12:05:48] <CaptHindsight> idle=poll results
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?The_Isolcpus_Boot_Parameter_And_GRUB2#Latency_Testing
[12:11:13] <CaptHindsight> skunkworks: have you used any 4 or more cpus with Linuxcnc and tested isolcpus vs idle=poll?
[12:13:10] <KGB-linuxcnc> 03Jeff Epler 05jepler/hardcode-cpuid-for-ch e65eaf1 06linuxcnc 10src/rtapi/rtai_rtapi.c Hard-code cpuid (CPU#) for rtai realtime * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e65eaf1
[12:13:45] <jepler_> I haven't ever had a machine beefy enough to have 4 cores running rtai
[12:13:59] <jepler_> nor even 4 threads
[12:17:40] <CaptHindsight> heh, I meant 4 or more cpu cores, it's been type day for me :o
[12:20:36] <linuxcnc-build> build #1511 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/1511 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[12:20:54] <linuxcnc-build> build #2310 of 1201.rip-lucid-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1201.rip-lucid-rtai-i386/builds/2310 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[12:22:34] <linuxcnc-build> build #123 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/123 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[12:23:21] <linuxcnc-build> build #2309 of 1900.clang-lucid-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1900.clang-lucid-rtai-i386/builds/2309 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[12:44:50] <linuxcnc-build> build #2316 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2316 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[13:14:29] <jepler_> I fail
[13:20:51] <seb_kuzminsky> your branch is bad and you should feel bad
[13:27:16] <seb_kuzminsky> jepler's branch is so broken it made logger[psha] quit
[13:30:30] <cradek> jepler: I bet you can easily get it in 3 tries
[13:30:42] <cradek> that's still pretty good.
[14:06:36] <cradek> seb_kuzminsky: did you update linux-kbuild and linux-tools?
[14:28:16] <KGB-linuxcnc> 03Jeff Epler 05jepler/hardcode-cpuid-for-ch c4fcac6 06linuxcnc 10src/rtapi/rtai_rtapi.c Hard-code cpuid (CPU#) for rtai realtime * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c4fcac6
[14:30:33] <seb_kuzminsky> cradek: no, i just touched them in a vain attempt to get apt-ftparchive to notice that they changed
[14:31:05] <seb_kuzminsky> what finally did the trick was adding APT::FTPArchive::AlwaysStat=True, and regenerating the Packages files
[14:32:05] <seb_kuzminsky> i'm gonna push a new rtai-modules with the rtai_16550a driver included
[14:32:23] <seb_kuzminsky> it should be totally backwards compatible with the current rtai-modules, so no one should notice or care
[14:32:30] <seb_kuzminsky> except that one guy who wanted that driver
[14:34:17] <cradek> cool
[14:36:09] <linuxcnc-build> build #1512 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/1512 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[14:36:31] <linuxcnc-build> build #2311 of 1201.rip-lucid-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1201.rip-lucid-rtai-i386/builds/2311 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[14:36:50] <cradek> jepler: good grief, man
[14:37:07] <jepler> geez
[14:37:13] <cradek> jepler: do you want me to do it for you?
[14:37:31] <linuxcnc-build> build #124 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/124 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[14:38:39] <linuxcnc-build> build #2310 of 1900.clang-lucid-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1900.clang-lucid-rtai-i386/builds/2310 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[14:38:46] <jepler> cradek: at this point, yes
[14:43:08] <cradek> so you want it to use 0 if there is only cpu 0; 1 if there are 0,1; 2 if there are 0,1,2 or more
[14:43:21] <jepler> I want it to use cpu 2 on CaptHindsight's one machine
[14:43:29] <jepler> but I was punished for writing that
[14:43:36] <jepler> as were we all
[14:43:41] <jepler> especially seb
[14:43:57] <cradek> I think it was probably worst for you
[14:44:01] <jepler> but fundamentally this is CaptHindsight's fault for not being set up to apply the first simple one-liner change
[14:44:15] <jepler> nah, seb had to interrupt his actual life to reboot a machine I left in an unusable state after that first commit
[14:46:54] <KGB-linuxcnc> 03Jeff Epler 05jepler/hardcode-cpuid-for-ch 2edbb6b 06linuxcnc 10src/rtapi/rtai_rtapi.c Hard-code cpuid (CPU#) for rtai realtime * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2edbb6b
[14:47:24] <cradek> (I didn't test building it either)
[14:47:47] <jepler> cradek: hah
[14:53:24] <seb_kuzminsky> i like these later commits that blow up in the compile phase instead of the runtests phase ;-)
[14:53:36] <seb_kuzminsky> way more convenient for me
[14:55:33] <cradek> much faster too
[14:57:42] <CaptHindsight> my humble apologies to everyone here for not having installed the tools on the test system
[14:58:03] <jepler> CaptHindsight: eh, just giving you a hard time
[14:58:52] <CaptHindsight> jepler: I forgot to set the sarcasm flag on my last comment ;p
[14:59:10] <jepler> oh my irc client filters out html anyway
[14:59:37] <linuxcnc-build> build #2317 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2317 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[15:27:52] <CaptHindsight> we have 3,6 and 8 core cpus as well that are getting to the point of retirement and possibly finding their way into machine controllers
[15:29:46] <CaptHindsight> jepler: are first 3 cores the current limit of where RTAI will run?
[15:54:06] <jepler> CaptHindsight: in unmodified linuxcnc, the intent is to run all realtime threads on the highest numbered CPU. It uses just one CPU in order to provide the "rate monotonic scheduling" guarantee.
[15:54:31] <jepler> so on your 4-core system, that means all linuxcnc code is expected to run on (zero-based) CPU #3
[15:54:43] <jepler> with the change that has taken all day to get right, the intent is to run on (zero-based) CPU #2
[15:56:26] <jepler> which allows some tests which may discriminate between "on bulldozer+ it's important to isolcpus the other core in the same module" and "there's an off-by-one error in rtai cpuid numbering or kernel isolcpus="
[15:59:53] <CaptHindsight> I thought I had noticed something in the source yesterday limiting it to 4 cores, but I am mistaken
[16:00:38] <CaptHindsight> limiting the search for an isolated core to the first 4
[16:07:52] <jepler> I am not aware of any routine in rtai or rtapi which "search[es] for an isolated core".
[16:08:39] <jepler> when using the CPU mask APIs in rtai, it looks for the CPU in the mask with the fewest realtime tasks and chooses that one if possible. but rtapi/linuxcnc doesn't use this API.
[16:09:26] <jepler> kern/latency uses this API, passing in a mask of 0x3, but it only creates one realtime task so picking the CPU with the fewest realtime tasks is moot
[16:09:28] <seb_kuzminsky> rtai only handles up to 8 CPUs, any more than that it can't see
[16:09:48] <seb_kuzminsky> (i believe this from tracing rtai's configure's --enable-cpus=$NUMBER)
[16:10:06] <jepler> oh, yeah, I think I saw the same thing
[16:10:19] <jepler> /proc/rtai/scheduler says "Number of RT CPUs in system: 4 (sized for 8)"
[16:10:33] <seb_kuzminsky> meh
[16:11:43] <jepler> .. which means that in rtapi we should probably limit rt_cpu to be NR_RT_CPUS - 1 at most
[16:12:06] <seb_kuzminsky> it's spelled RTAI_NR_CPUS now
[16:12:19] <cradek> I recall an old smell of something breaking if you had too many CPUs
[16:12:29] <cradek> I wonder if it was that
[16:12:37] <jepler> could have been
[16:12:44] <jepler> why does rtai even configure itself for fewer CPUs than linux?
[16:12:46] <cradek> do you remember that? was it mozmck?
[16:13:58] <jepler> I don't remember specifically
[16:15:03] <jepler> somebody should make an implementation of rtapi that works directly on ipipe
[16:15:09] <jepler> though then you'd have to code up a math library, yuck
[16:15:17] <cradek> that would be really neat
[16:20:33] <jepler> I think the list of math functions actually used in linuxcnc is: sin, cos, tan, sqrt, fabs, atan, atan2, asin, acos, pow, round, ceil, floor
[16:21:02] <jepler> (and of course sincos)
[16:23:10] <jepler> cradek could copy those from freebsd libm in an afternoon
[16:23:41] <jepler> CaptHindsight: so I think
http://buildbot.linuxcnc.org/dists/wheezy/scratch-rt/binary-i386/linuxcnc_2.6.2~jepler.hardcode.cpuid.for.ch~2edbb6b_i386.deb is finally ready
[16:23:43] <seb_kuzminsky> what does rtai "add" on top of ipipe? just a bunch of headache and heartbreak, seems to me
[16:24:04] <jepler> seb_kuzminsky: userspace / kernelspace shared memory; and math
[16:24:13] <jepler> and a 16550a driver, apparently
[16:24:19] <seb_kuzminsky> yeah woot
[16:25:16] <seb_kuzminsky> arent there things in vanilla linux that provide user/kernel shm?
[16:25:35] <seb_kuzminsky> debugfs does that
[16:26:43] <jepler> yeah
[16:27:13] <jepler> machinekit implemented something called "shmdrv"
[16:27:22] <CaptHindsight> jepler: ok, good...right before I reconfigure this hard drive
[16:35:13] <jepler> CaptHindsight: well if you still have time to gather some results .. I think isolcpus=1 =2 and =3 are the interesting cases
[16:35:26] <seb_kuzminsky> bummer, debugfs doesnt support mmap
[16:35:49] <jepler> and I'm betting =3 is best performance, meaning that on these bulldozer+ CPUs you want to isolate the other core in the module
[16:36:02] <CaptHindsight> jepler: will do, I'm going to drop Mint and Precise off the drive
[16:36:30] <CaptHindsight> looks like Wheezy and Gentoo from here on
[16:38:28] <jepler> I know I don't miss Ubuntu
[16:42:08] <CaptHindsight> isolcpus doesn't behave the same on Precise, not sure what is happening but the desktop bogs down and video playback gets really choppy with settings that were fine in Wheezy
[17:04:17] <CaptHindsight> isolcpus=3, 1ms thread 12,800, 25 uS thread 7,800, rtai kern/latency 32,400
[17:07:39] <jepler> (rtai kern/latency result should be unchanged, since the only modified component of the system is linuxcnc)
[17:10:10] <CaptHindsight> isolcpus=2, 1ms 200,000, 25uS 43,600
[17:16:36] <CaptHindsight> jepler: any other tests you like to see?
[17:17:44] <CaptHindsight> let me test isolcpus=1 brb
[17:22:45] <jepler> CaptHindsight: yes, isolcpus=1
[17:25:27] <CaptHindsight> isolcpus=1 1mS 146,000, 25uS 28,500
[17:26:08] <CaptHindsight> jepler: ^^
[17:26:11] <jepler> thank you
[17:26:22] <CaptHindsight> no problem
[17:27:06] <jepler> this seems to confirm that it's due to the bulldozer+ paired cores architecture
[17:28:21] <jepler> so the advice for anyone on bulldozer+ would be to isolate both CPUs in the pair
[17:29:00] <jepler> but there's also this general caveat that the rtai kern/latency test selects CPUs differently, so it shouldn't be used when testing isolcpus= performance
[17:29:16] <CaptHindsight> yeah, that was news to me
[17:29:50] <jepler> we could potentially fix it in linuxcnc.org's rtai package to use the same algorithm to select a cpuid to run on..
[17:30:01] <jepler> anyway, see you later. time to stir fry some tofu & veggies
[17:30:43] <CaptHindsight> after 5 here already
[17:31:10] <mozmck> cradek: I could never get my 6-core phenomII to work with the kernel I made for 10.04
[17:31:26] <mozmck> if that's what you are thinking about.
[17:33:38] <CaptHindsight> mozmck: the kernel on the 10.04 livecd?
[17:35:15] <CaptHindsight> I'm pretty sure that works on a 6-core phenomII
[17:35:20] <mozmck> Yes
[17:35:35] <mozmck> I never could get the realtime to actually work here.
[17:35:57] <CaptHindsight> I'll try it here later. I'm typing on it right now
[17:36:10] <mozmck> It would boot, but if I tried to run the latency test or linuxcnc it would just sit there at 0
[17:36:24] <mozmck> I think linuxcnc would hang.
[17:36:47] <seb_kuzminsky> mozmck: is that 6 cores with 2 hyperthreads each? what does nproc say?
[17:36:54] <seb_kuzminsky> or lshw, or cat /proc/cpuinfo
[17:36:58] <mozmck> Seems like jepler had problems with it on his 4-core too, but I don't remember for sure. I know someone else had the same problem.
[17:37:22] <mozmck> seb_kuzminsky: no, it's 6 real cores. I don't have it in my computer now.
[17:37:34] <CaptHindsight> the 10.04 ISO works great on the 4 core APU's
[17:38:14] <mozmck> ok
[17:38:38] <CaptHindsight> ah we fixed that in BIOS settings
[17:38:58] <mozmck> I have an FX-8350 8-core now. I think the cores in this thing share more stuff than the 6-core did though.
[17:39:05] <CaptHindsight> we had to turn off all the core boosting, core unlocking fancy power stuff
[17:39:52] <CaptHindsight> we has the same problems when configuring phenomII's with 3-6 cores
[17:40:04] <CaptHindsight> but they all worked
[17:40:12] <mozmck> interesting. I don't remember what all I tried. The funny thing was that there were no error messages, the realtime just didn't run.
[17:40:29] <CaptHindsight> yeah, it would just sit at 0
[17:40:50] <CaptHindsight> memleak just said the same thing
[17:41:35] <mozmck> so do you have to do the same bios modifications to run the new rtai kernel?
[17:42:14] <CaptHindsight> well we turn off anything that has to do with speed changing or powering down
[17:42:45] <CaptHindsight> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?TroubleShooting#AMD_APU_UEFI_settings
[17:43:04] <CaptHindsight> turn off any virtualization, C6 etc etc
[17:43:45] <CaptHindsight> all these tests we done with those settings
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?The_Isolcpus_Boot_Parameter_And_GRUB2#Latency_Testing
[17:44:38] <mozmck> Thanks. I haven't tried it on this machine yet, and it will not be running a machine except maybe for some testing.
[17:45:23] <mozmck> But my 6-core board might could come back as a machine controller. Hate to use it for that when it is a pretty good desktop PC!
[17:46:02] <CaptHindsight> Ideally I'd like to run Linuxcnc with GPU hardware acceleration and have the other cores for image processing
[17:46:51] <CaptHindsight> rtai on one core, the GPU doing what it's good at and the other cores for machine vision
[17:47:24] <CaptHindsight> is that too much to ask? :)
[17:47:52] <CaptHindsight> the new GPU hardware drivers clobber latency
[17:48:51] <CaptHindsight> if kernel mode settings are on it won't even run on Wheezy, just a scrambled screen
[17:49:15] <CaptHindsight> I have to install from the wheezy hybrid ISO to confirm
[17:49:38] <CaptHindsight> I use wheezy LXDE and then installed the Linuxcnc debs
[17:50:57] <CaptHindsight> the integrated GPU on the early APU's are fine with the hardware driver and KMS on
[17:52:55] <mozmck> seems like CPUs/GPUs are not getting and more RT friendly
[17:53:08] <mozmck> any more
[17:55:14] <CaptHindsight> and xenomai is not going to have the kernel API's anymore for v3
[17:55:34] <CaptHindsight> so it will slow down
[18:29:51] <CaptHindsight> mozmck: according to the preempt_rt tests at osadl the AMD A10's and the Intel i7's have the lowest latency, but we haven't been able to reproduce their results with Linuxcnc and preempt_rt
[18:30:04] <CaptHindsight> https://www.osadl.org/Latency-plot-of-system-in-rack-2-slot.qa-latencyplot-r2s7.0.html
[18:30:12] <CaptHindsight> https://www.osadl.org/Latency-plot-of-system-in-rack-0-slot.qa-latencyplot-r0s7.0.html
[18:31:12] <CaptHindsight> the Xeons do great as well
[18:58:39] <seb_kuzminsky> i added a link to the live+install email on the wlo front page
[19:02:07] <seb_kuzminsky> and i tried to clean up the Downloading page here:
http://linuxcnc.org/index.php/english/download
[19:02:55] <seb_kuzminsky> bbl
[22:23:54] <jepler> if just one person in the universe understands lut5 of course it's pcw
[22:23:58] <jepler> /nick lut5
[22:28:07] <jepler> $ python
[22:28:11] <jepler> >>> ~True
[22:28:11] <jepler> -2
[22:28:11] <jepler> WAT
[22:33:02] <skunkworks> jepler: didn't you write that?
[22:34:14] <jepler> skunkworks: well yes
[22:36:15] <skunkworks> heh
[22:36:50] <skunkworks> so I have not been following all the rtai conversations... was it figured that a certain isolcpus works the best?
[22:38:03] <jepler> skunkworks: yes, and maybe it even makes sense.
[22:38:50] <jepler> skunkworks: certain AMD CPUs, ever since their technology code-name "bulldozer", share some resources between resource pairs.
[22:39:34] <jepler> skunkworks: so if your realtime code is running on #3, then the best results come with isolcpus=2,3 (the pairs are 0,1 and 2,3)
[22:40:02] <jepler> confusingly, if you just isolate one CPU, it's better to isolate the other one in the pair -- so isolcpus=2 was second best
[22:40:36] <jepler> other differences between linuxcnc latency-test and rtai kern/latency are explained by the fact that they each request different CPUs be used
[22:40:46] <jepler> in the end, I think it is all explained
[22:41:04] <jepler> er, "share some resources between CPU pairs"
[22:41:58] <jepler> goodnight
[22:43:29] <skunkworks> jepler: very cool - thanks
[22:47:15] <skunkworks> didn't know you could isolate more than one..
[23:42:40] <seb_kuzminsky> tilde true equals minus two: sounds like a monty python song, so it all makes sense