#linuxcnc-devel | Logs for 2013-01-04

[00:00:04] <mhaberler> ah. I think I was between 30 to maybe 50 before I had the 3.2.21 where it is
[00:00:14] -!- skunkworks [skunkworks!~chatzilla@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[00:00:50] <mhaberler> anyway, I'm out for today.
[00:01:05] <memleak> skunkworks hello! mhaberler take care!
[00:01:18] <mhaberler> dgarr: the fixed kernel should show up as *0.3 tomorrow morning
[00:02:58] <mhaberler> it just looks online, its just the build running ;) it aint me, its the mhaberler roboposter
[00:03:07] -!- servos4ever has quit [Quit: ChatZilla 0.9.85 [SeaMonkey 2.0.11/20101206162726]]
[00:03:07] -!- logger[mah] has quit [Remote host closed the connection]
[00:03:15] -!- logger[mah] [logger[mah]!~loggermah@ns2.mah.priv.at] has joined #linuxcnc-devel
[00:04:44] <skunkworks> hi
[00:05:17] <memleak> be right back
[00:05:21] -!- memleak has quit [Quit: new kernel]
[00:05:50] <skunkworks> logger[mah]:
[00:05:50] <logger[mah]> skunkworks: Log stored at http://linuxcnc.mah.priv.at/irc/%23linuxcnc-devel/2013-01-04.html
[00:10:46] -!- zzolo has quit [Quit: zzolo]
[00:14:05] -!- memleak [memleak!~memleak@unaffiliated/memleak] has joined #linuxcnc-devel
[00:14:08] <memleak> hi!
[00:21:14] <skunkworks> is someone building new debs?
[00:21:21] <skunkworks> (sorry - just skimming
[00:21:23] <skunkworks> )
[00:24:33] <memleak> I
[00:24:44] <memleak> whoops.. I'm not, just xenomai from source.
[00:27:36] <memleak> It's weird how scripts/prepare-kernel.sh in xenomai is different than patch -1 < ../adeos_patch_from_xenomai_tree.patch
[00:27:50] -!- Skinkie has quit [Quit: Leaving.]
[00:28:24] <memleak> *patch -p1
[00:30:54] -!- kb8wmc has quit [Ping timeout: 265 seconds]
[00:31:31] -!- kb8wmc [kb8wmc!~chatzilla@] has joined #linuxcnc-devel
[00:34:30] -!- motioncontrol has quit [Quit: Sto andando via]
[00:34:55] -!- micges has quit [Quit: Leaving]
[00:35:51] -!- bradsimantel has quit [Quit: bradsimantel]
[00:42:42] -!- adb has quit [Ping timeout: 264 seconds]
[00:43:44] -!- ve7it has quit [Remote host closed the connection]
[00:53:53] sliptonic is now known as sliptonic_away
[00:54:41] sliptonic_away is now known as sliptonic
[01:00:05] -!- Nick001-Shop has quit [Quit: ChatZilla 0.9.89 [Firefox 17.0.1/20121128204232]]
[01:36:28] -!- plushy has quit [Quit: Leaving.]
[01:38:44] -!- hashfail has quit []
[01:39:06] -!- rob__H has quit [Ping timeout: 264 seconds]
[01:49:54] -!- sumpfralle has quit [Ping timeout: 276 seconds]
[01:50:46] -!- zzolo has quit [Client Quit]
[02:07:22] -!- asdfasd has quit []
[02:13:05] -!- jonathan___ has quit [Quit: Page closed]
[02:14:27] -!- sumpfralle1 has quit [Ping timeout: 248 seconds]
[02:25:16] -!- memleak has quit [Quit: Bed]
[02:31:02] -!- Valen has quit [Quit: Leaving.]
[02:37:19] -!- Valen has quit [Client Quit]
[02:42:43] -!- SWPadnos_ [SWPadnos_!~Me@74-92-8-208-NewEngland.hfc.comcastbusiness.net] has joined #linuxcnc-devel
[02:42:47] -!- andypugh_ [andypugh_!~andy2@cpc16-basl9-2-0-cust685.20-1.cable.virginmedia.com] has joined #linuxcnc-devel
[02:43:31] -!- sumpfralle has quit [Read error: Operation timed out]
[02:44:38] -!- pjm has quit [*.net *.split]
[02:44:41] -!- andypugh has quit [*.net *.split]
[02:44:41] -!- SWPadnos has quit [*.net *.split]
[02:44:54] andypugh_ is now known as andypugh
[02:44:54] SWPadnos_ is now known as SWPadnos
[02:44:59] -!- SWPadnos has quit [Changing host]
[02:44:59] -!- SWPadnos [SWPadnos!~Me@emc/developer/SWPadnos] has joined #linuxcnc-devel
[02:44:59] -!- mode/#linuxcnc-devel [+v SWPadnos] by ChanServ
[03:00:59] -!- skunkworks has quit [Remote host closed the connection]
[03:11:01] -!- gmouer has quit []
[03:21:26] -!- zzolo has quit [Quit: zzolo]
[03:45:59] -!- archivist_herron has quit [Ping timeout: 252 seconds]
[03:51:31] -!- andypugh has quit [Quit: andypugh]
[04:00:25] Guest88203 is now known as abetusk
[04:01:25] -!- zzolo has quit [Quit: zzolo]
[04:07:22] -!- Keknom has quit [Quit: Leaving.]
[04:15:01] -!- tjb1 has quit [Ping timeout: 245 seconds]
[04:15:02] tjb1_ is now known as tjb1
[04:17:31] -!- Gene45 has quit [Ping timeout: 245 seconds]
[04:31:24] -!- L84Supper has quit [Ping timeout: 260 seconds]
[04:32:48] -!- L84Supper [L84Supper!~Larch@unaffiliated/l84supper] has joined #linuxcnc-devel
[04:33:55] -!- Valen has quit [Quit: Leaving.]
[04:37:42] -!- FinboySlick has quit [Remote host closed the connection]
[05:29:46] -!- dgarr has quit [Quit: Leaving.]
[06:29:30] -!- steves_logging has quit [Ping timeout: 264 seconds]
[06:32:30] -!- alex4nder has quit [Ping timeout: 264 seconds]
[06:32:44] -!- alex4nder [alex4nder!~alexander@ns2.lexterieur.net] has joined #linuxcnc-devel
[06:35:36] -!- dimas has quit [Ping timeout: 264 seconds]
[06:57:20] -!- yuvipanda has quit [Excess Flood]
[07:08:53] -!- AR_ has quit [Ping timeout: 240 seconds]
[07:28:59] -!- yuvipanda has quit [Quit: yuvipanda]
[07:53:44] -!- archivist_herron has quit [Ping timeout: 255 seconds]
[07:56:54] -!- vladimirek [vladimirek!~vladimire@] has joined #linuxcnc-devel
[08:30:26] -!- norm has quit [Ping timeout: 245 seconds]
[08:33:12] -!- cncbasher [cncbasher!~quassel@cpc15-hart9-2-0-cust101.11-3.cable.virginmedia.com] has joined #linuxcnc-devel
[08:49:08] -!- racycle has quit [Quit: racycle]
[08:51:19] -!- Youdaman has quit []
[08:57:42] -!- norm has quit [Ping timeout: 264 seconds]
[09:03:02] -!- KGB-linuxcnc has quit [Ping timeout: 244 seconds]
[09:05:06] -!- hm2-buildmaster has quit [Ping timeout: 244 seconds]
[09:05:37] -!- fragalot has quit [Ping timeout: 244 seconds]
[09:05:37] -!- tris has quit [Ping timeout: 244 seconds]
[09:05:37] -!- ds3 has quit [Ping timeout: 244 seconds]
[09:06:48] fragalot is now known as Guest33719
[09:12:50] -!- KGB-linuxcnc [KGB-linuxcnc!~kgb-linux@git.linuxcnc.org] has joined #linuxcnc-devel
[09:17:39] -!- hm2-buildmaster [hm2-buildmaster!~hm2-build@174-29-75-7.hlrn.qwest.net] has joined #linuxcnc-devel
[09:23:34] -!- odogono has quit [Read error: Connection reset by peer]
[09:54:11] -!- theos has quit [Ping timeout: 248 seconds]
[10:00:52] -!- tjb1 has quit [Quit: tjb1]
[10:06:14] -!- adb [adb!~IonMoldom@] has joined #linuxcnc-devel
[10:20:40] Cylly is now known as Loetmichel
[10:23:35] -!- i_tarzan has quit [Read error: Connection reset by peer]
[10:33:36] -!- rob_h [rob_h!~rob_h@5e086765.bb.sky.com] has joined #linuxcnc-devel
[10:44:43] <mhaberler> OT: really interesting Linux control application: www.igh-essen.com/pdf/kursk-nluug.pdf
[11:05:39] -!- mhaberler has quit [Ping timeout: 248 seconds]
[11:18:31] -!- mhaberler [mhaberler!~mhaberler@extern-183.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[11:19:35] -!- mhaberler has quit [Client Quit]
[11:24:45] -!- aude has quit [Remote host closed the connection]
[11:29:35] -!- odogono has quit [Read error: Connection reset by peer]
[11:29:35] odogono_ is now known as odogono
[11:42:15] -!- shurshur has quit [Ping timeout: 265 seconds]
[11:42:33] -!- mhaberler [mhaberler!~mhaberler@extern-183.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[11:50:30] -!- shurshur has quit [Ping timeout: 264 seconds]
[11:51:59] aude is now known as aude-wiki
[11:52:09] aude-wiki is now known as aude
[11:52:15] aude is now known as Guest4276
[11:52:32] Guest4276 is now known as aude-wiki
[11:54:30] aude-wiki is now known as aude
[12:01:53] -!- mhaberler has quit [Quit: mhaberler]
[12:35:43] -!- yuvipanda_ has quit [Remote host closed the connection]
[12:43:51] -!- yuvipanda_ has quit [Remote host closed the connection]
[12:48:14] -!- Holgi has quit [Client Quit]
[12:49:16] -!- yuvipanda_ has quit [Read error: Connection reset by peer]
[12:50:56] -!- dhoovie has quit [Read error: Connection reset by peer]
[13:01:25] yuvipanda_ is now known as RantingPanda
[13:19:15] -!- tegarright has quit [Client Quit]
[13:21:39] -!- cncbasher has quit [Ping timeout: 248 seconds]
[13:23:08] -!- asdfas has quit [Ping timeout: 255 seconds]
[13:26:13] -!- RantingPanda has quit [Remote host closed the connection]
[13:29:42] -!- syyl_ has quit [Ping timeout: 255 seconds]
[13:53:44] -!- yuvipanda_ has quit [Remote host closed the connection]
[13:56:59] -!- skunkworks [skunkworks!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[14:15:47] -!- DJ9DJ has quit [Quit: bye]
[14:15:55] <skunkworks> logger[mah],
[14:15:55] <logger[mah]> skunkworks: Log stored at http://linuxcnc.mah.priv.at/irc/%23linuxcnc-devel/2013-01-04.html
[14:20:19] -!- yuvipanda_ has quit [Ping timeout: 252 seconds]
[14:21:40] -!- syyl__ has quit [Quit: Leaving]
[14:26:42] -!- JT-Shop has quit [Read error: Connection reset by peer]
[14:27:06] -!- JT-Shop [JT-Shop!~John@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[14:27:13] -!- abetusk has quit [Quit: Leaving]
[14:30:42] -!- yuvipanda_ has quit [Ping timeout: 264 seconds]
[14:37:47] -!- norm has quit [Quit: norm]
[14:39:42] -!- archivist_herron has quit [Ping timeout: 264 seconds]
[14:47:53] -!- yuvipanda_ has quit [Ping timeout: 240 seconds]
[15:01:23] -!- mackerski has quit [Ping timeout: 252 seconds]
[15:01:23] mackerski_ is now known as mackerski
[15:09:20] -!- automata_ has quit [Ping timeout: 255 seconds]
[15:12:01] -!- phantoneD has quit [Ping timeout: 265 seconds]
[15:13:05] Simon2 is now known as MicroNotSoft
[15:18:50] -!- vladimirek has quit [Remote host closed the connection]
[15:19:54] -!- vladimirek [vladimirek!~vladimire@] has joined #linuxcnc-devel
[15:21:15] -!- mackerski has quit [Remote host closed the connection]
[15:36:42] -!- norm has quit [Ping timeout: 264 seconds]
[15:38:43] -!- yuvipanda_ has quit [Ping timeout: 248 seconds]
[15:48:08] -!- shurshur has quit [Ping timeout: 252 seconds]
[16:04:13] -!- logger[psha] [logger[psha]!~loggerpsh@] has joined #linuxcnc-devel
[16:14:36] -!- yuvipanda__ has quit [Remote host closed the connection]
[16:20:48] -!- shurshur has quit [Remote host closed the connection]
[16:24:31] -!- memleak [memleak!~memleak@unaffiliated/memleak] has joined #linuxcnc-devel
[16:24:36] <memleak> good morning folks!
[16:25:39] -!- norm has quit [Ping timeout: 260 seconds]
[16:30:51] <skunkworks> Good morning!
[16:32:20] -!- L84Supper has quit [Quit: <puff of smoke>]
[16:33:05] -!- cncbasher [cncbasher!~quassel@cpc15-hart9-2-0-cust101.11-3.cable.virginmedia.com] has joined #linuxcnc-devel
[16:35:32] <memleak> skunkworks, hey!
[16:36:13] <memleak> can you post the exact problem you were having with Xenomai on your AMD board? 3.5.3 is almost working here, I just woke up, I'll be done by tonight.
[16:36:54] <memleak> I'm really loving this Xenomai stuff!
[16:40:37] <skunkworks> heh - cool
[16:41:02] <skunkworks> this is the error the second I install the xenomai kernel
[16:41:43] <skunkworks> http://imagebin.org/241608
[16:42:03] <memleak> that looks really bad..
[16:42:16] <memleak> straight 0s. Jeeze that's early!
[16:42:19] <skunkworks> this is the dmesg booting from the 12.04 non-realtime kernel
[16:42:20] <skunkworks> http://pastebin.ca/2299341
[16:42:57] <memleak> most likely a bad kernel config.
[16:43:55] -!- JT-Shop has quit [Read error: Connection reset by peer]
[16:44:24] -!- JT-Shop [JT-Shop!~John@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[16:44:26] <memleak> im generating a very specific kernel config for my specific board but it'll be a good baseline considering i dont have anything obscure on my board. AHCI support, SCSI, USB, HID, and basic CPU and memory features.
[16:45:16] <memleak> very trimmed down but will suffice for a very tiny RTAI kernel.
[16:45:49] <memleak> smaller the kernel, the lower the latency. too many things get turned on, it gets sluggish and you run into problems because there is more things which could possibly break.
[16:45:50] <cncbasher> skunkworks:did you pick up on Micheals updated kernel on the dev list ?
[16:48:56] -!- L84Supper [L84Supper!~Larch@unaffiliated/l84supper] has joined #linuxcnc-devel
[16:49:26] <skunkworks> yes - and replied
[16:50:43] -!- yuvipanda_ has quit [Ping timeout: 248 seconds]
[16:52:05] -!- dgarr [dgarr!~dgarrett@97-117-216-246.phnx.qwest.net] has joined #linuxcnc-devel
[16:54:46] <dgarr> i've tried the mah .3 deb today but still no boot this amd box: http://www.panix.com/~dgarrett/stuff/xnotes.txt
[16:59:17] <jepler> dgarr: weird, /dev/ada exists but /dev/sda6 does not?
[16:59:27] <dgarr> yes
[16:59:29] -!- yuvipanda__ has quit [Ping timeout: 255 seconds]
[16:59:40] <dgarr> (sda not ada of course)
[16:59:45] <jepler> er yes
[17:00:01] <jepler> do you use MBR ('fdisk') partitioning, or something else?
[17:00:14] <jepler> eek, freebsd is rotting my brain (their sata drives show up as /dev/adaN)
[17:00:16] <cradek> root=UUID=/dev/sda6
[17:00:19] <cradek> that's not a UUID is it?
[17:00:33] <cradek> guessing you mean root=/dev/sda6
[17:00:46] <dgarr> cradek: oops you're right, ill fix and report
[17:01:05] <jepler> how did you determine /dev/sda6 didn't exist? is there a shell prompt after the failure or something?
[17:07:46] -!- psyhitus has quit [Read error: Connection timed out]
[17:09:12] <dgarr> http://www.panix.com/~dgarrett/stuff/noboot1.jpg
[17:09:43] <jepler> cat /proc/partitions
[17:11:04] <cradek> sda6 would be in an extended fdisk partition isn't it?
[17:13:32] <jepler> cradek: yes I assume so
[17:14:02] <jepler> the working kernel apparently says: Jan 3 15:39:47 shop-lucid kernel: [ 1.534525] sda: sda1 sda2 sda3 < sda5 sda6 sda7 sda8 sda9 >
[17:14:09] <dgarr> http://www.panix.com/~dgarrett/stuff/noboot1_partitions.jpg
[17:14:12] <cradek> ah
[17:14:52] <jepler> oh -- and the working system has /dev/sd[abc] while the busted system only has two drives
[17:15:01] <jepler> http://www.panix.com/~dgarrett/stuff/x.log
[17:15:44] <jepler> yeah, so it's missing sata_via as dgarr suspects
[17:16:11] <jepler> if "we" ship a xenomai kernel we need to turn on all the drivers
[17:16:25] <jepler> it sounds like a lot of "legacy"ish drivers are turned off, which has now tripped up both skunkworks and dgarr
[17:16:53] <L84Supper> whats the size of the kernel as is?
[17:17:24] <L84Supper> what's a few more K's?
[17:17:25] <jepler> L84Supper: 4 lbs 8 oz
[17:17:27] <cradek> it's mostly in modules, so it doesn't matter
[17:18:28] <L84Supper> just over 2Kg, shouldn't be a problem
[17:20:33] <skunkworks> legecy-sih - this is a sata motherboard for gosh sakes. practically new ;)
[17:20:42] Guest33719 is now known as fragalot
[17:21:06] -!- shurshur has quit [Ping timeout: 264 seconds]
[17:21:07] -!- fragalot has quit [Changing host]
[17:21:11] <memleak> Paolo Mante, the lead developer of IPIPE told me very specifically to leave legacy turned on.
[17:21:21] shurshur_ is now known as shurshur
[17:21:39] <memleak> Xenomai 2.6.2 however automatically turns on CONFIG_IPIPE_LEGACY
[17:22:53] <memleak> When I first started looking into Xenomai, using cd $kernel_source && patch -p1 < ../patch_from_xenomai_tree.patch is different than cd $xenomai && scripts/prepare-kernel.sh
[17:23:16] <memleak> If you use the old fashioned "patch" method, it wont automatically be select. In short, follow the xenomai instructions.
[17:25:11] <memleak> Also if you use an AMD fam10 or newer processor or any CPU which uses MSI (message signaled interrupts) feel free to turn on PCI_MSI. The documentation for xenomai that says to turn it off is out of date, I just looked at the patch myself.
[17:25:33] <memleak> also http://mail.rtai.org/pipermail/rtai/2011-March/024440.html
[17:29:38] <seb_kuzminsky> for the kernel config, i think we should start with the upstream (ubuntu) kernel config, and make the minimal set of changes needed to enable preempt-rt and xenomai
[17:29:53] <jepler> certainly when it comes to anything like hardware drivers
[17:29:58] <cradek> yes that is the only way we've succeeded in the past
[17:30:02] <seb_kuzminsky> i think those folks have done a better job of determining what kernel config settings work best for the masses than we can
[17:30:03] -!- mackerski has quit [Quit: mackerski]
[17:30:03] <jepler> I don't know that those are cleanly separated from "other stuff"
[17:30:19] <memleak> seb_kuzminsky, I'm doing this all from scratch and making great progress though!!
[17:30:33] <memleak> I'll have a good baseline config for you guys in a bit.
[17:30:51] <memleak> That's actually the main reason I'm here...
[17:33:34] -!- psyhitus has quit [Read error: Connection timed out]
[17:34:04] <dgarr> i've updated http://www.panix.com/~dgarrett/stuff/lhisto.tcl for two small bugs, test results and screenshots appreciated
[17:37:01] <jepler> dgarr: that's a neat little program
[17:37:32] <jepler> dgarr: btw, did you consider whether it was possible to put the "additional pos/neg bins" in the first/last bin in the graph?
[17:39:23] <dgarr> i thought about it but think it reqires too much explanation, it now reads "additional pos bin ct" as the number is the count in all "bins" exceeding display limit
[17:39:25] <jepler> (boy those graphs look like FFTs)
[17:39:51] <jepler> (I suppose that's no surprise as it's dealing in the frequency domain)
[17:40:05] -!- psyhitus has quit [Ping timeout: 248 seconds]
[17:41:39] -!- memleak has quit [Quit: New kernel]
[17:41:45] <dgarr> interesting observation, its probably like http://en.wikipedia.org/wiki/Central_limit_theorem -- everything is normal (gaussian) eventually
[17:42:36] <jepler> the general symmetry probably comes from the RTOS trying to perform events at t=0, k, 2*k, ... n*k
[17:43:01] <jepler> when one event is at n*k+eps, if the next event is on time its interval becomes k-eps
[17:48:25] -!- memleak [memleak!~memleak@unaffiliated/memleak] has joined #linuxcnc-devel
[17:48:30] <memleak> http://pastebin.ca/2299429
[17:48:34] <memleak> How is my latency?
[17:49:30] -!- andypugh [andypugh!~andy2@cpc16-basl9-2-0-cust685.20-1.cable.virginmedia.com] has joined #linuxcnc-devel
[17:50:09] <memleak> How do you get that graphical latency test dgarr? http://www.panix.com/~dgarrett/stuff/screenshots/3.2.21-xenomai-2.6.1.png
[17:52:35] <dgarr> memleak: its a script i've been working on, requires linuxcnc and linuxcnc-dev for the comp utility, the program is http://www.panix.com/~dgarrett/stuff/lhisto.tcl
[17:52:53] -!- halo_cast has quit [Excess Flood]
[17:54:26] <memleak> Ah, I was wondering why I couldn't find it!
[18:02:16] -!- mhaberler [mhaberler!~mhaberler@089144206085.atnat0015.highway.a1.net] has joined #linuxcnc-devel
[18:05:50] <memleak> mhaberler, hello!
[18:06:52] <L84Supper> lat min| -2.342 ----lat avg| -2.247 ----lat max -1.426 the jitter is <1uS
[18:07:05] <mhaberler> hi!
[18:07:55] <memleak> Anyone interested in the kernel config?
[18:08:06] <memleak> Where to post?
[18:08:35] <L84Supper> lets see what is does on an AMD APU powered laptop this weekend :)
[18:09:21] <L84Supper> memleak: sticky pastebin for 30 days for now
[18:10:49] <L84Supper> that's actually the lowest jitter we have seen so far on AMD
[18:13:37] <mhaberler> memleak: you really want to look to the xenomai ML - this is where ipipe happens these days
[18:14:15] <memleak> I actually work behind the curtain with IPIPE.. before it even hits the mailing list.. ;)
[18:14:54] <mhaberler> q: whose curtain, Philip G?
[18:15:18] <memleak> Mante
[18:15:32] <memleak> One hell of a coder btw
[18:16:35] <mhaberler> are you sure you're working with the right strand - does this come from the denx ipipe repo?
[18:16:58] <memleak> I'm working with stuff before it hits adeos.
[18:17:42] -!- wboykinm has quit [Read error: Connection reset by peer]
[18:18:52] <mhaberler> I am a bit unsure what you are trying to achieve, get xenomai to work with some ipipe patch by Paolo?
[18:18:52] <memleak> http://code.google.com/p/neo-technical/downloads/detail?name=config-3.5.3-IPIPE kernel config
[18:19:20] <L84Supper> I can ask Eric Biederman for input on more tweaking
[18:20:35] <mhaberler> so you are working on an RTAI kernel?
[18:20:40] <memleak> No the reason I got involved with the early development of IPIPE with mante was to get 3.x kernel support stable enough on RTAI specifically, and today I'm here to get the latest Xenomai code working with the latest EMC with low latency.
[18:21:03] <memleak> and to also help others accomplish the same goal, hence me uploading my kernel config as a good base for others.
[18:21:27] <L84Supper> mhaberler: http://pastebin.ca/2299429 is his latency with xenomai with AMD
[18:22:31] <mhaberler> negative latencies… how would you explain that? you're sure the hires timers work properly?
[18:23:04] <mhaberler> I think you should hook this thing up to a scope and a mesa card, and measure on the scope
[18:23:26] <mhaberler> the parport doesnt cut it, it adds some3-5usec
[18:23:54] <mhaberler> or better do a velocity stepgen at fixed rate in a mesa card and read back the values, then you have something credible
[18:24:17] <L84Supper> will have to get more mesa cards
[18:24:30] <mhaberler> I mean I'd be happy if that is confirmed by actual measurements, but that looks a tad odd to me
[18:24:38] <memleak> I'm not running real hardware on this machine, its just a test system for latency. I'm about to run the latency test built into EMC's and dgarr's latency test too.
[18:25:11] <L84Supper> it's a real MB and CPU, just no Mesa cards attached
[18:25:31] <memleak> right.
[18:26:28] <L84Supper> where does that latency test throw a real world signal we can monitor?
[18:26:34] <mhaberler> could you look into the xenomai latency test source and check how it is anywhere possible to arrive at a negative latency, and what that could mean? I would got to the xenomai mailing list with that
[18:26:37] <mhaberler> non
[18:27:10] <mhaberler> what you could do is a halcomp and look at TSC values, but that has its own set of problems
[18:27:40] <memleak> I'm compiling GCC now with 4 compiling jobs in parallel with four instances of glxgears running, will post latency in a bit.
[18:27:48] <L84Supper> "It depends on what platform you are running. But from the results you get, you are probably running latency on x86_64, without any load. The
[18:27:49] <L84Supper> results you get doing so are probably meaningless. If you wonder about the negative latencies, they simply mean that your system is not calibrated correctly."
[18:27:55] -!- ybon has quit [Quit: WeeChat 0.3.8]
[18:27:59] <mhaberler> my recommendation is a $95 5i25, stepgen at a fixed rate in velocity mode, like 10mhz, and read back the position values through hostmot 2 in the base thread
[18:28:05] <mhaberler> that are real numbers
[18:28:09] <L84Supper> http://www.xenomai.org/pipermail/xenomai-core/2011-03/msg00035.html
[18:28:45] <mhaberler> aja
[18:28:47] <memleak> http://pastebin.ca/2299433
[18:29:18] <cncbasher> http://imagebin.org/241731
[18:29:25] <mhaberler> is that post 'calibration'?
[18:29:54] <mhaberler> wow!
[18:30:29] <L84Supper> not too shabby
[18:30:38] <memleak> which?
[18:30:47] <mhaberler> that is _very_ good
[18:30:51] <L84Supper> cncbasher
[18:31:11] -!- sumpfralle has quit [Ping timeout: 246 seconds]
[18:31:50] <mhaberler> cncbasher: do you have a mesa card in this box?
[18:31:55] <cncbasher> yes
[18:31:58] <cncbasher> 7i43
[18:32:10] <mhaberler> ah...
[18:32:29] <mhaberler> not good for measurement because the parport adds a ton of delay
[18:32:37] <mhaberler> 'ton' relative to what we're looking at here
[18:32:59] <pcw_home> Yeah 7I43 is ~6 usec/32 bit access
[18:33:01] <mhaberler> where's Peter with a freebie when we need him;)
[18:33:06] <cncbasher> such a pity in that case
[18:34:12] <pcw_home> i dont mind donating few 5I25s for measurement duty
[18:34:36] <mhaberler> memleak: if you dont go the Mesanet stepgen route, I'd suggest cooking a small halcomp which determines latency by looking at the TSC
[18:34:39] <memleak> hey my negative numbers went away!
[18:34:44] <mhaberler> see
[18:34:51] <L84Supper> memleak has only worked on this for a few hours, we were planning on really working on this in a couple more weeks
[18:35:02] <memleak> mhaberler, echo 0 > /proc/xenomai/latency
[18:35:08] <mhaberler> right
[18:35:31] <mhaberler> could you pastebin one more latency snapshot?
[18:35:59] <mhaberler> *all* figures positive including min, max ?
[18:36:05] <memleak> http://pastebin.ca/2299434
[18:36:17] <memleak> still 4 compiling jobs
[18:36:29] <memleak> while running the test
[18:36:42] <mhaberler> ok, all positive - just sanity checking
[18:36:59] <mhaberler> well if that holds up that is an excellent result, congratulations!
[18:37:08] <memleak> thanks! :D
[18:37:38] <L84Supper> ~8us vs 4us with RTAI
[18:37:44] -!- yuvipanda_ has quit [Remote host closed the connection]
[18:37:47] <andypugh> Though the only real reason to go to Xenomai was because RTAI didn't support 3.x kernels...
[18:38:20] <memleak> andypugh, thats why i worked / working with mante, because the plan was to get it going. still is.
[18:38:38] <L84Supper> memleak: when did Mante expect to have 3.x kernels supported?
[18:38:40] <memleak> back in august him and i hacked away quite a bit OTR
[18:38:49] <mhaberler> andypugh: I guess you missed out on a few important reasons
[18:39:05] <memleak> he didn't mention an ETA
[18:39:25] <memleak> hal.immed is the biggest haul-up
[18:39:33] <memleak> err hold-up
[18:39:50] <mhaberler> hal.immed? whazat?
[18:40:03] <andypugh> mhaberler: Well, yes. I think what I meant to say was that if there had been a 3.x kernel RTA when 12.04 came out then we might not have been worrying about this right now.
[18:40:19] <jepler> hm, you could make a ghetto time stamp with an arduino and a parport pin. parport -> arduino -> usb serial. build a 24+-bit free-running counter out of the avr's 16-bit timer/counter, and write its value to serial whenever the input pin toggles
[18:40:37] <mhaberler> I would worry a lot - the RTAI programming model - kernel RT - is extinct
[18:40:39] <jepler> only around 1us of I/O time to toggle a parport pin
[18:40:42] <memleak> mhaberler: http://cvs.gna.org/cvsweb/vulcano/base/arch/i386/hal/hal.immed?rev=1.70;content-type=text%2Fplain;cvsroot=rtai
[18:41:28] <memleak> also arch/x86_64/hal etc etc
[18:41:40] <mhaberler> jepler: I get around 2,5 usec on my atom dw525 doing that
[18:42:19] <andypugh> mhaberler: It seems to me to be "Vulnerable" or possibly "Critically Endangered" rather than "Extinct" at the moment. (to borrow the UICN Red List categories. :-)
[18:42:29] <pcw_home> Probably depends on PP hardware (D525 is LPC as I recall)
[18:42:47] <mhaberler> for the moment, yes - coding for it - i.e. future - pretty bad idea
[18:43:04] <pcw_home> (LPC is serialized ISA bus)
[18:43:39] <mhaberler> memleak: I am still loosing you - this is RTAI code? are you trying to do an 3.5x RTAI kernel?
[18:44:13] <memleak> I _was_ and then I stalled out.
[18:44:53] <jepler> I missed why we started talking about TSC vs actually measuring against external hardware, though
[18:44:56] <mhaberler> pcw_home: just the builtin pp on the dw525, tried nothing else
[18:44:57] <mhaberler> ah, welcome to the club ;)
[18:45:01] <memleak> if i worked on it consistently since, it'd probably be done by now.
[18:45:10] <jepler> is there a specific doubt about TSC validity, or just curiosity?
[18:45:12] <memleak> paolo and i work as a great team :)
[18:45:46] <jepler> > A patch to fix this bug has been released by Microsoft, but newly installed Windows 95 and 98 operating systems will still have the bug.
[18:45:52] <jepler> hah, thanks wikipedia for warning us about this!
[18:46:26] <memleak> Well i'll have to really try and make sure I don't do any fresh 95 or 98 installs!
[18:46:27] <pcw_home> mhaberler: yes that is LPC I think (which is pretty slow) a PCI parallel port card would
[18:46:28] <mhaberler> I think there are two realistic methods - TSC if you can be sure that TSC is for real, or reading back from a PCI card with a very fast counter on it
[18:46:29] <pcw_home> most likely be be faster
[18:48:14] <pcw_home> The TSC may be optimistic as I/O or memory access may be blocked in hardware
[18:48:15] <pcw_home> the counter or toggle PP bit are more realistic
[18:48:17] <mhaberler> so for a coarse validation a halcomp with TSC read would give an indication if OS-derived latencies are real
[18:49:55] <mhaberler> I have no idea how constant such PP I/O delays actually are; if they were that would cancel out
[18:50:30] <jepler> if there are variable PP I/O delays that would be interesting to people using that type of I/O
[18:50:33] <mhaberler> any idea if there is a chance of fluctuation for these I/O delays? bus contention maybe? cache?
[18:50:56] <mhaberler> yes, very much so
[18:51:36] <memleak> if you want to minimize I/O delays you should use memory compaction with transparent tables, cleancache and zcache
[18:51:55] <mhaberler> uh
[18:52:10] <memleak> zcache w/ zlib and other "compression buddies"
[18:52:14] <mhaberler> can you explain the causal chain to a pedestrian
[18:52:31] <mhaberler> zlib.. how exactly does that play in here?
[18:52:40] <memleak> one moment.
[18:53:16] <jepler> hm, there may be a free-running 24-bit, 3579545Hz timer living at PORT_ACPI_PM_BASE + 0x8 on most modern hardware. https://patchwork.kernel.org/patch/1405181/
[18:53:24] <jepler> most modern PC hardware, anyway
[18:53:39] <mhaberler> 25x nsec rate, hm
[18:55:12] <memleak> in kernel
[18:55:42] <jepler> memleak: this is I/O as in 'outb', not as in disk I/O or anything else higher-level
[18:55:49] <mhaberler> sorry, lost in terms here - why and how are those anywere relevant to I/O jitter on parports?
[18:56:04] <mhaberler> ah, that might be the confusion
[18:56:14] <memleak> oh those I/Os.. :/
[18:56:51] -!- yuvipanda_ has quit [Ping timeout: 260 seconds]
[18:57:05] <memleak> I thought zcache went lower but oh well..
[18:57:07] <mhaberler> reword: my question is: if you do outb(parport) - is there a chance the time between execution of the insn and the pin changing state being variable, e.g- due to bus contention or caching (CPU caches, that is)
[18:57:15] <mhaberler> do we know that?
[18:57:56] <mhaberler> and if it is, can there be a upper bound (worst case) given
[18:58:32] <mhaberler> that would be the requirement for using scope on parport pin and saying anything about RTOS latency based on what the scope sees
[18:59:34] <mhaberler> jepler: that timer would be an interesting cross-check, for instance if TSC is credible
[19:00:18] <mhaberler> i.e. the their multiple is constant, or not
[19:01:00] <pcw_home> Yes. I wonder where in the bus hierarchy that timer is located
[19:01:02] <pcw_home> (the TSC is optimistic because its a CPU register and always available regardless of the I/O system)
[19:01:19] <mhaberler> there are side effects though, I think TSC read can cause a pipeline stall
[19:01:41] <mhaberler> i.e. speculative jump prefetch
[19:02:17] <memleak> well you cant just turn off X86_TSC can you?
[19:02:47] <mhaberler> what does that buy you?
[19:03:00] <mhaberler> compared to not reading it
[19:03:01] <memleak> hmm?
[19:03:23] <mhaberler> why would you want to turn it off?
[19:03:53] <mhaberler> in linuxcnc terms, TSC read is a queuebuster operation
[19:03:54] <memleak> "TSC read can cause a pipeline stall" so to avoid that pipeline stall..
[19:04:26] <jepler> I'd just like to mention that I hate the outb (et al) manpage
[19:04:33] <memleak> XD
[19:05:03] <mhaberler> I'm not suggesting not to use it; all I'm saying using it has a minor impact on timing, so it isnt a very good 'measurement probe'
[19:05:42] <mhaberler> blindly reading the TSC and believing might cause a surprise, thats all (not much of a surprise)
[19:06:24] <mhaberler> then on earlier CPU's TSC wasnt at constant rate, but thats mostly fixed I think (CPU freq scaling came in)
[19:06:44] <mhaberler> the /proc/cpuinfo says a bit about it
[19:06:47] <memleak> I also can't imagine how well normal applications would function without any TSC.
[19:07:07] <memleak> CPU freq is a definite no with RT purposes
[19:07:24] <mhaberler> I dont think they use it very much; maybe some profiler
[19:08:19] <mhaberler> anyway, I'm heading out, so let me summarize and see I got it right:
[19:08:55] <mhaberler> you have a 3.5x xenomai kernel with latency figures on an AMD which redefine the laws of electronics ;)
[19:10:02] <mhaberler> I just want to understand what workflow you used, because you confuse me with RTAI code interspersed, and the xenomai folks are working on 3.5.3 kernel as well
[19:10:22] <mhaberler> did you use the latter? if so, where is a place for the rtai code you posted?
[19:10:26] -!- psyhitus has quit [Read error: Connection timed out]
[19:10:49] -!- IchGuckLive has quit [Remote host closed the connection]
[19:11:21] -!- guest_______ has quit [Quit: Page closed]
[19:11:47] -!- holger has quit [Quit: ChatZilla 0.9.89 [Firefox 17.0.1/20121129170341]]
[19:12:20] <memleak> redefine the laws of electronics? if you're referring to the negatives, they're fixed, as you saw.
[19:12:25] <mhaberler> jepler: is there a way/a low-latency way to read that acpi pm timer from userland?
[19:12:37] <mhaberler> sure.. just pulling your leg - it looks very good
[19:12:49] <jepler> mhaberler: I'm not sure about that yet...
[19:12:51] <memleak> I am not using any RTAI code today as I simply trying to help out those in IRC get Xenomai working.
[19:13:13] <mhaberler> maybe it can be mmap()ed/iomap()ed
[19:13:37] <jepler> I think that it is this I/O port that can be seen named on both systems where I looked (one AMD, one Intel): 0408-040b : ACPI PM_TMR
[19:13:46] <jepler> but it's at 0808 on one of the two systems; not a fixed address.
[19:13:52] <memleak> My RTAI code I was working on in August has nothing to do with this and none of the code is public yet as it is still in early development. I worked with mante, haven't talked to him in awhile, haven't proceeded with my mission to get 3.x kernel support for RTAI in awhile.
[19:14:01] <jepler> also it's a sub-port of pnp 00:0a on one machine, 00:0b on the other
[19:14:46] <mhaberler> so the pastebins you posted are rtai latencies, right?
[19:14:51] <memleak> nope
[19:15:01] <memleak> "My RTAI code I was working on in August has nothing to do with this"
[19:15:11] <mhaberler> ok
[19:15:36] <memleak> I feel like no matter how many times I try and say Xenomai, you still insist on me using RTAI...
[19:15:51] <mhaberler> I just got confused, thats all
[19:15:58] <memleak> Alright.
[19:16:32] <mhaberler> well that would be worth replicating on other machines and see if the figures are consistent
[19:16:48] <mhaberler> I'll fix your account later, am on mobile now
[19:16:56] <memleak> Everything I've touched yesterday and today have all been 100% xenomai. Yeah I'll do that :)
[19:17:05] <memleak> Not today but someday.
[19:17:24] <mhaberler> I would be very interested to see that side by side relative to the older kernels on a plot
[19:17:30] <pcw_home> Sounds really good, I wonder why skunkworks had such dismal numbers?
[19:17:53] <mhaberler> it must be earth rays over there toggling some BIOS bits
[19:17:55] <memleak> pcw_home, thats why i got on IRC in the first place. main reason I'm here in fact :)
[19:18:05] -!- halo_cast has quit [Ping timeout: 246 seconds]
[19:18:43] <jepler> mhaberler: http://emergent.unpythonic.net/files/sandbox/pmtmr.c enjoy
[19:18:52] <mhaberler> pcw_home: I dont get this either, even my beaglebone figures are consitently below 40/32 with a massive nfs-based build on the side
[19:18:55] <jepler> on my box it spews lots of lines like this:
[19:18:56] <jepler> http://emergent.unpythonic.net/files/sandbox/pmtmr.c
[19:18:57] <jepler> err
[19:19:01] <jepler> like this:
[19:19:02] <jepler> 3844 2671414142
[19:19:02] <jepler> 3856 2671417998
[19:19:02] <jepler> 17851437 2689269435
[19:19:02] <jepler> 3845 2689273280
[19:19:21] <memleak> eww!!!
[19:19:33] <jepler> where an actual 1ms interval would be ~3579 delta so it is obviously detcting latencies in my non-real-time system
[19:19:47] <mhaberler> that makes a lot of sense
[19:20:05] <andypugh> I get latencies in the billions on my VMs :-)
[19:20:16] <mhaberler> could be very useful, thanks for looking into that!
[19:20:19] <jepler> a latency more than one counter wrap, 3579545Hz/2^24 ~= .21s, would not be explicitly detected
[19:20:27] <mhaberler> well right, such is life in vbox
[19:20:30] <skunkworks> well - following these directions... http://wiki.linuxcnc.org/cgi-bin/wiki.pl?NewRTInstall
[19:21:03] <skunkworks> Is there something that i am missing? And this is running the latency-test
[19:21:55] <mhaberler> I really gotta run, but - could you check the Xenomai 'how to massage your BIOS' page? I need to dig if I can find it
[19:22:30] <mhaberler> jepler: there was a kernel reschedule between sample 2 and 3, clearly
[19:24:38] <mhaberler> memleak: I'll send you mail about the repo later; just push and add some notes in the linuxcnc subdir, and the configs and build instructions you used
[19:25:02] <memleak> skunkworks, maybe the .deb kernel doesn't work for your computer
[19:25:35] <memleak> also xenomai and kernel are older than the ones i used to get good latency
[19:25:59] <mhaberler> well the boot issue is a simple driver/cant find root fs issue, this fails way before any xenomau-related initialisation happens
[19:26:10] -!- bradsimantel has quit [Ping timeout: 276 seconds]
[19:26:20] <memleak> i did it all from scratch to make sure it was done right. i dont rely on debs and rpms anymore.
[19:26:32] <memleak> (for your exact problem skunkworks)
[19:26:33] <mhaberler> skunkworks - mail me the 'dmesg' output of successful boot with a working kernel
[19:26:41] -!- micges [micges!~micges@dhr150.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[19:27:08] <mhaberler> ok, streets are being rolled up, I need to run - cu
[19:27:30] <memleak> bye mhaberler !
[19:27:44] <mhaberler> great work - cu!
[19:28:05] -!- mhaberler has quit [Read error: Connection reset by peer]
[19:29:02] <jepler> ugh, some (old?) chips may have very broken pm_tmr. http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/arch/i386/kernel/timers/timer_pm.c?v=
[19:31:16] -!- chillly has quit [Ping timeout: 248 seconds]
[19:32:39] <jepler> er, the overflows are ~4.6s so it would take a really bad latency to be out of the scale of the pm_tmr
[19:33:59] <jepler> the location of pm_tmr seems to be in the south bridge, so whatever are the sources of "I/O" latency, it would include less than for ISA/LPC peripherals but more than for memory / internal to the CPU
[19:35:01] -!- micges has quit [Quit: Leaving]
[19:40:48] -!- DJ9DJ has quit [Quit: bye]
[19:43:01] <memleak> skunkworks, I'll be working on a wiki on my google code page for building Xenomai, the kernel and all that stuff from source so if there's an issue you can fix it yourself.
[19:43:51] <memleak> it'll be really in-depth and easy to follow too
[19:44:41] <cncbasher> i'll be following also .. it's extremely interesting and need to get my head around it all , so it all helps
[19:45:05] <memleak> it'll explain how everything connects and all too, not a flow chart but you'll get the idea :)
[19:46:24] -!- micges [micges!~micges@dhr150.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[19:50:12] <skunkworks> THanks everyone. I will get a dmesg from the first one I started playing with.
[19:53:13] <skunkworks> THis one http://imagebin.org/index.php?mode=image&id=241442
[19:53:55] <memleak> weird.. i cant compile EMC with --with-threads=xenomai or whatever..
[19:54:29] <skunkworks> I think if xenomai is the only realtime kernal you have - it will know to use it.
[19:54:51] <skunkworks> (try it without the --with.....
[19:55:10] <memleak> it doesnt work..
[19:55:22] <memleak> --with-threads is an invalid option
[19:55:31] <memleak> checking for RT dir... configure: error: RT not found.
[19:55:47] <memleak> --with-realtime=/usr/xenomai doesn't work either..
[19:56:37] <memleak> do we need RTAI userspace? or should EMC work with Xenomai kernel and xenomai userspace?
[19:56:53] <skunkworks> are you running mahs repository?
[19:57:01] <memleak> mahs is..?
[19:57:05] <memleak> well, obviously not.
[19:57:31] <skunkworks> git clone git://git.mah.priv.at/emc2-dev.git linuxcnc-rtos
[19:57:56] <memleak> oh mhaberler 's tree???!
[19:58:17] <memleak> that's what he was going to give me commit rights to!! ahhhh!!
[19:58:29] <memleak> i was wondering what this was all about
[19:58:47] <skunkworks> I have not been paying that close attenction - but I don't think that stuff is in the actual linuxcnc repository....
[19:59:06] <skunkworks> yet
[19:59:08] <memleak> it isn't. that explains my problem.
[19:59:12] <memleak> alright thanks!
[19:59:58] <memleak> well this'll be fun :)
[20:00:07] -!- chopper79 has quit [Quit: Leaving.]
[20:01:22] -!- micges has quit [Quit: Leaving]
[20:03:29] <jepler> I kept fiddling with my pmtmr program. http://emergent.unpythonic.net/files/sandbox/pmtmr2.c
[20:04:01] <memleak> you're good at C :)
[20:04:09] <jepler> I wallow in it daily
[20:04:21] <memleak> looks that way!
[20:06:56] <memleak> does anyone know if a real-time system will work though with RTAI userspace?
[20:07:08] <memleak> Xenomai kernel with RTAI downloaded and installed to /usr/realtime
[20:18:01] <skunkworks> cncbasher, how did you go about installing the xnomi on your system?
[20:18:44] <skunkworks> xenomai/linuxcnc?
[20:19:20] <memleak> skunkworks, userspace is ./configure --prefix=/usr/realtime ; make ; sudo make install
[20:19:42] <memleak> kernel is scripts/prepare-kernel.sh in xenomai tree
[20:20:32] <memleak> if you're gunna build from source though you should remove all those debs very good in advance
[20:20:41] <memleak> my guide should be up later on today
[20:20:50] <memleak> g2g for now, bye everyone
[20:58:20] -!- tjb1 has quit [Quit: tjb1]
[21:01:27] -!- micges [micges!~toudi@dhr150.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[21:14:08] -!- bedah has quit [Read error: Connection reset by peer]
[21:16:52] -!- chopper79 has quit [Quit: Leaving.]
[21:19:17] -!- psyhitus has quit [Ping timeout: 248 seconds]
[21:19:43] -!- vladimirek has quit [Remote host closed the connection]
[21:21:55] -!- paul___ has quit [Quit: Page closed]
[21:25:45] <skunkworks> wow - finally found a system with usable latency I think...
[21:25:50] <cncbasher> skunkworks: sorry been with the kids for a while ? , just seen your post
[21:26:07] <skunkworks> http://imagebin.org/241748
[21:26:17] <skunkworks> cncbasher, no problem. Been busy too
[21:26:40] <skunkworks> It doesn't seem to go above 25us atleast
[21:28:24] <cncbasher> looks good
[21:29:28] <skunkworks> sliding out a little - still under 25us http://imagebin.org/241748
[21:29:48] <skunkworks> oops - http://imagebin.org/241749
[21:29:56] -!- Loetmichel has quit [Ping timeout: 255 seconds]
[21:30:33] <cncbasher> i used the kernels from micheal and just about followed his instructions , and based a script on it for future use haha
[21:42:21] <skunkworks> heh
[21:42:22] <skunkworks> ok
[21:42:39] -!- erasmo [erasmo!~erasmo@] has joined #linuxcnc-devel
[21:43:01] <skunkworks> I just wanted to make sure I wasn't missing anyting. It just looks like the kernel is generic enough yet - or needs different builds based on hardware...
[21:43:03] <cncbasher> what mesa card are you running
[21:43:33] <skunkworks> I don't have any here - but the K&T uses a2 5i20's
[21:43:38] <skunkworks> *2
[21:43:50] <cncbasher> arh ok ..
[21:44:35] <cncbasher> i'm using a 7i43 , so taken that the 5i20 is about 10 times faster
[21:44:46] <cncbasher> you should be fine
[21:45:22] <skunkworks> oh - sure - for survo thread systems - 25us would be fine
[21:45:55] <cncbasher> my test setup here is steppers
[21:46:14] <cncbasher> and it runs them fine
[21:47:21] <skunkworks> printer port steppers
[21:47:23] <skunkworks> ?
[21:48:06] <cncbasher> 7i43 is parrell port connected yes , so a lot more overhead than a pci card of course
[21:48:31] <skunkworks> oh - but still - you only need the servo thread
[21:48:38] <cncbasher> yes
[21:48:42] <skunkworks> cool.
[21:49:03] <skunkworks> I have a pluto-p - similar setup - crappier design.
[21:49:53] <cncbasher> it should work
[21:50:00] <cncbasher> try it
[21:52:09] <cncbasher> have to go , granddaughter needs her bedroom back ... haha
[21:57:49] -!- FinboySlick has quit [Quit: Leaving.]
[21:58:03] -!- erasmo has quit [Remote host closed the connection]
[22:08:22] -!- chopper79 has quit [Quit: Leaving.]
[22:19:35] -!- sc__ has quit [Quit: Page closed]
[22:32:26] -!- skunkworks has quit [Read error: Connection reset by peer]
[22:33:20] -!- odogono has quit [Quit: odogono]
[22:34:12] <zultron> Hey memleak, you're building xeno 3.5.3?
[22:36:10] <andypugh> Sounds like the photo was as ComicCon. I haven't been to that.
[22:36:23] <andypugh> Wrong channel.
[22:36:23] <memleak> zultron yep. Writing the documentation now.
[22:36:50] <memleak> Figured it all out like the back of my hand :)
[22:37:47] <zultron> Sweet!
[22:38:14] <zultron> I went with 3.2.21 because there's a .deb for precise.
[22:38:49] <zultron> Funny thing is the ipipe-core patch for 3.2.21 has a bug that breaks compilation. No idea how that got through testing.
[22:39:06] <memleak> there are several 3.2.21 patches
[22:39:17] <zultron> Yup, I'm using -2.
[22:39:26] <memleak> -3 is newer and more stable.
[22:39:32] <memleak> http://git.xenomai.org/?p=xenomai-2.6.git;a=blob;f=ksrc/arch/x86/patches/ipipe-core-3.2.21-x86-3.patch;h=4abe18540736d20c179202a745a5c007d1f54d41;hb=HEAD
[22:40:02] <memleak> This is exactly why I'm documenting all this stuff, so everyone knows all the goodies!
[22:40:14] <zultron> Oh, didn't see that. I was using the one from the xenomai distribution.
[22:40:15] -!- chillly has quit [Quit: Leaving]
[22:40:39] <memleak> 2.6.2 has it, 2.6.1 doesn't IIRC. 2.6.1 has .debs, 2.6.2 isn't packaged yet.
[22:40:45] <memleak> at least not that I'm aware of.
[22:41:13] <zultron> Hmm, I'm using the v2.6.2 git tag....
[22:41:44] <memleak> Ah 2 days after the 2.6.2 git tag, -3 was added, sorry about that.
[22:42:24] <zultron> I see, so I ought to build xenomai from master then.
[22:43:11] <memleak> I'd recommend following xenomai-2.6.git unless you want 2.7 right when it comes out, follow -head
[22:43:22] <zultron> It was nice that the /debian stuff just works. Wish that were true for the ubuntu make-kpkg stuff.
[22:44:10] <memleak> I'll have my wiki page done in about an hour or so, wanna just sit tight until my instructions are up?
[22:44:34] <memleak> I'm getting into all the corners of building xenomai along with a good sample kernel config
[22:45:47] <zultron> Sure, I'd like to see it. I've already been through this routine with el6, including a few days of bisecting kernel .configs, so I'm a bit familiar by now.
[22:46:18] <zultron> I'm not wrestling with xeno itself, just the .deb stuff.
[22:46:57] <zultron> None of the ubuntu docs for creating custom kernel *flavours* are up to date.
[22:47:13] <memleak> so just do it by hand :)
[22:47:44] <memleak> ive done it the old fashioned way before. nothing breaks using cp -prv arch/x86/boot/bzImage /boot/vmlinuz-custom then modifying grub via text editor
[22:48:08] <memleak> no initrds, no weird nonsense
[22:48:57] <zultron> If I were building this for myself, I might. Actually, I don't even use debian, so I'm doing this for folks who just want to point at a repo and 'apt-get install' or 'yum install'.
[22:50:00] -!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc-devel
[22:50:15] <memleak> if you're gunna do that i'd suggest basing your kernel config off of mine at least. the only parts which you should touch is the SCSI / ATA stuff and maybe some I2C options
[22:50:17] <zultron> Actually, I generate packages for myself, too. The configuration management system in the shop knows what to do with them. ;)
[22:50:34] -!- vladimirek [vladimirek!~vladimire@] has joined #linuxcnc-devel
[22:50:54] <zultron> Yeah? What kind of changes do you make?
[22:51:49] <memleak> i made a bunch of changes, too many to go over.
[22:52:15] -!- shurshur has quit [Quit: ChatZilla 0.9.89 [Firefox 10.0.1/20120208060813]]
[22:53:42] <zultron> The reason to base the config off the distro's packages is their configs run on a LOT of different hardware, even if they're not optimized for RT.
[22:54:38] <zultron> Otherwise I'll end up with folks whose machines don't boot or have other problems, and I'm not planning to support these. ;)
[22:55:09] <memleak> I'm aware of all of this, which is why I mentioned some specifics to change.
[22:55:39] <memleak> Not to brag but I'm awfully skilled with compiling kernels so don't worry. In fact I'll make the changes myself.
[22:56:35] <memleak> I'm make them more universal yet still incredibly optimized and tweaked as much as possible without hurting compatibility, or at least leaving it pretty well compatible.
[22:56:41] <zultron> Well, that's an awful kind offer. I think I'd like to take you up on that.
[22:56:45] <memleak> *I'll
[22:56:51] -!- servos4ever has quit [Quit: ChatZilla 0.9.85 [SeaMonkey 2.0.11/20101206162726]]
[22:56:56] <memleak> Ok, just sit tight. I'll generate 32-bit and 64-bit configs.
[22:57:08] <zultron> You're also working on beaglebone configs right?
[22:57:19] <memleak> Just x86, sorry.
[22:57:53] <memleak> In my case a powerhouse desktop
[22:58:02] <zultron> Ah well. Anyway, I can just grab any working config for that, and at least not have to worry about hardware diffs.
[22:58:12] <zultron> Thanks, memleak.
[22:59:40] <memleak> x86 kernel configs have to be done right..
[23:00:24] <memleak> I personally know all the options inside and out. Just because its x86 doesn't mean it's easy and any config will do. Mine also have pretty low latency.
[23:00:34] <memleak> I'm working on them right now.
[23:02:53] <zultron> Sounds fantastic. I'll leave you to it.
[23:03:14] <memleak> is the pentium pro CPU selection OK?
[23:03:37] <memleak> arch linux uses it, seems pretty compatible, fast too but 686 only
[23:03:58] <zultron> I don't see any reason to support 386 arch.
[23:04:18] <memleak> ok pentium pro it is
[23:11:52] -!- chopper79 has quit [Quit: Leaving.]
[23:15:17] -!- paul_liebenberg has quit [Quit: paul_liebenberg]
[23:15:25] <seb_kuzminsky> 386 support was recently dropped from the linux kernel
[23:21:16] <zultron> (Whoops, xenomai /debian did NOT just work; I've got a few patches...)
[23:22:16] -!- vladimirek has quit [Remote host closed the connection]
[23:25:02] -!- zzolo has quit [Quit: zzolo]
[23:25:53] <memleak> been awhile since i last used a 32-bit machine
[23:26:06] <memleak> lots of weird config options heh
[23:43:42] <memleak> zultron, im just going to generate a baseline for 32-bit, im not sure how universal you want it so i'm just going to leave it up to you.
[23:44:01] <memleak> i keep starting over
[23:47:46] <memleak> it'll boot on anything but wireless and everything i dont use wont work out of the box
[23:55:04] -!- pfred1 has quit [Quit: ..]
[23:59:37] <memleak> zultron, http://code.google.com/p/neo-technical/downloads/detail?name=x86.config