Back
[01:09:25] <memleak> speaking of latency one of my pro gaming buddies is working on a coreboot port to several of his AM3+ and FM2 motherboards that he received from AMD for free, should help a lot with RTAI and jitter problems
[01:17:59] <memleak> according to the email ASUS F2A85-M PRO and F2A85-V PRO and GIGABYTE F2A85X-D3H
[01:20:47] <memleak> says hes doing it to overclock his hardware beyond what the BIOS lets him. XD
[01:23:18] <memleak> not sure if anyone here runs coreboot but hes helped me port a 785 board into the tree last year or so, just in case anyone wants to buy a motherboard really tuned for real-time
[03:05:28] <KGB-linuxcnc> 03Chris S Morley 05master 1c08ab9 06linuxcnc 10src/emc/usr_intf/pncconf/pncconf.py pncconf -fix 7i64 pin names * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1c08ab9
[07:37:48] <skunkworks> seems to peak at 112us - but stays around 80us
[07:41:52] <skunkworks> threw the hd in a different system - same issue. I will install 32 just to take that out of the picture
[09:22:24] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ngcgui-gcmc bb07923 06linuxcnc 10(7 files in 6 dirs) ngcgui: discard trailing semicolon for entry tag * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bb07923
[09:53:03] <pcw_home> skunkworks ping times?
[10:00:36] <skunkworks> pcw_home, yes
[10:01:37] <pcw_home> that should be OK must be something else wrong
[10:02:55] <pcw_home> (Ive tried three systems and it worked on all three though my desktop has latency peaks that make it unusable)
[10:03:08] <skunkworks> right - maybe it is a 64bit thing. (easy to test without digging into anything)
[11:14:55] <mozmck> seb_kuzminsky: regarding the grub stuff on precise, the "problem" is most likely the version numbering. Grub will by default use the latest kernel by version number. In 10.04 I think I made the last part of the number 100 higher than the original to get around that. I.e. the ubuntu kernel was 2.6.32-22 (I think) and I made the rtai version 2.6.32-122-rtai or something like that.
[11:15:03] <mhaberler> skunkworks,PCW: in case you have a ubc3-7i80 branch running.. could you try if the normal hm2 support still works with that branch (i.e. non hm2_eth, any Mesanet board)?
[11:16:51] <seb_kuzminsky> mozmck: i remember that
[11:17:07] <seb_kuzminsky> mozmck: the problem this time is that it's the kernel's version, not the version of the debian package, that's off
[11:17:25] <mozmck> ah
[11:17:28] <seb_kuzminsky> we're shipping 3.4.55-something, but ubuntu precise installs 3.8.something-something
[11:17:47] <mozmck> maybe you could do something like that for the kernel version? I would it cause other problems?
[11:17:58] <mozmck> 3.44.55-something
[11:18:02] <seb_kuzminsky> heh
[11:18:08] <seb_kuzminsky> that would be confusing
[11:18:21] <mozmck> Another option is that you can select the default kernel to boot.
[11:18:25] <seb_kuzminsky> i'd prefer to teach grub which kernel we want it to boot
[11:18:31] <cradek> weird, my xubuntu installed with linux-image-3.2.0-xx-generic
[11:18:47] <seb_kuzminsky> maybe xubuntu != ubuntu in this way?
[11:18:49] <mozmck> I don't remember where that is but it is in a config file I think.
[11:19:07] <cradek> then linux-image-3.4.55-rtai-2 turns into the default boot when I simply install it
[11:19:13] <cradek> maybe
[11:19:23] <mozmck> No, I'm pretty sure new installs of *buntu 12.04.3 use the 3.8.x kernel
[11:19:44] <cradek> but he says "doesn't put itself on the [grub] menu"
[11:20:00] <mozmck> Prior to that they used 3.2.x
[11:20:00] <cradek> he = e keller
[11:20:07] <cradek> do you think he's just mistaken?
[11:20:29] <seb_kuzminsky> i bet if he looks in the "previous version" grub sub-menu he'll see it there
[11:20:31] <mozmck> It hides them under "previous kernels" or something like that
[11:20:40] <seb_kuzminsky> 2/3 nerds agree
[11:20:45] <cradek> oh, that's an irritating feature
[11:21:09] <mozmck> :) I thought I was missing some kernels for a while until I figured that out.
[11:21:14] <seb_kuzminsky> they have to do it that way, because they never remove kernels (by default) so the list gets unmanageable and overwhelming if you dont move the old ones off
[11:21:21] <seb_kuzminsky> same problem we have with our configs ;-)
[11:21:29] <mozmck> not to mention hard drive space!
[11:21:30] <cradek> when we make a cd we won't have other kernels, so it's moot for those users
[11:21:33] <seb_kuzminsky> i know, we'll sick dgarr on it!
[11:21:49] <seb_kuzminsky> bbl
[11:21:51] <seb_kuzminsky> work :-(
[11:22:12] <mozmck> I had a separate boot partition for a long time and the "never remove old kernels" kept biting me.
[11:34:06] <pcw_home> mhaberler: yes I will do that when I get a chance
[12:16:00] <memleak> if you guys want, before you ship a new live cd i can bump rtai to the latest 3.4 kernel release
[12:16:35] <memleak> 3.4.67 is already supported
[12:17:59] <cradek> that sounds great, but I think we're not very near that yet
[12:21:02] <memleak> for the live cd should we use rtai 4 or stick with 3.x?
[12:22:48] <memleak> aka the old vulcano branch before magma got merged in
[12:23:51] <cradek> you would know better than any of us would
[12:24:00] <cradek> my gut says use whatever we've already been testing
[12:24:30] <cradek> because we have reason to believe it works, and we don't know of problems with it
[12:24:41] <memleak> that sounds safer to me too
[12:30:36] <memleak> has anyone had actual RTAI bugs with the 3.4.55 debs?
[12:31:18] <memleak> or just kernels and initrds not showing up in /boot
[13:02:39] <cradek> I haven't heard of any rtai problem
[13:03:00] <cradek> the problems I had were: no initrd, swap didn't work; seb fixed them both
[13:03:13] <cradek> I've heard of but not seen problems regarding the grub menu
[13:03:35] <cradek> I think those are just about the default option (and the "previous" menu thing hiding the one you want, and ubuntu stupidly hides grub altogether)
[13:10:30] <skunkworks> omg - why is it asking for the cdrom to install buildassential?
[13:10:55] <cradek> when you install from cd, it leaves cd droppings in sources.list
[13:10:56] <skunkworks> (and I did spell it right)
[13:11:02] <cradek> no
[13:11:04] <cradek> oh
[13:11:07] <cradek> I misread
[13:11:09] <skunkworks> heh
[13:11:15] <skunkworks> so how do you fix that?
[13:11:29] <cradek> delete the cdrom lines from sources.list
[13:11:32] <skunkworks> I don't think I have run into that before..
[13:11:33] <skunkworks> ok
[13:16:30] <skunkworks> that seems to work - thanks
[13:32:11] <cradek> if you didn't have networking available during the install maybe??
[13:48:18] <seb_kuzminsky> memleak, cradek: i think it'd be good to move the current RTAI we have onto the latest 3.4 kernel
[13:50:35] <seb_kuzminsky> we're currently using commit a0dc5355ee233032926dd23d1e132ef1befbbd76 from the master branch in the ShabbyX rtai repo on github
[13:50:54] <skunkworks> pcw_home, odd - the watchdog bites instantly - but the tmax is around 500us for the servo thread
[13:53:03] <cradek> I think that would be great, and I'll sure test it this weekend if so.
[13:54:54] <skunkworks> if I set the watchdog timeout much higher - I can get it to flash for a bit - then it stops. I think it must be a latency issue that doesn't show itself until I try to run it
[14:04:58] <memleak> seb_kuzminsky, do you know the commit message title?
[14:06:10] <memleak> update docs, i see it now
[15:24:09] <PCW> skunkworks: thats odd the read and write times I see are a close match to the ping statistics on all three machines
[15:25:21] <PCW> (you also need to make sure ubuntu is not futzing with the port)
[20:42:51] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ngcgui-gcmc ea76dd8 06linuxcnc 10lib/python/pyngcgui.py pyngcgui: expandsub not honored for gcmc files * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ea76dd8
[21:29:22] <skunkworks> logger[mah]:
[21:29:22] <logger[mah]> skunkworks: Log stored at
http://linuxcnc.mah.priv.at/irc/%23linuxcnc-devel/2013-12-21.html
[21:45:43] <skunkworks> pcw_home: how do you go about isolating the nic from linux prime?
[22:22:58] <pcw_home> I think I had to set ubuntu's network settings up for manual, ignore ipv6 etc
[22:24:14] <pcw_home> otherwise it periodically futzes about with the NIC causing pain and suffering