Back
[07:07:19] <jepler> seb_kuzminsky: while it's handy during development to have a mix, I'm not sure it's something that has to ultimately work
[07:07:27] <jepler> seb_kuzminsky: for the reasons you outline, it's messy business
[08:27:57] <cradek> I don't think a particular gui needs to work in half-converted state
[08:28:07] <cradek> that is an unnecessary extra burden
[09:08:33] <seb_kuzminsky> y'all are ever the voice of reason, to my ocd
[09:09:08] <seb_kuzminsky> i do like having the tests pass during development though
[09:38:10] <cradek> it's sure easy to go too far
[10:08:47] <memfrob> one of these days i'd like to trim IPIPE down to it's core and figure out exactly what from IPIPE, RTAI needs.
[10:09:17] <memfrob> there is a lot of xenomai specific stuff in IPIPE that RTAI doesn't touch at all.
[10:11:42] <jepler> memfrob: that sort of 'trimming' is what seb_kuzminsky was getting at when he talked about building LinuxCNC right on top of IPIPE without RTAI involved
[10:11:53] <jepler> there are a lot of RTAI features not used by LinuxCNC, after all
[10:12:10] <jepler> and, yes, probably IPIPE features not used by RTAI
[10:28:17] <seb_kuzminsky> i'm worried because i think none of us knows enough about x86 architecture to make a good realtime kernel
[10:28:41] <seb_kuzminsky> i'm hopeful that the folks who specialize in that kind of thing, the rtai and ipipe core devs, know what they're doing and we can piggyback on them
[10:32:27] <pcw_home> I still wonder about the long latencies that are missed by the latency test with RTAI
[10:32:28] <pcw_home> thread dispatch latency might be good but if random processes delay hal functions
[10:32:30] <pcw_home> the dispatch latency doesn't mean much
[10:33:39] <seb_kuzminsky> it might be worth making a bug report on the rtai list about that
[10:34:10] <pcw_home> (plot motion-controller time on a D525, move the mouse and watch the hash)
[10:34:19] <seb_kuzminsky> :-(
[10:35:02] <pcw_home> Maybe the latency test should do some FP operations before recordong the time
[10:35:50] <pcw_home> (im just guessing FP operations are a cause)
[10:35:58] <seb_kuzminsky> does the d525 lack sufficient l1/l2 cache? maybe the latency is due to cache eviction, and not something rtai can really fix?
[10:36:06] <seb_kuzminsky> pmc would tell us
[10:36:11] <seb_kuzminsky> (i'm just guessing too!)
[10:37:07] <pcw_home> it might be, Theres some strange behavior in hm2_eth latency on preemt_rt that seems cache related
[10:37:39] <pcw_home> (the faster you run the servo thread, the better the latency gets)
[10:38:02] <seb_kuzminsky> isolcpus should remove the cache pressure from external (non-rtai) sources
[10:39:35] <pcw_home> Ill have to try that on the J1800/RTAI (IsolCPUS seems to make preemt_rt worse)
[10:41:52] <pcw_home> The main thing i have learned with these random latency spikes in the middle of linuxcnc thread is the faster the CPU, the better
[10:43:11] <seb_kuzminsky> i should be more precise here
[10:43:13] <pcw_home> and that theres not much correlation between latency test results and mid linuxcnc thread execution delays
[10:43:32] <seb_kuzminsky> isolcpus will remove the cache pressure if you isolate all the vcpus that share the cache
[10:45:43] <seb_kuzminsky> i think hwloc will show this info
[10:47:59] <seb_kuzminsky> here's the output of 'lstopo', from the hwloc-nox package, run on my development laptop:
[10:48:04] <seb_kuzminsky> http://pastie.org/9698128
[10:48:26] <seb_kuzminsky> it shows i have 4 cores, each with 2 vcpus, and each core has its own L1 and L2
[10:48:39] <seb_kuzminsky> so isolcpus would have to take a whole core to relieve cache pressure
[10:48:41] <seb_kuzminsky> bbl
[11:19:31] <seb_kuzminsky> ok, the new rtai kernel debs are up on linuxcnc.org
[11:20:00] <seb_kuzminsky> linux-image-3.4-9-rtai-686-pae version 3.4.55-4linuxcnc
[11:20:09] <cradek> yay!
[11:20:23] <cradek> I'll start rolling a new iso
[11:20:40] <seb_kuzminsky> i'm really glad brian morel went and found that baytrail usb patch and got it all integrated
[11:20:48] <seb_kuzminsky> cool cradek
[11:21:04] <cradek> yeah that broken usb was a real problem
[11:21:12] <seb_kuzminsky> do you think we should give the new live-cd a more descriptive name?
[11:21:29] <pcw_home> Thats great, the JXXXX cards look like the new D525
[11:22:38] <cradek> yeah, we should probably rename it
[11:23:46] <seb_kuzminsky> i guess the new live cd will have 2.6.4 on it, that's kinda cool too
[11:24:29] <cradek> hm, a lot of upstream changes in live-build
[11:25:03] <seb_kuzminsky> ruh roh
[11:25:53] <cradek> molly-guard, lxc-server
[11:26:03] * cradek whistles innocently and starts the build
[11:31:18] <jepler> what's an lxc-server?
[11:33:58] <cradek> I think they put it in and then took it back out, whatever it is
[11:56:43] <jepler> so an lxc-server is like something you could do the hokey pokey with
[11:56:50] <jepler> that helps, thanks
[11:58:12] <skunkworks> another new hard drive bad.. wow - lately has been bad.
[11:58:14] <seb_kuzminsky> heh
[12:10:20] <pcw_home> No sure I would use anything but a SSD for linuxcnc since decent ones are sub $50 now
[12:11:13] <cradek> I had one fail (well, start failing SMART tests) this morning
[12:11:30] <cradek> my very polite machines send an email when that happens
[12:11:49] <pcw_home> The manufacturers MTBF figures of hard drives are laughable
[12:12:30] <pcw_home> 250K hours, you bet (ignoring the 10% that die in 6 months)
[12:13:53] <jepler> weird, a bunch of pins on this ssd are brought out to a nonstandard edge (?) connector. testing/burn-in rig?
http://www.newegg.com/Product/Product.aspx?Item=N82E16820208823
[12:14:36] <pcw_home> that is funny
[12:16:33] <pcw_home> maybe controller flashing?
[12:16:43] <jepler> pcw_home: any specific sub-$50 SSD you recommend?
[12:19:02] <pcw_home> I'm using a 32G Transcend at the moment I think it was 49.95
[12:19:29] <pcw_home> (2.5" mechanicals)
[12:19:32] <skunkworks> seb_kuzminsky, little late but - installed the hybrid iso - then apt-get upgrade. Installed the new kernel and usb's worked
[12:22:37] <seb_kuzminsky> haw yea
[12:23:38] <cradek> untested new iso is on l.o
[12:23:55] <cradek> I'm downloading it to try right after lunch
[12:24:07] <cradek> (yay zsync)
[13:00:28] <skunkworks> It looks like with the J1900's the best latency is when isolcpus=2,3 and idle=poll
[13:00:40] <skunkworks> I will let it run over night.
[13:00:45] <skunkworks> <10us
[13:13:11] <seb_kuzminsky> skunkworks: what's lstopo say on that machine? are vcpus 2 & 3 the hyperthreads on the last core?
[13:13:52] <seb_kuzminsky> (and does the isolcpus kernel argument use the same vcpu mappings as rtai, and do they both agree with lstopo?)
[13:18:59] <pcw_home> The Baytrails dont have hyperthreading
[13:20:40] <pcw_home> J1800 is 2 core 2.4 GHz , J1900 is 4 core 2 GHz, J2950 is 4 core 2.4 GHz
[13:29:48] <seb_kuzminsky> hmm
[13:30:27] <seb_kuzminsky> i see that you are right
[13:31:15] <seb_kuzminsky> i'd like to see lstopo from one of those machines
[13:32:57] <seb_kuzminsky> normally each core has its own L1 and L2, and all the cores on a socket share L3
[13:33:30] <seb_kuzminsky> if the baytrails are that way too then i dont understand the result the skunkworks reported
[13:33:46] <pcw_home> I can do that in a bit (on a J1800)
[13:34:10] <seb_kuzminsky> there sould be no cache effect of isolating a second vcpu, because it's on a separate core and so doesn't share L1 or L2 with any other vcpus
[13:34:14] <seb_kuzminsky> thanks pcw_home
[13:43:00] <bjmorel_work> What is your guys procedure for running latency test? Surfing around on youtube / GLXGears etc.? I can run some more tests when i Get home tonight.
[13:43:12] <seb_kuzminsky> hi brian
[13:43:38] <seb_kuzminsky> that's about what i do for a quick and easy test
[13:46:28] <cradek> new live+install image with 3.4.55-4linuxcnc kernel and linuxcnc 2.6.4 is available at the usual place
[14:26:17] <PCW> J1800 lstopo:
[14:26:18] <PCW> http://pastebin.com/rkDY2UX4
[14:48:46] <seb_kuzminsky> awesome, thanks cradek
[14:49:49] <cradek> thanks more to bjmorel and you
[14:50:44] <seb_kuzminsky> zsync is good stuff
[14:51:43] <seb_kuzminsky> Read binary.hybrid.iso. Target 78.9% complete.
[15:06:21] <seb_kuzminsky> PCW: interesting, L2 is per socket, not per core
[15:06:30] <seb_kuzminsky> i guess that makes sense if each core only has one hyperthread
[15:20:15] <cradek> yeah, zsync works great
[15:20:26] <cradek> I put it out there using zsync, too
[15:44:35] <seb_kuzminsky> what is schedrmt?
[15:44:49] <seb_kuzminsky> it's a user interface...
[15:45:36] <seb_kuzminsky> looks like it does the same thing as linuxcncrsh, more or less
[15:46:30] <seb_kuzminsky> plat
[15:46:31] <seb_kuzminsky> Returns the platform for which this was compiled, e.g., linux_2_0_36
[15:47:32] <seb_kuzminsky> it's some kind of network-controller gcode running interface
[15:47:35] <seb_kuzminsky> bizarre
[15:47:51] * seb_kuzminsky glances slyly at 'git rm'
[15:47:53] <cradek> smells like emc1 remnants
[15:47:57] <jepler> it's something somebody wanted in linuxcnc because we don't do enough to publicize that you can write out-of-tree user interfaces using the C++ or Python APIs
[15:48:43] <jepler> schedrmt is '09, way way after emc1
[15:49:05] <jepler> it's by the linuxcncrsh author
[15:49:57] <seb_kuzminsky> i see
[15:51:16] <seb_kuzminsky> i'm gonna pretend i didn't look under that rock
[15:57:35] <jepler> iirc cradek & I originally developed AXIS to be built only alongside an emc1 source tree .. there was no emc-dev package, so you couldn't add it on to the BDI version of emc1.
[15:58:13] <jepler> paul_c had some way he built an axis deb that he refused to share, right there at the tail end of the time he maintained bdi
[15:58:47] <jepler> anyway, we got cozy with people like jmk who were active on emc2 and jumped at the chance to put our source in the main CVS
[15:58:57] <jepler> which was a no-brainer by that time, because it was clear emc1 was a dead end
[15:59:25] <jepler> so it's a bit disingenuous of me to say that all UIs should stay out of the main linuxcnc source tree, since I wanted it otherwise for axis
[15:59:47] <jepler> but on the other hand, the landscape of building a UI outside of linuxcnc is totally different now than it was then. Pretty sure we moved AXIS in before emc2 even did debs..
[16:01:09] <seb_kuzminsky> i can understand how it's more convenient for users & developers if the UI is in the linuxcnc tree and distributed with our debs
[16:01:27] <jepler> except when it stinks because our idea of a release cycle is inappropriate for their project
[16:01:27] <seb_kuzminsky> i dont mind it, as long as it's useful
[16:03:51] <seb_kuzminsky> hmm, yeah
[16:04:19] <jepler> but to do what I am advocating, we'd need stuff we don't have now
[16:04:34] <jepler> ways for Bob UI Builder to get his deb on wlo
[16:04:46] <seb_kuzminsky> they can always ignore the in-tree version of the UI and build their own - the in-tree development model degrades gracefully to the out-of-tree model
[16:05:19] <jepler> who knows, we might use submodules for UIs that we decide to package on wlo
[16:05:42] <seb_kuzminsky> i've not been happy with the submodule workflow we use at work
[16:06:25] <seb_kuzminsky> if linuxcnc-dev was in ubuntu, Bob could use a launchpad ppa
[16:06:31] <jepler> that's true
[16:06:47] <jepler> same for any old deb repo, minus the UI
[16:07:24] <seb_kuzminsky> not just UI - launchpad builds the debs for you, doesn't it?
[16:07:30] <seb_kuzminsky> that's not nothing
[16:08:27] <seb_kuzminsky> maybe that's the major value-add to having your UI in our tree at the moment: we do the building & packaging & distributing for you
[16:08:56] <seb_kuzminsky> much like what we do for out-of-tree utilities like mesaflash and truetype-tracer
[16:18:07] <jepler> yeah
[16:18:42] <jepler> until I remember we support more than one distro version & cpu architecture & kernel at a time, it seems easier
[16:18:56] <jepler> though an OOT UI shouldn't depend on any of those details but CPU architecture
[16:20:31] <bjmorel_work> One of the projects I hope to someday work on is clarifying the build dependancies of the various parts of the source tree. Always felt like there was a lot of package dependencies needed for the build.
[16:21:07] <bjmorel_work> seb_kuzminsky: Didn't you have a new configure script you were working on at one point?
[16:21:09] <seb_kuzminsky> the pbuilder/makefile/bull-in-a-china-shop thingy i use to build mesaflash & ttt could be adapted to build random git trees against linuxcnc-dev, for some combination of distros & architectures
[16:21:45] <seb_kuzminsky> bjmorel_work: the branch is called seb/master/new-deb-configure
[16:22:07] <jepler> btw I won't be around much for the next week
[16:22:17] <seb_kuzminsky> i was all excited about it but then jepler poked a hole in the tcl/tk change i made, and my i deflated
[16:22:21] <skunkworks_> sure is weird seeing 2.8.0 in master...
[16:22:30] <seb_kuzminsky> jepler: doing something fun?
[16:23:31] <jepler> seb_kuzminsky: visiting some friends, hopefully getting at least home-cooked korean meak
[16:23:34] <jepler> meal
[16:25:21] <seb_kuzminsky> skunkworks_: it's just 2.8.0~pre so far ;-)
[16:25:26] <seb_kuzminsky> jepler: that sounds fun
[16:26:40] <skunkworks_> the j1900 with nothing special set in the kernel line has mid 20us latency over night. See what it is tomorrow
[16:27:09] <seb_kuzminsky> skunkworks_: is that the 4-cpu version of the j1800 that pcw was talking about earlier?
[16:27:14] <skunkworks_> yes
[16:27:18] <skunkworks_> 4 core
[16:27:23] <skunkworks_> (non hyperthreading)
[16:27:26] <seb_kuzminsky> can you paste lstopo frmo it? i dont understand the isocpus=2,3 thing
[16:27:28] <skunkworks_> it is a celeron
[16:27:35] <skunkworks_> I can tomorrow
[16:27:38] <seb_kuzminsky> ok cool
[16:27:57] <seb_kuzminsky> is that running the bjmorel_work's new "4linuxcnc" kernel?
[16:28:02] <skunkworks_> yes
[16:28:17] <skunkworks_> although the latency in my opinion has not changed...
[16:28:33] <skunkworks_> (nothing changed in that front between the 2 kernels)
[16:28:47] <skunkworks_> Which I think it shouldn;t have
[16:28:48] <seb_kuzminsky> agreed
[16:28:54] <seb_kuzminsky> yes that all makes sense
[16:29:05] <seb_kuzminsky> did you get the kernel deb from bjmorel_work, or from highlab, or from wlo?
[16:29:30] <skunkworks_> I installed an older hybrid iso and then did an update. painless.
[16:29:39] <skunkworks_> *upgrade
[16:29:47] <skunkworks_> well - both
[16:29:58] <skunkworks_> so - great work!
[16:34:40] <seb_kuzminsky> cool, thanks for testing :-)
[16:55:17] <brianmorel99> Cleaned out my kernel, did apt-get update & upgrade and all works well.
[17:00:26] <seb_kuzminsky> great :-)
[17:01:47] <seb_kuzminsky> brianmorel99: i merged your 3.4.55-rtai branch, then made another commit to reset the abi name back to just "9"
[17:01:50] <seb_kuzminsky> fyi
[17:01:57] <seb_kuzminsky> thanks for figuring out that usb problem
[17:04:04] <brianmorel99> Anytime, glad to help. Now to finish re-wiring the mill
[17:35:48] <cradek> group hug!
[17:38:11] <skunkworks_> next time we are all together...
[18:00:43] <KGB-linuxcnc> 03Sebastian Kuzminsky 05liblinuxcnc-ui 386eee9 06linuxcnc 10(17 files in 3 dirs) halui test: reorganize the halui jogging test dir layout * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=386eee9
[18:00:43] <KGB-linuxcnc> 03Sebastian Kuzminsky 05liblinuxcnc-ui 7d36de0 06linuxcnc 10(6 files) halui test: add an mdi test * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7d36de0
[18:00:43] <KGB-linuxcnc> 03Sebastian Kuzminsky 05liblinuxcnc-ui 7008539 06linuxcnc 10tests/halui/mdi/test-ui.py halui test: give halui a few seconds to switch the task mode back * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7008539
[18:00:45] <KGB-linuxcnc> 03Sebastian Kuzminsky 05liblinuxcnc-ui 1766a00 06linuxcnc 10src/emc/usr_intf/halui.cc halui: use lui for getting and thinking about task mode * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1766a00
[18:00:49] <KGB-linuxcnc> 03Sebastian Kuzminsky 05liblinuxcnc-ui 010c81a 06linuxcnc 10(5 files) lui: redo how the Command NML system waits * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=010c81a
[18:00:53] <KGB-linuxcnc> 03Sebastian Kuzminsky 05liblinuxcnc-ui dc5c288 06linuxcnc 10tests/liblinuxcnc-ui/lui-test.c lui-test: use implicit wait-for-done inside lui instead of explicit wait calls after each lui call * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=dc5c288
[18:00:58] <KGB-linuxcnc> 03Sebastian Kuzminsky 05liblinuxcnc-ui b4d1fd9 06linuxcnc 10src/liblinuxcnc-ui/task-mode.cc task-mode: use lui_send_nml_command_and_wait() * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b4d1fd9
[18:01:02] <KGB-linuxcnc> 03Sebastian Kuzminsky 05liblinuxcnc-ui 186eab1 06linuxcnc 10src/liblinuxcnc-ui/task-state.cc task-state: use lui_send_nml_command_and_wait() * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=186eab1
[18:01:06] <KGB-linuxcnc> 03Sebastian Kuzminsky 05liblinuxcnc-ui acdf262 06linuxcnc 10tests/liblinuxcnc-ui/lui-test.c lui-test: switch test_task_mode() to use fatal_if() * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=acdf262
[18:01:10] <KGB-linuxcnc> 03Sebastian Kuzminsky 05liblinuxcnc-ui 43fc512 06linuxcnc 10src/emc/usr_intf/emcrsh.cc linuxcncrsh: when the user runs "set set_wait", set the wait mode of lui too * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=43fc512
[18:01:14] <KGB-linuxcnc> 03Sebastian Kuzminsky 05liblinuxcnc-ui ece183d 06linuxcnc 10src/emc/usr_intf/emcrsh.cc linuxcncrsh: warn about broken "set wait" * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ece183d
[18:01:18] <KGB-linuxcnc> 03Sebastian Kuzminsky 05liblinuxcnc-ui 0fc3092 06linuxcnc 10src/liblinuxcnc-ui/Submakefile 10src/liblinuxcnc-ui/linuxcnc-ui.h 03src/liblinuxcnc-ui/mdi.cc lui: add lui_send_mdi_command() * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0fc3092
[18:01:22] <KGB-linuxcnc> 03Sebastian Kuzminsky 05liblinuxcnc-ui 3206c31 06linuxcnc 10src/emc/usr_intf/halui.cc halui: use lui for sending mdi * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3206c31
[18:01:26] <KGB-linuxcnc> 03Sebastian Kuzminsky 05liblinuxcnc-ui 6c0f334 06linuxcnc 10src/emc/usr_intf/xemc.cc xemc: use lui for send_mdi_command * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6c0f334
[18:01:30] <KGB-linuxcnc> 03Sebastian Kuzminsky 05liblinuxcnc-ui 343ce4f 06linuxcnc 10src/emc/usr_intf/emcrsh.cc 10src/emc/usr_intf/emcsched.cc 10src/emc/usr_intf/emcsh.cc change in-tree shcom users to use lui instead for mdi * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=343ce4f
[18:01:35] <KGB-linuxcnc> 03Sebastian Kuzminsky 05liblinuxcnc-ui f84fe88 06linuxcnc 10tests/mdi-queue/oword-queue-buster/test.sh 10tests/mdi-queue/simple-queue-buster/test.sh 10tests/t0/shared-test.sh 10tests/toolchanger/toolno-pocket-differ/shared-test.sh tests: use linuxcncrsh's "set set_wait" instead of the broken "set wait" * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f84fe88