Back
[08:00:34] <skunkworks_> hm - going to take 2 days to re-align my xp machine..
[09:02:57] <pcw_home> With the stars?
[09:07:50] <skunkworks_> heh - no. I imaged my hd to a 2gb hd.. The 2gb is 'advanced format' drive. My sectors are not aligned and the system slowed way down
[09:19:34] <skunkworks_> gparted to the rescue
[09:25:08] <jepler> how tiresome
[09:29:12] <skunkworks_> I ’twas a suprise
[09:29:31] <skunkworks_> *it
[09:29:59] <cradek> I'd be surprised to be installing a windows xp machine, too
[09:32:26] <skunkworks_> heh
[09:32:48] <skunkworks_> some legacy stuff still causes issues
[09:39:08] <mozmck1> for any win stuff I have to do I use winXP in virtualbox - running on linux.
[09:40:55] <mozmck1> skunkworks: for any win stuff I have to do I use winXP in virtualbox - running on linux.
[09:41:56] <skunkworks> I do that on my laptop
[09:42:08] <mozmck1> it works well, and backups are a breeze. one large file for the whole system, which can also be run on other computers.
[09:49:29] <skunkworks> right
[10:26:40] <skunkworks> cradek: the hotfix for the skipping segments looks good so far
[10:26:56] <cradek> great
[10:27:16] <skunkworks> (plus he made G61 and G61.1 behave as described - exact path vs exact stop)
[10:27:19] <cradek> he should merge or rebase it
[10:52:32] <skunkworks> micges: beat s-curve into submission?
[10:52:56] <micges> I think so
[10:53:21] <micges> I'll push branch after some commits cleanup
[10:57:08] <skunkworks> cool
[10:57:50] <micges> math is right but something is going that leads to those spikes of acc you saw
[10:58:05] <skunkworks> my first parametric drawing..
http://electronicsam.com/images/KandT/testing/Screenshot%20from%202014-06-23%2010:32:46.png
[10:58:47] <micges> parametric in freecad, I like it
[11:00:37] <skunkworks> you definatly have to know the 'tricks' to make what you want.. there is a learning curve..
[11:52:31] <CaptHindsight> hmm Linux Mint 17 out today with KDE 4.13, MDM 1.6, a Linux kernel 3.13 and an Ubuntu 14.04 package base. have to see what problems Linuxcnc has with this...
[11:57:21] <CaptHindsight> cradek and seb_kuzminsky: you have to let memleak know what bits you want merged from ubc3-7i80 and
https://github.com/machinekit/machinekit into linuxcnc master
[11:58:40] <CaptHindsight> https://github.com/NTULINUX/linuxcnc/tree/ubc3-7i80-master ubc3-7i80-master.diff 3MB
[11:59:14] <CaptHindsight> only 8 conflicts right now
[12:09:35] <CaptHindsight> a diff without all the arm and glue gun stuff might be the next step
[12:11:46] <cradek> yeah. I am not sure which way to go. I would like one? of the userland rtoses to be supported, especially so the 7i80 will work, and ideally it would be one where there's an existing debian kernel. does that make preemt-rt the best choice?
[12:12:06] <cradek> I agree that separating out the rtos support and whatever api changes are needed are the way to go.
[12:13:09] <cradek> merging ubc is trivial and those conflicts are tiny, but that's not what we want, because we don't want the emcweb, the raspberry/beagle stuff, the logging server, etc to be rolled in all together
[12:29:51] <pcw_home> preemt-rt is by far the most easily supported linux based RTOS if you can live with the latency
[12:29:53] <pcw_home> and probably fine for most hardware supported systems (and there are hardware remedies for jitter if needed)
[12:33:31] <pcw_home> (and even I can make a working preemt-rt kernel)
[12:42:25] <mozmck1> cradek: why is that? so they can be tested separately?
[12:43:42] <CaptHindsight> I guess we should see if adding preempt_RT is already separate from adding Xenomai or if it was done in the same file
[12:44:54] <CaptHindsight> we are working on finishing ARM again now as well, but that can be added later
[12:47:06] <memfrob> in the diff i created, preempt_rt and xenomai changes are both in there at the same time.
[12:48:01] <mozmck1> I would like to see the Xenomai stuff personally, just because it gives more options as far as hard realtime and newer kernels etc.
[12:48:02] <CaptHindsight> so it looks like we get all 3 real time kernels
[12:48:10] <memfrob> yes we do.
[12:48:43] <memfrob> mozmck1, preempt_rt is further ahead with kernel releases than xenomai.
[12:49:29] <CaptHindsight> yeah, we're waiting for RTAI to get fixed again for newer kernels >3.4
[12:49:58] <CaptHindsight> this shouldn't be a problem to have support for all 3 (famous last words)
[12:50:04] <mozmck1> memfrob: yes, but farther behind with latency and jitter. xenomai gets closer to rtai in that respect.
[12:51:34] <memfrob> even if RTAI supported 3.14 kernels, it wouldn't do linuxcnc any good.
[12:51:57] <memfrob> with the current linuxcnc source that is. it needs changes.
[12:52:08] <mozmck1> hmm, what kind?
[12:52:10] <CaptHindsight> from or test comparisons boards with RTAI <10uS are ~25uS with Xenomai and 50uS+ with preempt_rt
[12:52:20] <memfrob> 3.10 with RTAI works fine with other applications.
[12:52:42] <memfrob> mozmck1, proc changes, math changes from what i recall. possibly one more.
[12:53:03] <CaptHindsight> pcw_home: what results do you get with prempt_rt on your test boards?
[12:53:07] <mozmck1> CaptHindsight: yes, I've seen other similar reports.
[12:53:32] <CaptHindsight> the scheduler in RTAI is currently broken
[12:54:34] <pcw_home> Preemt-rt maybe 50-80 usec latency
[12:55:05] <pcw_home> which is fine for hardware assisted systems
[12:55:49] <CaptHindsight> 1) fix the scheduler in RTAI 2) math support in kernel kconfig has changed and no options seem to work with Linuxcnc 3) Linuxcnc needs to fix /proc in order for any 3.10 or newer RTAI kernels to work
[12:56:22] <CaptHindsight> One workaround for the broken scheduler is with isocpu= you need to leave the last cpu core out of the list. For example isolcpus=1,2,3 for a 4 core and it should work or a single core cpu should work fine.
[12:56:26] <pcw_home> 50 usec is not a whole lot worse than RTAI if you factor in actual hardware latencies
[12:57:16] <CaptHindsight> we got <80Us with preempt_rt on the ARM A20
[12:57:31] <CaptHindsight> Xenomai was ~40uS
[12:57:34] <mozmck1> what does linuxcnc do in /proc?
[12:58:46] <memfrob> mozmck1, one second ill find it.
[13:00:34] <memfrob> src/rtapi/rtapi_proc.h
[13:01:23] <memfrob> mozmck1, also: git grep "ifdef CONFIG_PROC_FS"
[13:01:44] <mozmck1> ok, thanks.
[13:06:07] <memfrob> if you want all the problems with linuxcnc caused by RTAI, i squashed it into one big commit.
[13:06:12] <memfrob> https://github.com/ShabbyX/RTAI/commit/2f482966781267dc2a8c33bc47150bb2fd2bf47b
[13:06:35] <memfrob> broken scheduler commit though i couldn't find
[13:07:38] <memfrob> broken scheduler might actually be this one: base/arch/x86/hal/hal.c: do not make available rtai_sched_affinity and free_isolcpus_from_linux under UP.
[13:09:05] <memfrob> "under UP" > "all the time" mistake perhaps..
[13:29:13] <KGB-linuxcnc> 03Jeff Epler 05master 2b93565 06linuxcnc Merge branch 'linuxcnctop-tweaks' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2b93565
[15:28:44] <MrHindsight> anyone have a short synopsis of what the down sides are to using/keeping NML in Linuxcnc?
[15:29:31] <MrHindsight> I recall the discussion about replacing it but not the reasons
[15:30:54] <MrHindsight> http://sourceforge.net/p/emc/mailman/message/31907346/ found this thread
[15:50:08] <kwallace> I seem to recall that NML had a message size that is too small to handle any more features such as a more tool IDs.
[15:50:24] <cradek> replacing nml is much less important than getting the new-rtos support
[15:50:57] <cradek> kwallace: (you can set the message size just by editing the nml file, if your machine needs more tools)
[15:52:03] <cradek> the upside of nml is it's currently working and requires little maintenance - the downside is it's a little tedious when you want to add a new message
[15:52:22] <cradek> lately I've heard it may also be broken for multi-machine communication when they have different word sizes
[15:52:42] <MrHindsight> maybe new RTOS and the hm2-ethernet as the first steps in the merge
[15:53:05] <cradek> yeah I agree those are the important things
[15:53:50] <mozmck1> no, NML is OLD, which means it is hopelessly broken, useless, should be scrapped, etc.
[15:54:07] <mozmck1> hmm, is that trolling?
[15:54:23] <kwallace> I thought I read that NML message size or buffer size could not be made bigger, but I really know nothing about NML.
[15:54:36] <MrHindsight> maybe a short list in order of priority for the features to merge (not etched in stone)
[15:54:38] <cradek> I am not aware of a maximum size limitation
[15:55:03] <cradek> the nml buffers are a fixed, but configurable, size
[15:55:55] <kwallace> Then, I too wonder why NML is so awful.
[15:56:29] <cradek> if there is an actual problem, it's the serial number echo architecture that bites occasionally when you have multiple very busy UIs
[15:57:15] <cradek> kwallace: if you want to do "modern" things like make UIs out of web browsers and phones you might not feel like messing with nml, which nobody has ported to your new architecture
[15:58:56] <cradek> if the linuxcnc project wants to continue focusing on being a desktop cnc control running on a single pc, there is certainly no nml-related emergency
[15:59:32] <cradek> reasonable people might disagree about whether that's a good focus
[16:03:34] <cradek> the tool table size limitation should be fixed by not expecting the whole tool table to fit in one message (this is probably true whether we are using nml or some other messaging system)
[16:03:50] <cradek> I am sure andy's tool table database rewrite fixes this
[16:07:51] <CaptHindsight> I was just looking ahead and thinking about that post about compatibility with
http://www.mtconnect.org/ http://rosindustrial.org/
[16:36:12] <kwallace> "the tool table size limitation should be fixed by not expecting the whole tool table to fit in one message" ahh, I think this is what I was recalling from past posts.
[17:04:38] <CaptHindsight> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Todo-2.6 I see it's all on the list already
[17:20:03] <memfrob> configure script should have a check for tkimg
[17:21:18] <memfrob> so who wants xenomai and preempt-rt support seperated and isolated from the rest of mhaberler's changes? is that the split you guys were looking for?
[17:22:16] <memfrob> im on an RT system now and can check for bugs in blobs
[17:24:53] <CaptHindsight> memfrob: yes, post that split/diff and also get a diff for the hm2-ethernet support that mozmck added
[17:25:33] <CaptHindsight> those are the first two changes we can see about merging into Linuxcnc
[17:25:52] <memfrob> hm2-ethernet support is in the ubc3-7i80 branch?
[17:26:48] <CaptHindsight> yes, that's why we decided to use that branch since it works with all three real time kernels and has the new hm2-ethernet tested and working
[17:27:56] <mozmck1> mozmck didn't add that!
[17:29:19] <memfrob> micges then?
[17:31:08] <CaptHindsight> my fault, yes micges
[17:33:23] <skunkworks_> I think mozmck1 did it...
[17:33:31] <skunkworks_> ;)
[17:41:05] <memfrob> rsyslog should be added to configure script as well
[17:43:12] <mozmck1> how much of the stuff in that Todo-2.6 still needs to be done before the final 2.6 release??
[17:53:04] <memfrob> this is a new record! preempt-rt staying at 23us!
[17:58:27] <mozmck1> nice! is it a newer kernel? different board?
[17:59:35] <memfrob> yeah 64-bit bleeding edge hardware
[17:59:35] <memfrob> i have 5 instances of firefox and flash videos, 3 instances of glxgears, and compiling gcc 4.9 in the background with 5 instances, staying at 32us now
[18:00:17] <mozmck1> not bad!
[18:06:17] <memfrob> my system hung for a second while linking gcc and it shot up to 100us
[18:12:55] <memfrob> took a long while to get here:
http://i.imgur.com/3jYPhBr.png
[18:13:58] <memfrob> im also using llvmpipe 3D acceleration (not hardware / GPU)
[18:17:49] <CaptHindsight> Asus f2a85-v pro
https://www.asus.com/Motherboards/F2A85V_PRO/, A10 5800K
http://products.amd.com/en-gb/DesktopAPUDetail.aspx?id=44
[18:18:35] <CaptHindsight> we need to start a new category on the latency test results for 3 different real time kernels
[18:20:35] <CaptHindsight> RTAI on that board might only be 7-10uS
[18:23:49] <CaptHindsight> memfrob: which kernel version?
[18:24:11] <memfrob> 3.12.22-rt34
[18:25:41] <memfrob> kernel config:
http://dpaste.com/22CPR57
[18:27:55] <memfrob> now that i have a working RT system, time to split xenomai and preempt-rt commits
[22:07:44] <jepler> it looks like g++ 4.8 (debian testing)'s memory requirements went up a bit; I can no longer comfortably build linuxcnc with -j5 in 2GB RAM
[22:07:59] <jepler> specifically the files that use boost::python take a half gig each
[22:09:01] <skunkworks_> I cannot to -j9 conistantly with 4gb.. it sometimes doesn't finish.. (and most everything else runs out of memory..)
[22:11:39] <skunkworks_> chrome says - 'he's dead jim...' ;)
[22:14:04] <jepler> mine builds, but not without hitting swap
[22:15:14] * memfrob has 16GB and does not have these problems :P
[22:15:28] <memfrob> memory leaks.. i need a lot to compensate.
[22:47:08] <mozmck1> maybe having 20GB is why I haven't noticed any problem building some large programs with -j9 :)
[22:47:41] <memfrob> why do you have to one-up me like that?.. :P
[22:48:10] <mozmck1> well, I didn't think of it that way :)
[23:02:34] <memfrob> jepler, the idea behind the increased amount of memory during compiling seems to be decreasing the amount of memory when the application is running.
[23:03:22] <memfrob> i recall reading the release notes for GCC 4.9 i think it was, and they were able to get firefox to use less memory after compilation.
[23:05:23] <memfrob> stricter compilation rules, changing the behavior of linking (especially LTO / link-time optimization) etc
