Back
[02:12:42] <cmorley> jepler: in your added file multifilebuilder.py in the method add_from_file() there is a line:
[02:13:04] <cmorley> if self.domain is not None: builder.set_translation_domain(domain)
[02:14:04] <cmorley> I think the last 'domain' should be self.domain otherwise i get in error if self.domain is not none. Can you confirm?
[02:20:56] <cmorley> I pushed the change to new_pncconf ....
[02:21:37] <KGB-linuxcnc> 03Chris Morley 05new_pncconf bb145c4 06linuxcnc 203 commits pushed, 10355 files changed, 0319057(+), 0420099(-)
[02:23:50] <cmorley> ttyl
[07:00:23] <jepler> cmorley: quite possibly. I neglected to test multifilebuilder with non-english language.
[07:07:04] <jepler> yes, I believe that's the correct correction
[07:13:37] <skunkworks> This is wierd..
http://linuxcnc.org/index.php/english/forum/10-advanced-configuration/27368-new-trajectory-planner-testersprograms-wanted/49800
[07:14:36] <skunkworks> I got a notifacation that someone has posted in 'New Trajectory Planner - Testers/programs wanted' but it actually goes to 'cambam problems'
[07:21:04] <jepler> skunkworks: I have a feeling that a moderator moved the post to a new topic
[07:21:14] <skunkworks> ah
[07:21:17] <jepler> probably jt
[07:29:06] <jepler> cmorley: but either there's still something wrong with the way set_translation_domain works in MultiFileBuilder, or something wrong with the way stepconf calls it
[07:29:53] <jepler> cmorley: because stepconf calls it after all files have been added. if that has an effect on widgets previously added, then the right fix involves calling it on all builders in set_translation_domain -- I think
[07:34:12] <KGB-linuxcnc> 03Jeff Epler 05jepler/2.6/proposed d6bf74d 06linuxcnc 10debian/configure packaging: Debian testing requires use of tcl/tk 8.6 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d6bf74d
[07:34:12] <KGB-linuxcnc> 03Jeff Epler 05jepler/2.6/proposed 67eb4d2 06linuxcnc 10lib/python/multifilebuilder.py python: fix exception in set_translation_domain * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=67eb4d2
[07:34:20] <jepler> seb_kuzminsky: some proposed patches for 2.6 ^^
[08:09:38] <skunkworks> seb_kuzminsky, what is the minimum I need (there are a lot of debs in that directory)
[08:29:26] <cradek> if you add it as a source and run apt-get dist-upgrade I think it'll give you the right ones
[08:30:04] <skunkworks> what is it?
[08:30:05] <cradek> but I think the very minimum you need to boot is linux-image-3.4-10-rtai-686-pae_3.4.102-0linuxcnc_i386.deb
[08:30:14] <skunkworks> ok
[08:30:27] <cradek> deb
http://highlab.com/~seb/linuxcnc/rtai-debs wheezy main
[08:30:35] <skunkworks> ah
[08:48:35] <CaptHindsight> ok, another fix for AMD APU's is the bassakwards isolcpus= parameter, for a 4 core APU isolcpus=0,1,2 is the fix to keep latency the lowest along with radeon.modeset=0
[08:51:17] <CaptHindsight> wheezy with 3.4.9 (pae) rtai is ~7100nS (25uS base) with the llvmpipe driver on a 4 core, down from ~50K
[09:24:32] <jepler> is there any such thing as "runtime isolcpus"?
[09:24:50] <jepler> .. so that linuxcnc could set isolcpus=1,2,3 at startup and reset it at exit
[09:29:05] <memleak> there should be a way to write to the IPIPE interface via /proc
[09:31:31] <memleak> well.. you can disable a CPU entirely using /proc via echo 0 > /sys/devices/system/cpuX/online
[09:31:41] <memleak> err.. /sys sorry :/
[09:38:19] <memleak> i do not see a way to modify isolcpus though on the fly, only CPU hotplug.
[09:46:32] <jepler> http://elinux.org/CPU_Shielding_capability
[09:47:05] <jepler> for me as a developer, I would want to build on all my CPUs but get the benefits of isolcpus while actually running realtime code
[09:53:04] <memleak> i understand but there are limitations in the IPIPE interface. gotta work with what you get.. or write your own interface to talk to isolcpus on the fly
[10:01:21] <jepler> I guess all you have to do is run taskset -c 0-31 make -j32
[10:03:23] <jepler> after booting with isolcpus= to isolate either the highest CPU (or highest two CPUs in the case of HT on Intel?)
[10:04:30] <CaptHindsight> you need somebody with Intel hardware to test and find out
[10:05:39] <jepler> actually I think it depends on linux kernel and/or specific CPU
[10:06:44] <CaptHindsight> with RTAI 3.4.9
[10:06:57] <jepler> on i7-4930k with kernel 3.2.0, processors X and X+6 share the same core id, so they're HT siblings
[10:07:58] <jepler> on i5-3320M with linux 3.14, processors X and X+1 share the same core ID
[10:08:48] <jepler> there's a library for determining this kind of thing at runtime (I just grepped /proc) but the user would have to write the proper isolcpus= into the grub config :-/
[10:10:29] <jepler> which is fine if it's a technique an advanced user would want to use to get a few more us performance
[10:10:36] <jepler> .. but terrible if it's something all users would have to do
[10:10:55] <jepler> just default to isolcpus=1-31 and leave them only one thread for userspace by default, I guess
[10:14:44] <jepler> CaptHindsight: aha, cradek's git for building live images is
http://timeguy.com/gitweb?p=live-images.git;a=summary / git://timeguy.com/live-images.git
[10:16:40] <memleak> taskset -c 0-31 make -j32 that's hilarious xD
[10:18:13] <jepler> OK, so in my fantasy world I have a nicer machine than I really do
[10:18:21] <jepler> but saying taskset -c 0-1 make -j2 just makes me seem sad
[10:22:45] <skunkworks> seb_kuzminsky, sorry - this was after plugging in a mouse
http://pastebin.com/B3bqfD7d
[10:23:41] <jepler> [ 18.872416] usb 1-1: device not accepting address 2, error -110
[10:23:45] <jepler> no change
[10:23:48] <skunkworks> right
[10:24:05] <jepler> bummer
[10:24:06] <skunkworks> and again - the debian -rt kernel works
[10:24:16] <skunkworks> odd
[10:33:14] <cradek> seb_kuzminsky: Failed to fetch
http://linuxcnc.org/dists/wheezy/base/binary-i386/mesaflash_3.0.0_i386.deb Size mismatch
[10:33:30] <cradek> did you replace it without changing the version number?
[10:38:26] <seb_kuzminsky> skunkworks: bummer... thanks for testing :-/
[10:38:31] <seb_kuzminsky> cradek: mmmmmmmaybe
[10:38:49] <cradek> seb_kuzminsky: if so you're a bad person
[10:42:11] <seb_kuzminsky> yeah i see the same thing here
[10:42:23] <seb_kuzminsky> i know! let me consult my git log to see what i changed! ahah
[10:45:45] <cradek> jepler: do you guys want something changed in the image? I didn't succeed in reading back to find what you were talking about.
[10:59:57] <seb_kuzminsky> cradek: i did the same to truetype-tracer
[11:00:56] <seb_kuzminsky> luckily i can just git checkout the version that's right and rsync it to wlo
[11:00:59] <seb_kuzminsky> done
[11:00:59] <seb_kuzminsky> :-P
[11:01:09] <seb_kuzminsky> i should learn to be more careful about that kind of thing
[11:01:42] <cradek> that fixed it, thanks
[11:02:17] <seb_kuzminsky> i wonder if there's a lint for debian archives
[11:02:55] <CaptHindsight> with isolcpus=0,1,2 in wheezy it looks like RTAI tasks run on the isolated 4th core, but in Precise everything is running on the 4th core :/
[11:03:58] <CaptHindsight> both distros are using 3.4.9 pae RTAI
[11:05:12] <CaptHindsight> how I can I really tell in Wheezy what core real time tasks are being on?
[11:05:40] <CaptHindsight> being on/being run on
[11:05:49] <seb_kuzminsky> the precise ones were accidentally overwritten too, i just fixed them
[11:17:25] <cradek> CaptHindsight: I think there's a summary in dmesg after you stop realtime
[11:23:48] <jepler> cradek: yesterday, CaptHindsight was talking about making images with linuxcnc based on mint linux. he linked to a "howto" that uses the "copy existing CD to hard drive, modify image, turn back to ISO" workflow. I said that with debian, one can do better
[11:23:56] <jepler> cradek: and I was looking for your packaging to make the point
[11:24:01] <cradek> oh ok
[11:24:09] <cradek> yeah, that's the ubuntu way and it sucks
[11:29:01] <cradek> CaptHindsight:
[11:29:02] <cradek> [ 76.045511] CPU USE SUMMARY
[11:29:03] <cradek> [ 76.045513] # 0 -> 0
[11:29:03] <cradek> [ 76.045515] # 1 -> 23652
[11:29:31] <cradek> in dmesg, after running the kern/latency testsuite test
[11:31:10] <jepler> don't you want isolcpus=3 ?
[11:31:58] <jepler> (if so, I said a wrong isolcpus= earlier)
[11:32:37] <jepler> running in qemu -smp 4, isolcpus=3, taskset -pc $$ gives an affinity list of 0-2
[12:02:41] <jepler> CaptHindsight: AMD bulldozer+ have a HT-like design, don't they?
[12:02:51] <CaptHindsight> jepler: but RTAI's scheduler is broken so you have to do the opposite with isolcpus=
[12:03:08] <memleak> jepler, if you mean 4 cores disguised as 8 cores, no.
[12:03:18] <CaptHindsight> that is still the "fix"
[12:03:31] <seb_kuzminsky> the jessie installer was just released
[12:04:03] <jepler> memleak: I was just reading
http://en.wikipedia.org/wiki/Bulldozer_%28microarchitecture%29#Bulldozer_core
[12:04:04] <CaptHindsight> I just tried isolcpus=3 and latency is back to being bad again
[12:04:29] <jepler> > The processing core shares the early pipeline stages (e.g. L1i, fetch, decode), the FPUs, and the L2 cache
[12:04:36] <CaptHindsight> bulldozer does have virtualization but it's off in BIOS
[12:05:32] <jepler> so it feels like you'd want to mask stuff off the other "core" in the same "module", so that you don't accrue latency due to competing for instruction fetch/decode bandwidth
[12:06:26] <CaptHindsight> yes
[12:07:44] <seb_kuzminsky> looks like it's shipping with linux 3.14, which is an LTS kernel, and which is supported by ipipe, but unfortunately not by rtai
[12:09:20] <memleak> seb_kuzminsky, it wouldnt require much work to get it working with RTAI though
[12:09:52] <CaptHindsight> if everything goes well :p
[12:10:05] <seb_kuzminsky> heh yeah
[12:10:06] <memleak> you'd basically need to add 20 lines of EXPORT_SYMBOL to the kernel .patch file
[12:10:19] <jepler> CaptHindsight: It looks like the kernl/latency test in rtai binds to CPU 1, while linuxcnc binds to CPU 3 (binary.hybrid.iso running in qemu with -smp 4)
[12:10:42] <memleak> thats all new kernels from IPIPE ever need, ive bumped major kernel releases before many times.
[12:10:53] <seb_kuzminsky> it was a lot of work trying to get 3.4.87 and 3.4.96 to work, and in the end they didnt work and we gave up
[12:11:07] <memleak> 3.4.96 works here.
[12:11:09] <CaptHindsight> give me 1's and 0's and a soldering iron :)
[12:11:34] <memleak> skunkworks just has USB issues with every kernel pretty much that isnt 3.4.55
[12:11:35] <seb_kuzminsky> here too, but it crashes other testers' machines
[12:11:40] <jepler> and taskset -pc $$ prints 0-2
[12:11:49] <seb_kuzminsky> bbl
[12:11:54] <memleak> oh it did..
[12:11:56] <cradek> /* on SMP machines, we want to put RT code on the last CPU */
[12:12:08] <cradek> rtapi does this on purpose - it could just do something else if it would help
[12:12:15] <jepler> CaptHindsight: was the test which had bad latency with 4 threads and isolcpus=3 for you the rtai latency test?
[12:12:31] <jepler> cradek: I think choosing 1 is a bad idea, it's likely to be HT with 0 on Intel
[12:12:56] <CaptHindsight> jepler: running it now, bad latency with 4 threads and isolcpus=3
[12:14:09] <jepler> CaptHindsight: what linuxcnc latency do you get?
[12:14:32] <jepler> with isolcpus=3
[12:15:15] <jepler> CaptHindsight: also, cat /proc/rtai/scheduler while rtai kern/latency or linuxcnc are running, you'll see they have different CPU values
[12:15:40] <jepler> e.g., 3:8 (CPU list : bitmask) for linuxcnc and 1:2 for kern/latency
[12:16:13] <CaptHindsight> 1ms thread 260K, 25us thread ~40K
[12:16:15] <jepler> perhaps for linuxcnc.org we should change the rtai latency test to use the same algorithm to choose the core to bind to
[12:17:10] <CaptHindsight> with isolcpus=0,1,2 the 25uS thread is 7K
[12:19:07] <jepler> kern/latency calls rt_set_runnable_on_cpus with the argument 3 if SMP
[12:19:13] <jepler> the comment claims this means that it is runnable on all CPUs
[12:21:10] <jepler> CaptHindsight: are you running the wheezy kernel from linuxcnc.org or something else?
[12:22:53] <CaptHindsight> jepler: yes it's the wheezy from linuxcnc.org
[12:23:36] <CaptHindsight> now we are going to try isolcpus=1,2,3 since that what memleak said worked for him :/
[12:28:18] <CaptHindsight> works great as well isolcpus=1,2,3 is about the same as isolcpus=0.1.2
[12:29:59] <CaptHindsight> isolcpus=1,2,3 25us thread 5342, 1ms thread 10788
[12:31:45] <jepler> what about isolcpus=2,3 ?
[12:31:56] <CaptHindsight> lets try
[12:33:39] <jepler> afk
[12:38:35] <CaptHindsight> jepler: nearly identical latency results with isolcpus=2,3 25us thread 4556, 1ms thread 10551
[13:55:09] <cradek> not sure how I feel about
http://linuxcnc.org/index.php/english/forum/9-installing-linuxcnc/28216
[13:55:10] <jepler> (0,1,2), (1,2,3) and (2,3) give broadly similar favorable results? I am having trouble fitting this into any sensible explanation
[13:56:31] <jepler> cradek: I don't want the linuxcnc forum moderators to be in the business of moderating people's opinions
[13:56:46] <cradek> yeah - I wasn't considering that
[13:57:14] <cradek> I wish he had said what software they are distributing and what problems he has with it
[13:57:36] <cradek> it could still be emc1 running mini. who knows.
[13:58:26] <cradek> and they may still be using non-chopping unipolar stepper drivers
[13:59:01] <cradek> ah heck, I didn't know joe died
[13:59:37] <jepler> :-/
[14:00:53] <jepler> it looks like in 2011 they started shipping Hardy; the UI they show is Mini.
http://www.sherline.com/CNCinstructions.htm http://www.sherline.com/CNCinst6.0.htm
[14:01:12] <cradek> their instructions say "EMC2 v6.00" which isn't a think I'm aware of existing
[14:01:28] <jepler> a screenshot down the second page has a bird on an orange background
[14:03:29] <cradek> if you turn the handwheels faster than 1 rotation per second you'll burn out their driver board
[14:04:37] <cradek> NOTE: Do not enter a value higher than 100 for the Feed Override, as the program will stop and you will get the error message "axis 0* following error."
[14:04:49] <cradek> so it's very old and was always misconfigured
[14:04:53] <cradek> that's sad
[14:06:22] <CaptHindsight> jepler: so isolcpus=3 or no setting has poor latency
[14:08:59] <jepler> CaptHindsight: and in each configuration where you get good behavior, you get good behavior from the linuxcnc latency-test *and* the rtai kern/latency test? Or are you only testing one or the other?
[14:09:55] <CaptHindsight> so far I have only tested with the linuxcnc latency-test
[14:10:10] <CaptHindsight> I'll can try the other next
[14:12:19] <CaptHindsight> also Wheezy LXDE needs radeon.modeset=0 or you'll never get a login screen, it doesn't hard lock you just junk on the screen, it never syncs
[14:17:16] <jepler> CaptHindsight: Do you mean the desktop that is on the linuxcnc.org iso? If so, that's xfce.
[14:20:49] <CaptHindsight> jepler: no, I installed linuxcnc after installing wheezy from the LXDE ISO
[14:20:55] <jepler> skunkworks_: is your refrigerator running?
[14:21:51] <CaptHindsight> rtai kern/latency test with isolcpus=2,3 latency is ~32K
[14:25:10] <jepler> CaptHindsight: and with isolcpus=0,1 ?
[14:26:17] <jepler> I want some rule that makes sense, in the case that it turns out linuxcnc latency-test is running on core 3 and rtai kern/latency is running on core 1
[14:27:11] <jepler> except isolcpus=0,1,2 giving good results with linuxcnc latency-test doesn't fit into any pattern I can fathom
[14:27:22] <jepler> except that "2" was common to all of them
[14:28:32] <jepler> so maybe try linuxcnc latency-test with isolcpus=2 too
[14:31:41] <CaptHindsight> jepler: isolcpus=0,1 is the same as isolcpus=2,3
[14:32:43] <CaptHindsight> memleak just left but RTAI did break how it interprets isolcpus=
[14:32:43] <jepler> CaptHindsight: can you install package hwloc-nox, run hwloc-ls, and pastebin the result?
[14:32:58] <CaptHindsight> sure
[14:33:56] <jepler> CaptHindsight: so for isolcpus=0,1 and isolcpus=2,3, rtai kern/latency test is FAIL ?
[14:41:26] <skunkworks_> jepler, heh - yes. It was a few that failed.. (didn't blow - acutally opened up on one end of the fuse)
[14:42:15] <CaptHindsight> jepler:
http://pastebin.com/sEKxA1dH
[14:42:43] <CaptHindsight> jepler: isolcpus=0,1 and isolcpus=2,3, rtai kern/latency test is ~32K
[14:52:33] <CaptHindsight> with isolcpus=1,2,3 that had the best linuxcnc latency-test results, rtai kern/latency test is also ~32K
[14:52:33] <jepler> so hwloc knows that the cores are associated in pairs with modules, similar to how on a HT system it knows that threads are associated with cores
http://pastie.org/9471002
[14:53:11] <jepler> CaptHindsight: so all the rtai kern/latency results you've seen so far are markedly worse than the best linuxcnc latency-test results?
[14:55:49] <CaptHindsight> jepler: linuxcnc latency-test with the best isolcpus= settings are ~7K base thread and ~32K with rtai kern/latency
[15:00:29] <skunkworks_> *fuse
[15:14:31] <seb_kuzminsky> Schooner requested i enable the RTAI serial driver, so there's a new rtai-modules package if anyone wants to test it before i push it to wlo:
[15:14:34] <seb_kuzminsky> deb
http://highlab.com/~seb/linuxcnc/rtai-debs wheezy main
[15:14:47] <CaptHindsight> hmm with isolcpus=3 it's the same ~32K with rtai kern/latency as all the other settings but linuxcnc latency-test is also ~32K base but really bad for the 1ms thread ~160K
[15:15:03] <seb_kuzminsky> 3.9.265.gd99something
[15:16:57] <CaptHindsight> jepler: so in summary rtai kern/latency is ~32K no matter what isolcpus setting tried
[15:18:18] <CaptHindsight> jepler: the linuxcnc latency-test is best with isolcpus=0,1,2 or 1,2,3 or 1,2 and worst with no setting or isolcpus=3
[15:18:35] <jepler> CaptHindsight: try linuxcnc latency-test with isolcpus=2
[15:19:25] <CaptHindsight> isolcpus=3 also has the worst 300K 1ms thread latency
[15:26:04] <CaptHindsight> jepler: isolcpus=2 linuxcnc latency-test ~7k base, 13k servo, rtai kern/latency is ~32K
[15:28:02] <jepler> CaptHindsight: so for linuxcnc, isolcpus=<set including 2> gives best performance?
[15:29:05] <CaptHindsight> isolcpus=0,1 also was good
[15:29:50] <CaptHindsight> isolcpus=3 and no settings are the worst
[15:30:13] <CaptHindsight> worst for the linuxcnc latency-test
[15:31:08] <CaptHindsight> rtai kern/latency test always is ~32K no matter what isolcpus= is set to
[15:32:32] <jepler> boy, I can't make sense of all the data you gathered
[15:33:57] <CaptHindsight> does the linuxcnc latency-test have a different affinity than RTAI?
[15:34:05] <jepler> yes
[15:34:38] <jepler> linuxcnc tries to bind all RT tasks to the highest cpuid
[15:35:09] <jepler> n = NR_CPUS-1;
[15:35:09] <jepler> while ( ! cpu_online(n) ) {
[15:35:09] <jepler> n--;
[15:35:09] <jepler> }
[15:35:09] <jepler> rtapi_data->rt_cpu = n;
[15:35:12] <jepler> ...
[15:35:17] <jepler> retval = rt_task_init_cpuid(ostask_array[task_id], wrapper, task_id,
[15:35:17] <jepler> stacksize, prio, uses_fp, 0 /* signal */, rtapi_data->rt_cpu );
[15:35:50] <jepler> so I assume that in your case, NR_CPUS is 4 so n starts with 3, and cpu_online(3) is true, so rtapi_data->rt_cpu gets 3
[15:37:27] <jepler> I was entertaining the idea that maybe rtai counts CPUs as 1-based, so that isolcpus #3 would be rtai cpuid 2
[15:37:30] <jepler> or vice versa
[15:37:57] <jepler> anyway, rtai kern/latency has
[15:38:03] <jepler> #define RUNNABLE_ON_CPUS 3 // 1: on cpu 0 only, 2: on cpu 1 only, 3: on any;
[15:38:06] <jepler> #define RUN_ON_CPUS (num_online_cpus() > 1 ? RUNNABLE_ON_CPUS : 1)
[15:38:14] <jepler> ...
[15:38:14] <jepler> rt_set_runnable_on_cpus( /* select on which CPUs the task is */
[15:38:17] <jepler> &thread, /* allowed to run */
[15:38:20] <jepler> RUN_ON_CPUS
[15:38:23] <jepler> );
[15:38:54] <jepler> the comment aside, I think 3 actually means CPU 0 or 1 (_cpus is a bitmask, _cpuid is a number)
[15:39:24] <CaptHindsight> I'll have to ask memleak again how exactly the scheduler in RTAI is broken since what should be isolcpus=3 for a 4 core cpu is now wrong, somehow things got inverted
[15:39:47] <jepler> it can't simply be inverted, because some of the sets that worked best *included* 3
[15:40:25] <CaptHindsight> yeah, thats where I'm not clear, i just recall that somebody got it backwards in some way
[15:40:42] <jepler> anyway, rt_set_runnable_on_cpus is a bit confusing to me:
[15:40:49] <jepler> cpuid = get_min_tasks_cpuid();
[15:40:49] <jepler> if (!test_bit(cpuid, &run_on_cpus)) {
[15:40:49] <jepler> cpuid = ffnz(run_on_cpus);
[15:40:49] <jepler> }
[15:40:49] <jepler> rt_set_runnable_on_cpuid(task, cpuid);
[15:40:59] <jepler> but as you can see, it delegates to the _cpuid version of the function
[15:41:08] <CaptHindsight> whats the command to mark this in the logs?
[15:41:33] <jepler> I think it says: find the cpuid with the fewest tasks. if that's in the set of CPUs, use that cpuid. Otherwise, find the first nonzero bit in run_on_cpus and use that
[15:41:55] <jepler> in any case, you can see that the CPU selection algorithm is *different* :-P
[15:42:46] <jepler> while actually running kern/latency and looking at /proc/rtai/scheduler, the CPU column is reported as 1:2
[15:43:11] <jepler> while actually running linuxcnc latency-test and looking at /proc/rtai/scheduler, the CPU column is reported as 3:8
[15:43:34] <jepler> I believe this is indicating in the case of kern/latency that it's running on (zero-based) CPU #1, AKA mask 0x2
[15:43:44] <jepler> and linuxcnc is running on (zero-based) CPU #3, AKA mask 0x8
[15:44:29] <jepler> so to that extent, it seems like both sets of code are having the effect I think they do
[15:44:53] <jepler> this is with the CD image booted in qemu -smp 4, commandline isolcpus=3
[15:45:35] <jepler> (of course, all the latency results are *bad*, it's a VM)
[15:47:07] <jepler> the /proc values come from
[15:47:08] <jepler> task->runnable_on_cpus, // cpuid,
[15:47:08] <jepler> task->lnxtsk ? CPUMASK((task->lnxtsk)->cpus_allowed) : (1 << task->runnable_on_cpus),
[16:01:40] <CaptHindsight> isolcpus=1 linuxcnc latency-test base 52K, servo 98K, rtai kern/latency is ~32K
[16:11:03] <CaptHindsight> isolcpus=0 linuxcnc latency-test base 30K, servo 75K, rtai kern/latency is 4300, !? why does this isolcpus=0 make the only difference and lower the rtai kern/latency to only `4K from ~32K?
[16:12:20] <CaptHindsight> jepler: isolcpus=0 has made the only difference to rtai kern/latency and has lowered it to 4K from 32K compared to all the other tests
[16:13:12] <CaptHindsight> at the same time linuxcnc latency-test is worse. Up to 30K for the base from 7K
[16:15:28] <jepler> but review above, where I show that they are trying to run on different CPUs
[16:15:57] <jepler> it's no surprise to me that they behave best for different isolcpus settings
[16:16:08] <jepler> but the specific settings that make them behave best still baffle me
[16:18:26] <CaptHindsight> me to
[16:26:03] <jepler> that 0,1 and 2,3 both give good results for linuxcnc kills every theory I have imagined
[16:32:56] <CaptHindsight> that's it for todays latency vs isolcpus settings tests
[16:34:01] <jepler> CaptHindsight: thanks for all your testing
[16:34:15] <CaptHindsight> I have to go mix some chemicals or something else non-software :)
[16:34:21] <jepler> my last suggestion would be to toss up a page on the wiki with your findings, because they're scattered all through three+ hours of conversation
[16:34:32] <jepler> chemical mixture suggestion: bourbon; vermouth; bitters
[16:35:04] <CaptHindsight> I like islays neat splash of water
[16:35:47] <jepler> they don't pay me enough to afford a quality whisky, so I have to have mixed drinks
[16:35:50] <CaptHindsight> my logs and scroll back should have it, and somebody has a logger
[16:36:39] <CaptHindsight> but Manhattans are my holiday season favorite
[16:37:43] <jepler> ah well sometime when it's cold I'll channel my mixologist friend and we can argue over the ratio of bourbon to vermouth
[16:47:23] <andypugh> Someone on the forum has just poiinted out that the new LiveDVD isn’t particularly easy to find.
[16:47:41] <Tom_shop> i had no problems finding it
[16:47:49] <andypugh> It’s about 3 long pages and clicking just the right links, including a trip to Gmane to get it.
[16:48:19] <andypugh> Tom_shop: Try finding it from the “Download” link on the web site.
[16:48:52] <Tom_itx> oh i bet i now why it was so easy...
[16:49:04] <Tom_itx> jepler pointed me to the 'special' page :)
[16:50:22] <Tom_itx> it says it's a 'temporary' address
[16:50:50] <Tom_itx> andypugh, just post this link there:
http://article.gmane.org/gmane.linux.distributions.emc.user/52401
[16:51:26] <andypugh> The Download page says “nstructions to get the 2.6 LiveCD are here:
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Hybrid_Iso” but that simply isn’t true.
[16:52:04] <andypugh> Yeah, I gave the guy the link. The point is that you can’t get there from the “Download” page by the obvious route
[16:52:23] <seb_kuzminsky> the www.linuxcnc.org webpage should make it super easy, i agree
[16:52:26] <Tom_itx> true, those are the 'turn n burn' links
[16:53:11] <seb_kuzminsky> i just got write access to wlo, i'll try to figure out how to update it to make it easier to find the live+install cd
[16:53:15] <andypugh> You actually have to go to the “Upgrade” page, read half way down, follow a link to Gmane, then from there get directed back to LinuxCNC.org
[17:19:58] <seb_kuzminsky> cradek: do you think the live+install cd is ready to graduate from its "experimental" status to the recommended best way to make fresh 2.6 installs?
[17:45:09] <cradek> sure
[17:45:43] <cradek> other than the kernel problem with skunkworks's usb I don't know of anything weird. even with that, it's probably the best option we currently have.
[17:59:08] <seb_kuzminsky> John Bradshaw reports that 3.4-9-rtai-686-pae crashes his machine that ran fine with lucid's rtai kernel (dgarr has a machine like that too) (bug #388)
[17:59:22] <seb_kuzminsky> but even so, i agree this is our best option at the moment
[18:01:16] <cradek> well that sucks
[18:02:27] <cradek> python: swrast/s_renderbuffer.c:588: map_attachment: Assertion `srb->Map' failed.
[18:02:30] <cradek> /usr/bin/linuxcnc: line 766: 12668 Aborted (core dumped) $EMCDISPLAY -ini "$INIFILE" $EMCDISPLAYARGS $EXTRA_ARGS
[18:02:39] <cradek> this has nothing to do with rtai or dgarr's problem
[18:02:48] <cradek> it's probably just bogus opengl
[18:03:03] <cradek> [ 295.500017] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung
[18:03:06] <cradek> [ 295.500030] [drm] capturing error event; look for more information in /debug/dri/0/i915_error_state
[18:03:45] <cradek> trying to overwrite '/etc/udev/rules.d/99-rtai.rules', which is also in package rtai-modules-2.6.32-122-rtai 3.8.1-linuxcnc1
[18:04:01] <cradek> looks like he tried to upgrade the OS instead of reinstalling
[18:04:20] <cradek> to say the least, I don't recommend doing that
[18:05:29] <cradek> #6 0xb55b3e04 in _swrast_map_renderbuffers () from /usr/lib/i386-linux-gnu/dri/libdricore.so
[18:06:14] <seb_kuzminsky> i have a machine that gets 915 warnings in dmesg but otherwise works
[18:06:32] <cradek> I don't see where that wiki page recommends upgrading the os like that
[18:06:48] <seb_kuzminsky> it doesnt
[18:06:54] <seb_kuzminsky> but i dont see why it shouldnt work
[18:07:08] * cradek shrugs
[18:07:26] <cradek> looks like it gives a system with broken opengl
[18:07:39] <seb_kuzminsky> i tried it in a VM and it worked, except the rtai-modules collision, which i fixed in the 3.9.265 version i built out earlier today
[18:07:42] <cradek> considering unity compositing etc that's no big surprise
[18:08:32] <cradek> that's cool if you made the upgrade work, though
[18:09:17] <seb_kuzminsky> it already nearly worked
[18:09:27] <seb_kuzminsky> it was easy to fix the last tiny bit
[18:09:47] <cradek> neato
[18:50:07] <CaptHindsight> jepler:
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?The_Isolcpus_Boot_Parameter_And_GRUB2 bottom of page, now I'm seeing a pattern
[18:53:17] <skunkworks> http://linuxcnc.org/index.php/english/forum/9-installing-linuxcnc/28164-unable-to-find-a-live-file-system-gigabyte-j1800?limitstart=0
[18:53:48] <skunkworks> same motherboard same problem.. (isn't just me :) )
[18:54:50] <KGB-linuxcnc> 03Jeff Epler 052.6 6cd5eac 06linuxcnc 10debian/configure packaging: Debian testing requires use of tcl/tk 8.6 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6cd5eac
[18:54:51] <KGB-linuxcnc> 03Jeff Epler 052.6 4d120e8 06linuxcnc 10lib/python/multifilebuilder.py python: fix exception in set_translation_domain * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4d120e8
[18:55:02] <seb_kuzminsky> jepler: thanks, merged
[18:56:30] <seb_kuzminsky> CaptHindsight: i've seen you refer to the new rtai kernel as "3.4.9" a couple of times, but that's not accurate
[18:57:09] <seb_kuzminsky> unfortunately the correct moniker is a bit of a mouthfull: 3.4-9-rtai-686-pae, version 3.4.55-3linuxcnc
[18:57:30] <seb_kuzminsky> just trying to minimize future confusion
[18:57:34] <CaptHindsight> close enough
[18:58:02] <seb_kuzminsky> if you insist on abbreviating it, please at least call it 3.4-9 instead of 3.4.9
[18:58:05] <CaptHindsight> ok, I'll change to that moniker
[18:58:13] <seb_kuzminsky> the 9 is not the same kind of thing as the 3.4
[18:58:16] <seb_kuzminsky> thanks!
[18:58:22] <CaptHindsight> no problem
[18:59:34] <CaptHindsight> seb_kuzminsky:
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?The_Isolcpus_Boot_Parameter_And_GRUB2
[19:00:36] <seb_kuzminsky> now it's too long, can you shorten it?
[19:00:38] <seb_kuzminsky> j/k
[19:00:39] <seb_kuzminsky> thanks
[19:02:09] <CaptHindsight> heh, one more reboot and I'm done :)
[19:02:22] <CaptHindsight> 10 hours testing
[19:02:50] <seb_kuzminsky> One. One reboot.... Ah, ah, ah!
[19:08:33] <CaptHindsight> now you can see how the different latency tests handle the change to isolcpus
[19:10:24] <CaptHindsight> I have to do isolcpus=2 over, seem to have lost my results
[19:10:43] <seb_kuzminsky> nice, that table makes it easy to see the data
[19:10:46] <seb_kuzminsky> bbl
[19:11:10] <seb_kuzminsky> guess 0 is the magic number
[19:11:59] <andypugh> Isn’t it Karmic Koala? (The Wiki page says Karmic Karma)
[19:23:15] <CaptHindsight> all results are in
[19:23:40] <andypugh> The judges seem inconsistent :-)
[21:07:35] <jepler> seb_kuzminsky: thank you!
[21:08:48] <jepler> CaptHindsight: with all the numbers in, I'm back to thinking the best theory is: isolcpus numbers OR rtai cpuid numbers are off by one
[21:09:07] <jepler> CaptHindsight: I am confident that rtai kern/latency intends to run on CPU 1, and linuxcnc on CPU 3
[21:09:18] <jepler> CaptHindsight: but the best results for kern/latency come when CPU 0 is isolated
[21:09:28] <jepler> and the best results for linuxcnc latency-test come when CPU 2 is isolated
[21:13:47] <jepler> this is an interesting development:
http://www.parallax.com/microcontrollers/propeller-1-open-source
[21:13:54] <jepler> > The Propeller 1 (P8X32A) is now a 100% open multicore microcontroller, including all of the hardware and tools: Verilog code, Spin interpreter, PropellerIDE and SimpleIDE programming tools, and compilers. The Propeller 1 may be the most open chip in its class.
[21:19:00] <cradek> neato!
[21:54:44] <skunkworks> I had a mdadm array I made a few years ago with 2tb drives (6) before I knew / or fdisk knew about the 'advanced formated' drives. They where all miss-aligned. I have been removing each drive and rebuilding the array with correctly re-partitioned drives. Each time the rebuild speed increases. It started at about 20mb/sec and it is up to 42mb/sec and I still have 2 drives to go.
[21:55:30] <skunkworks> really wasn't a big deal as it was offsite backup. so it was still faster than the internet connection.
[22:04:45] <jepler> whoops, pressed C-A-D on the wrong computer
[22:09:34] <jepler> anyway, with uspace on a 2-core system, I didn't find it made much difference to specify isolcpus=. specifying idle=poll seemed to help latency a bit. but I did not run any extended tests / stressing while testing
[22:13:53] <skunkworks> I haven't used isolcpus in a while.. I should try it.. But I do find better latency with idle=poll.. like it can help from 30us latency down to 10us
[23:39:49] <CaptHindsight> I can try a 2 core APU on the same board later today/tomorrow