Back
[00:02:31] -!- mephux has quit [Excess Flood]
[00:04:12] -!- Nick001-Shop has quit [Remote host closed the connection]
[00:04:13] -!- logger[mah] has quit [Remote host closed the connection]
[00:04:19] -!- logger[mah] [logger[mah]!~loggermah@ns2.mah.priv.at] has joined #linuxcnc-devel
[00:15:16] -!- mephux has quit [Excess Flood]
[00:20:42] -!- KimK has quit [Read error: Connection reset by peer]
[00:22:03] -!- KimK [KimK!~Kim__@wsip-184-176-200-171.ks.ks.cox.net] has joined #linuxcnc-devel
[00:26:10] -!- JT-Shop-2 [JT-Shop-2!~John@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[00:26:11] -!- JT-Shop has quit [Read error: Connection reset by peer]
[00:26:12] -!- jthornton has quit [Read error: Connection reset by peer]
[00:26:14] -!- jthornton_ [jthornton_!~john@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[00:26:34] JT-Shop-2 is now known as JT-Shop
[00:34:04] -!- wildbilldonovan has quit [Quit: EOT]
[00:35:45] -!- Guest30769 has quit [Excess Flood]
[00:43:30] -!- sumpfralle has quit [Ping timeout: 276 seconds]
[00:46:49] -!- sumpfralle1 has quit [Read error: Connection reset by peer]
[00:50:36] -!- mephux has quit [Excess Flood]
[00:50:48] -!- KimK has quit [Read error: Connection reset by peer]
[00:51:36] -!- KimK [KimK!~Kim__@wsip-184-176-200-171.ks.ks.cox.net] has joined #linuxcnc-devel
[00:59:37] -!- mephux has quit [Excess Flood]
[01:00:37] -!- asdfasd has quit [Read error: Connection reset by peer]
[01:21:08] -!- KimK has quit [Read error: Connection reset by peer]
[01:22:37] -!- KimK [KimK!~Kim__@wsip-184-176-200-171.ks.ks.cox.net] has joined #linuxcnc-devel
[01:51:18] -!- KimK has quit [Read error: Connection reset by peer]
[01:52:14] -!- KimK [KimK!~Kim__@wsip-184-176-200-171.ks.ks.cox.net] has joined #linuxcnc-devel
[01:52:25] -!- plushy has quit [Read error: Connection reset by peer]
[01:55:10] -!- Guest65242 has quit [Quit: Page closed]
[02:07:20] -!- KimK has quit [Ping timeout: 256 seconds]
[02:22:39] -!- KimK [KimK!~Kim__@wsip-184-176-200-171.ks.ks.cox.net] has joined #linuxcnc-devel
[02:35:29] -!- Keknom has quit [Read error: Connection reset by peer]
[03:06:05] -!- tandoori has quit [Ping timeout: 246 seconds]
[03:14:12] -!- tjb1 has quit [Ping timeout: 256 seconds]
[03:14:12] tjb1_ is now known as tjb1
[03:15:36] -!- sumpfralle has quit [Ping timeout: 276 seconds]
[03:17:39] -!- zzolo has quit [Quit: zzolo]
[03:18:30] -!- Tom_itx has quit [Ping timeout: 260 seconds]
[03:18:43] -!- plushy has quit [Quit: Leaving.]
[03:29:01] -!- tjb1 has quit [Ping timeout: 264 seconds]
[03:29:01] tjb1_ is now known as tjb1
[03:29:46] -!- micges has quit [Quit: Leaving]
[03:39:09] -!- zzolo has quit [Client Quit]
[03:43:06] -!- JT-Shop-2 [JT-Shop-2!~John@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[03:43:07] -!- jthornton_ has quit [Read error: Connection reset by peer]
[03:43:08] -!- JT-Shop has quit [Read error: Connection reset by peer]
[03:43:09] -!- jthornton__ [jthornton__!~john@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[03:47:31] -!- zzolo has quit [Client Quit]
[03:50:07] -!- kwallace [kwallace!~kwallace@smb-41.sonnet.com] has joined #linuxcnc-devel
[03:51:38] -!- Tom_L has quit []
[03:51:59] -!- kwallace1 has quit [Ping timeout: 255 seconds]
[03:54:27] -!- Keknom has quit [Quit: Leaving.]
[04:28:25] -!- mephux has quit [Excess Flood]
[04:33:50] -!- Tom_itx has quit [Disconnected by services]
[04:33:55] Tom_garage is now known as Tom_itx
[05:03:30] -!- Loetmichel has quit [Ping timeout: 260 seconds]
[05:12:58] -!- psha[work] [psha[work]!~psha@195.135.238.205] has joined #linuxcnc-devel
[05:19:41] -!- FinboySlick has quit [Quit: Leaving.]
[05:55:02] -!- cmorley1 [cmorley1!~chris@S010600c09fc019c2.no.shawcable.net] has joined #linuxcnc-devel
[05:57:07] r00t4rd3d is now known as SkinnyWhiteKid
[05:57:46] SkinnyWhiteKid is now known as r00t4rd3d
[05:58:27] -!- cmorley has quit [Ping timeout: 256 seconds]
[06:03:00] -!- Fox_Muldr has quit [Ping timeout: 260 seconds]
[06:04:29] -!- kwallace1 [kwallace1!~kwallace@smb-171.sonnet.com] has joined #linuxcnc-devel
[06:06:19] -!- Gene34 has quit []
[06:06:28] -!- kwallace has quit [Ping timeout: 256 seconds]
[06:08:35] -!- capricorn_1 has quit [Remote host closed the connection]
[06:09:21] -!- chopper79 has quit [Quit: Leaving.]
[06:13:42] Cylly is now known as Loetmichel
[06:16:59] -!- RagingComputer has quit [Ping timeout: 255 seconds]
[06:35:49] -!- tjb1 has quit [Quit: tjb1]
[06:36:07] -!- kwallace1 [kwallace1!~kwallace@smb-171.sonnet.com] has parted #linuxcnc-devel
[06:56:15] -!- mhaberler [mhaberler!~mhaberler@extern-180.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[07:15:42] -!- cmorley1 has quit [Quit: Leaving.]
[07:30:07] -!- cmorley [cmorley!~chris@S010600c09fc019c2.no.shawcable.net] has joined #linuxcnc-devel
[08:05:31] -!- emel has quit [Excess Flood]
[08:15:06] -!- defaultro has quit [Ping timeout: 256 seconds]
[08:26:17] -!- psha[work] has quit [Ping timeout: 245 seconds]
[08:26:30] -!- psha[work] [psha[work]!~psha@195.135.238.205] has joined #linuxcnc-devel
[08:31:32] -!- RagingComputer has quit [Ping timeout: 256 seconds]
[08:34:57] -!- Faralla has quit [Quit: Leaving...]
[08:49:48] -!- firephoto has quit [Quit: ZNC - http://znc.in]
[08:52:23] firephoto_ is now known as firephoto
[08:55:03] -!- racycle has quit [Quit: racycle]
[09:17:32] -!- Tecan has quit [Ping timeout: 245 seconds]
[09:34:46] -!- kmiyashiro has quit [Quit: kmiyashiro]
[09:52:11] -!- adb [adb!~IonMoldom@178.211.237.94] has joined #linuxcnc-devel
[09:54:11] -!- dhoovie has quit [Ping timeout: 246 seconds]
[10:02:13] -!- KGB-linuxcnc has quit [Ping timeout: 276 seconds]
[10:03:48] -!- cradek has quit [Ping timeout: 276 seconds]
[10:04:12] -!- cradek [cradek!~chris@outpost.timeguy.com] has joined #linuxcnc-devel
[10:09:16] -!- KGB-linuxcnc [KGB-linuxcnc!~kgb-linux@git.linuxcnc.org] has joined #linuxcnc-devel
[10:39:54] -!- Poincare has quit [Quit: changing servers]
[10:55:15] -!- vladimirek has quit [Ping timeout: 260 seconds]
[10:55:48] -!- vladimirek [vladimirek!~vladimire@95.105.250.72] has joined #linuxcnc-devel
[11:17:21] -!- tandoori has quit [Changing host]
[11:24:56] -!- sumpfralle has quit [Remote host closed the connection]
[11:29:10] -!- toudi_ [toudi_!~toudi@egt68.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[11:29:14] toudi_ is now known as micges
[11:29:45] -!- mhaberler has quit [Quit: mhaberler]
[11:30:38] -!- syyl has quit [Ping timeout: 255 seconds]
[11:30:51] -!- mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[11:32:20] -!- shurshur has quit [Ping timeout: 255 seconds]
[11:35:41] -!- mackerski has quit [Ping timeout: 246 seconds]
[11:35:41] mackerski_ is now known as mackerski
[11:36:11] -!- sumpfralle has quit [Ping timeout: 256 seconds]
[11:49:11] -!- AR_ has quit [Ping timeout: 244 seconds]
[11:52:46] -!- mackerski has quit [Quit: mackerski]
[11:56:41] -!- sumpfralle has quit [Ping timeout: 256 seconds]
[11:57:48] -!- theos has quit [Disconnected by services]
[12:10:45] -!- linuxcnc-build has quit [Ping timeout: 248 seconds]
[12:11:03] -!- linuxcnc-build [linuxcnc-build!~linuxcnc-@174-29-75-7.hlrn.qwest.net] has joined #linuxcnc-devel
[12:12:32] -!- plushy has quit [Ping timeout: 256 seconds]
[12:16:00] -!- odogono has quit [Read error: Connection reset by peer]
[12:25:54] jthornton__ is now known as jthornton
[12:29:25] -!- odogono has quit [Read error: Connection reset by peer]
[12:38:22] -!- skunkworks has quit [Remote host closed the connection]
[12:51:18] -!- micges has quit [Quit: Leaving]
[13:06:39] -!- emel has quit [Excess Flood]
[13:12:18] -!- Valen has quit [Quit: Leaving.]
[13:21:49] -!- Faralla has quit [Read error: Connection reset by peer]
[13:29:49] -!- odogono has quit [Read error: Connection reset by peer]
[13:30:04] -!- skunkworks [skunkworks!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[13:36:42] -!- mackerski has quit [Quit: mackerski]
[13:40:59] -!- mackerski has quit [Client Quit]
[14:00:46] -!- odogono has quit [Read error: Connection reset by peer]
[14:03:23] -!- Thetawaves_ has quit [Quit: This computer has gone to sleep]
[14:16:31] -!- odogono has quit [Read error: Connection reset by peer]
[14:31:02] -!- odogono has quit [Read error: Connection reset by peer]
[14:33:35] JT-Shop-2 is now known as JT-Shop
[14:33:36] -!- chopper79 has quit [Quit: Leaving.]
[14:37:36] -!- mattions has quit [Ping timeout: 256 seconds]
[15:14:11] -!- mackerski has quit [Quit: mackerski]
[15:14:29] <skunkworks> mhaberler, yes - that worked - thanks
[15:14:54] <mhaberler> good; linuxcnc running?
[15:15:28] <skunkworks> yes and no...
[15:15:38] <mhaberler> no part first;)
[15:15:42] <skunkworks> http://imagebin.org/244668
[15:16:38] <skunkworks> Everything seens to build and run just fine - still yucky latency
[15:16:44] -!- mephux has quit [Excess Flood]
[15:16:56] <skunkworks> THis system is sub 15us with rtai
[15:17:17] <mhaberler> is this a software stepgen config?
[15:17:59] -!- zzolo has quit [Client Quit]
[15:18:57] <skunkworks> mhaberler, I am just testing computer hardware
[15:20:50] <skunkworks> why does the servo thread seem to stay under 20us?
[15:22:12] <mhaberler> we're still tracking down a config issue which has to do with timing; not sure it will make a difference
[15:22:58] <mhaberler> could you pastebin a complete dmsg (so includes everthing from start of boot)?
[15:23:24] <skunkworks> sure
[15:25:06] <skunkworks> http://pastebin.ca/2308591
[15:27:32] <mhaberler> if you get around to it, could you do the same with an RTAI boot?
[15:31:27] <mhaberler> you have an oops during boot (line 736); maybe the irqpoll boot option helps
[15:32:18] <mhaberler> obviously Xenomai doesnt initialize on this hardware, it misses the telltale messages
[15:32:41] <mhaberler> try 'dmesg |grep Xenomai'
[15:33:30] <mhaberler> no wonder then
[15:34:05] -!- L84Supper2 [L84Supper2!~TheLarch@58.211.26.178] has joined #linuxcnc-devel
[15:34:05] -!- L84Supper2 has quit [Changing host]
[15:34:05] -!- L84Supper2 [L84Supper2!~TheLarch@unaffiliated/l84supper] has joined #linuxcnc-devel
[15:34:27] <mhaberler> see 'a basic Xenomai health check' here:
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?NewRTInstall
[15:35:17] <mhaberler> as long as that doesnt show up there's not much point in measuring timing; actually a wonder it's that good without the RT scheduler active
[15:36:01] <mhaberler> so we need to figure out why that dont come up: step 1 IMO is to get rid of the oops during boot, that could actually be the cause
[15:42:29] <pcw_home> That seems to be there (line 449...)
[15:42:31] <mhaberler> sorry, not true - line 449 shows Xenomai startup. strike out last messages..
[15:42:37] <mhaberler> uhum
[15:43:15] <skunkworks> http://pastebin.ca/2308600
[15:43:31] <mhaberler> sorry, my bad
[15:43:35] <skunkworks> no problem
[15:44:57] -!- cevad has quit [Ping timeout: 256 seconds]
[15:45:05] <pcw_home> Is it possible the servo/base thread priorities are swapped?
[15:46:22] <pcw_home> or is servo thread just dispatched after nth base thread invocation
[15:46:56] <mhaberler> no, the gist of the list discussion was the 'harmionic scheduler' is an unimplemented idea
[15:47:19] <mhaberler> it is all about relative timing accuracy
[15:48:39] <mhaberler> there's one Kconfig option CONFIG_XENO_OPT_TIMING_PERIODIC which we're currently trying to find out if needed/not needed/counterproducive (I guess the latter); this is set in the current kernel und could have to do with relative task timings
[15:49:12] -!- kwallace [kwallace!~kwallace@tmb-235.sonnet.com] has joined #linuxcnc-devel
[15:51:56] <pcw_home> I though currently the servo thread was just run at a sub-multiple of the base thread
[15:52:54] <mhaberler> yes, but calculated multiples; it is not strictly a harmonic scheduler in the sense that the multiples arent guaranteed, its a best-effort by the rt scheduler
[15:53:07] <mhaberler> are guaranteed
[15:54:38] <pcw_home> Yow!
[15:56:25] <mhaberler> right… that's those terminology discussions which few seem to enjoy and are totally fundamental to the cause
[15:56:39] -!- kwallace1 [kwallace1!~kwallace@smb-12.sonnet.com] has joined #linuxcnc-devel
[15:57:11] <mhaberler> John is currently working on a new build; let us give that a spin outselves before having you try it - QA, you know ;)
[15:58:07] <mhaberler> if it were a harmonic scheduler we'd have to have just one pyhiscal thread which schedules all others since the rt kernels care zilch
[15:59:01] <pcw_home> Yeah no point in generating jitter for yourself
[15:59:14] -!- kwallace has quit [Ping timeout: 246 seconds]
[15:59:22] <mhaberler> the good news seems to be there is no part actually relying on the harmonic property, at least I cant tell
[15:59:58] <mhaberler> aim high, fail low, keep running ;)
[16:00:25] <pcw_home> :-)
[16:00:35] <pcw_home> bbl walk the dog
[16:00:41] <mhaberler> cu
[16:01:35] <mhaberler> skunkworks - in case you do an RTAI boot, please pastebin a dmesg too -just for comparison. thanks!
[16:02:11] <skunkworks> Could I do the livecd? or Do I need to install?
[16:03:00] <mhaberler> actually I think you could, I would assume its an RTAI kernel booted off the CD
[16:03:45] <skunkworks> (I don't remember if I installed on an actual hd last time..
[16:04:32] <mhaberler> in case you have the xenomai kernel still running, please also pastebin output of cat /proc/interrupts and cat /proc/irq
[16:05:03] <mhaberler> and cat /proc/xenomai/irq
[16:08:09] -!- Poincare has quit [Quit: changing servers]
[16:09:09] -!- wildbilldonovan has quit [Ping timeout: 252 seconds]
[16:13:52] -!- hm2-buildmaster_ [hm2-buildmaster_!~hm2-build@174-29-164-43.hlrn.qwest.net] has joined #linuxcnc-devel
[16:14:04] -!- linuxcnc-build_ [linuxcnc-build_!~linuxcnc-@174-29-164-43.hlrn.qwest.net] has joined #linuxcnc-devel
[16:15:12] -!- linuxcnc-build has quit [Ping timeout: 240 seconds]
[16:15:16] -!- seb_kuzm1nsky [seb_kuzm1nsky!~seb@174-29-164-43.hlrn.qwest.net] has joined #linuxcnc-devel
[16:15:32] -!- seb_kuzminsky has quit [Ping timeout: 248 seconds]
[16:15:42] -!- hm2-buildmaster has quit [Ping timeout: 240 seconds]
[16:20:26] -!- chopper79 has quit [Quit: Leaving.]
[16:21:20] -!- arvind_khadri has quit [Ping timeout: 255 seconds]
[16:21:36] <skunkworks> mhaberler,
http://imagebin.org/244674
[16:21:49] <skunkworks> http://pastebin.ca/2308620
[16:22:47] <mhaberler> well the RTAI kernel oopses just the same during boot
[16:22:55] <mhaberler> line 613
[16:23:17] <skunkworks> heh
[16:24:04] <mhaberler> somebody on the xeno list had a similar problem
[16:24:29] -!- karavanjoW has quit [Quit: KVIrc 4.0.4 Insomnia http://www.kvirc.net/]
[16:26:20] -!- Thetawaves_ has quit [Quit: This computer has gone to sleep]
[16:26:31] <skunkworks> mhaberler, I didn't see your previous posts - I can reboot if you would like.
[16:26:50] <mhaberler> are you familar with grub - like adding an 'irqpoll' option?
[16:27:02] <skunkworks> I think so
[16:27:48] <mhaberler> give that a try; not sure it makes much of a difference but running with a boot oops is frowned upon;)
[16:29:42] -!- zzolo has quit [Quit: zzolo]
[16:32:59] <mhaberler> skunkworks: does this machine have any PCIe cards?
[16:33:23] -!- wildbilldonovan has quit [Read error: Connection reset by peer]
[16:34:48] <mhaberler> actually.. which cards are in there? please also pastebin an 'lspci -vvv' output
[16:35:23] <skunkworks> I have a pcie video card in it. that is it
[16:35:55] <mhaberler> what does /proc/interrupts say, that should identify the source
[16:37:45] <skunkworks> so - I should put irqpoll after quiet splash?
[16:38:15] <skunkworks> (in 'e' grub)
[16:38:24] <mhaberler> right, and delete quiet and make it 'nosplash' while you are at it, this is the 'dumbing down' options
[16:40:53] <mhaberler> was that pcie video card stock with the board, or extra? which make?
[16:41:25] <mhaberler> it looks this 'irq 16: nobody cared' issue is related to random freezing so it is a possible explanation for lousy performance
[16:41:55] <mhaberler> is there any chance you can swap that card for something different, like an old dumb VGA card?
[16:43:27] <skunkworks> gforce 8400gs
[16:43:59] <skunkworks> /proc/interrups errors
[16:44:05] <mhaberler> is that 'nvidia gforce 8400gs' ?
[16:44:46] <skunkworks> yes - made by asus
[16:45:03] <mhaberler> aha. here's the opinion on that:
http://www.techmansworld.com/2012/06/linus-torvalds-creator-of-linux-to.html
[16:45:21] <skunkworks> heh
[16:45:36] <mhaberler> what do you mean by '/proc/interrups errors' ?
[16:45:39] <mhaberler> try :
[16:45:39] <skunkworks> yes - I am sure I can find a pci card if I can get it to boot.
[16:45:45] <mhaberler> cat /proc/interrupts
[16:45:49] <skunkworks> duh
[16:45:51] <skunkworks> thanks
[16:45:53] <mhaberler> ah, excellent
[16:46:02] <mhaberler> I'm quite sure it's the card
[16:47:21] <skunkworks> http://pastebin.ca/2308627
[16:47:39] <mhaberler> bingo: 16: 859 IO-APIC-fasteoi nouveau
[16:47:44] <skunkworks> http://pastebin.ca/2308626
[16:47:50] <skunkworks> (dmesg)
[16:49:35] <skunkworks> Let me put a pci video card
[16:49:44] <mhaberler> ok, the oops is gone, unsure if that is a fix
[16:49:48] <mhaberler> yes, very good idea
[16:50:30] <mhaberler> I dont think there is much point in trying with the nvida hardware at all; might be a waste of time
[16:50:53] <mhaberler> I'd be very interested in latency with a non-nvidia card
[16:53:06] toudi_ is now known as micges
[16:53:47] -!- micges [micges!~toudi@egt68.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[16:55:49] -!- kmiyashiro has quit [Quit: kmiyashiro]
[17:01:47] -!- skorasaurus has quit [Quit: left the building.]
[17:08:46] <skunkworks> mhaberler, I could not find a pci card that would boot... It does have an onboard sis and so far the latency is staying under 12us with no overruns
[17:09:14] <skunkworks> I never tried it because I 'thought' I remember the onboard video caused issues.
[17:09:23] <skunkworks> (latency issues)
[17:09:53] <skunkworks> So no Nvidia
[17:11:40] -!- psha [psha!~psha@213.208.162.67] has joined #linuxcnc-devel
[17:11:48] -!- Brandonian has quit [Quit: Brandonian]
[17:17:34] -!- tjb1 has quit [Quit: tjb1]
[17:17:49] <skunkworks> well - was good until I took a screen shot...
[17:18:42] -!- dway has quit [Quit: dway]
[17:32:06] -!- chopper79 has quit [Quit: Leaving.]
[17:32:36] -!- psha has quit [Read error: No route to host]
[17:32:49] -!- psha [psha!~psha@213.208.162.67] has joined #linuxcnc-devel
[17:50:56] -!- Sendoushi has quit [Remote host closed the connection]
[17:55:00] <mhaberler> excellent!
[18:03:58] <skunkworks> mhaberler, last sentence..
[18:04:30] <skunkworks> I found a pci ati card that booted - same thing - latency looks good until I try to do a screen shot
[18:05:18] -!- mattions has quit [Ping timeout: 272 seconds]
[18:07:08] <mhaberler> I think you see now why I think a split between realtime hal/motion/rt os and the rest is overdue, or we'll be fighting this kind of nonsense
[18:07:27] <mhaberler> that's not a good answer to your problem, I right now have no better
[18:07:57] <mhaberler> nonsense forever.
[18:08:06] <mhaberler> dont know really what to suggest
[18:08:39] <mhaberler> it uses the nouveau graphics driver (at least with the nvidia card); maybe there's an alternate driver
[18:09:08] <mhaberler> any other cards in the drawer?
[18:09:48] <mhaberler> what driver gets loaded with the builtin card (line 16: in /proc/interrupts should tell)?
[18:13:19] -!- ravenlock has quit [Quit: Leaving]
[18:14:08] <pcw_home> How bad is the latency with screen operations?
[18:14:46] <skunkworks> let me look
[18:15:12] <skunkworks> mhaberler,
http://pastebin.ca/2308656
[18:16:16] <mhaberler> oh, of course not 16, because that card is off (you removed it, did you?)
[18:17:19] <mhaberler> interesting, the builtin card seems not to use an IRQ?
[18:17:23] <skunkworks> that is the onboard sis card
[18:17:37] <mhaberler> can you post the boot dmesg?
[18:18:07] <skunkworks> pcw_home,
http://imagebin.org/244690
[18:18:16] <skunkworks> the servo thread seems fine for some reason
[18:18:27] <skunkworks> mhaberler, just a second
[18:18:51] <pcw_home> That is quite strange
[18:19:41] <mhaberler> remember: the kernel config wrt xenomai timers is still likely not correct, so it is too early for conclusions
[18:20:42] <mhaberler> it makes zero sense to me - no spike on servo
[18:20:49] -!- sumpfralle has quit [Read error: Connection reset by peer]
[18:21:40] <mhaberler> but that timer thing is at the core of the issue - whether timers are aperiodic or periodic; I'm just building a kernel with that option changed
[18:22:06] <skunkworks> http://pastebin.ca/2308661
[18:22:06] <mhaberler> even the raspberry does better
[18:25:04] <mhaberler> ah, vesafb
[18:28:37] <mhaberler> you sure have read the video section here:
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Hardware_Requirements
[18:28:49] <mhaberler> it might be worth chasing yet another card
[18:30:33] <skunkworks> heh
[18:30:54] <mhaberler> I really wish we wouldnt have this stupid permanent uphill fight against manufacturer X hiccups and no way to change the setup so the whole issue becomes moot to start with - I do remember the original NIST design was fully distributed, and that has been successfully dumbed down to a single cpu option. Aaaaaargh.
[18:32:05] <mhaberler> fact is, even a decent remote X server is already an improvement for such issues
[18:33:29] <mhaberler> it might also be worth researching if a given graphics card has more than one driver option
[18:33:58] <mhaberler> what was the max base thread latency before the screen shot? 12 or so?
[18:34:21] <skunkworks> yes
[18:37:56] -!- riz_ [riz_!62dd7d6e@gateway/web/freenode/ip.98.221.125.110] has joined #linuxcnc-devel
[18:38:01] <mhaberler> this card obviously uses a main memory frame buffer for cost reasons:
[18:38:09] <mhaberler> vesafb: framebuffer at 0xd8000000, mapped to 0xf8580000, using 5120k, total 5120k
[18:38:20] <mhaberler> -----------------------------------------^^^^^^^^^^^^^^^^^^^
[18:38:45] <mhaberler> wild guess: screenshot starves main memory bus
[18:39:42] -!- vladimirek has quit [Read error: Operation timed out]
[18:39:51] <mhaberler> I think there are two different things at work here:
[18:40:32] <mhaberler> 1) likely the time kconfig thing, but I dont think thats relevant for the screenshot spike, rather for the wide distribution on base thread
[18:40:53] -!- psha has quit [Quit: Lost terminal]
[18:40:53] <mhaberler> 2) the graphics card - that still is an issue, just another one
[18:42:00] <mhaberler> I bet if you run the thing over remote X (to another computer setting DISPLAY=ip address:0.0) you can screenshot all day long and not see a hitch
[18:42:41] <mhaberler> can you pastebin the output of: lspci -vvv ?
[18:43:14] <mhaberler> cant find the onboard vga chipset id in dmesg
[18:43:57] <skunkworks> mhaberler, I did find an ati pci video card that booted.. IT did the same thing when screen shooting
[18:44:02] <skunkworks> old
[18:44:33] <mhaberler> hm, then memory access isnt a likely explanation
[18:45:03] <skunkworks> right
[18:45:47] <mhaberler> nah, reading 5megs cant last 60usec anyway
[18:46:03] <mhaberler> maybe on a 260/165
[18:46:08] <mhaberler> 360/165
[18:46:49] <mhaberler> can you do a snapshot of /proc/interrupts before and just after the screenshot?
[18:51:49] -!- kwallace1 has quit [Read error: Connection reset by peer]
[18:52:31] <mhaberler> any link to the motherboard spec/tech reference?
[18:53:34] <skunkworks> give me a few
[18:54:05] <riz_> I'm trying to understand what Dynamically_Allocated_NML_Objects is. It looks like a linked list that stores emcCommandBuffer, emcStatusBuffer, and emcErrorBuffer. Even within those buffers I see a linked list called format_chain. Is format_chain the main buffer?
[18:56:03] <mhaberler> I can just give you the short path to the mental model
[18:56:42] <mhaberler> it is a named shared memory space, and the 'M' is nonsense - there is no message queue, it is overwritten on each write
[18:57:06] <jepler> Dynamically_Allocated_NML_Objects looks like some uninteresting implementation detail
[18:57:12] <mhaberler> format_chain is likely the list of ops to serialize
[18:57:18] <jepler> I've never had to concern myself with it; never heard of it before just now
[18:59:46] <riz_> emcCommandBuffer basically is a linked list that stores the commands from the user interface to the task controller. Are the commands just stored in a linked list? Is that an example of format_chain being the list of ops to serialize or is that something else
[19:00:06] <riz_> *Is
[19:01:15] <riz_> just trying to understand how the NML messages are stored in these buffers (emcCommandbuffer, emcStatusbuffer etc.)
[19:02:31] <mhaberler> I do not think this is actually a list
[19:04:21] <mhaberler> see the discussion MDI and queueing a while ago, dev list
[19:05:05] <mhaberler> except for error messages, and the interplist there is no queuing from NML used
[19:06:19] <riz_> are you referring to this one:
http://psha.org.ru/irc/%23emc-devel/2012-05-02.html
[19:08:24] <mhaberler> no, on the emc-developers mailing list
[19:08:45] <mhaberler> I had fixed a bug and folks got antsy as they relied on the bug ;)
[19:08:51] -!- kwallace [kwallace!~kwallace@smb-12.sonnet.com] has joined #linuxcnc-devel
[19:09:12] <mhaberler> let me see
[19:10:00] <mhaberler> look around this one:
http://sourceforge.net/mailarchive/forum.php?thread_name=2491FA3C-9C40-4854-82B4-9D8F12986144%40mah.priv.at&forum_name=emc-developers
[19:10:31] <mhaberler> note: extra queue in task - which means: there was no such thing before that
[19:10:45] <riz_> oh so there is no queing used at all aside from error mesages and interplist?
[19:10:54] <mhaberler> it took me a long time to get that, yes
[19:11:23] <mhaberler> the whole NML thing as used except for those 2 use cases is basically just access draped around a shared memory buffer
[19:12:20] <mhaberler> it is quite a misnomer, there is no such thing as messages in 99% of NML use, its shared memory (with a bit of pretty much unused TCP access)
[19:13:14] <riz_> Why has NML not been scrapped? haha
[19:13:27] <mhaberler> this is a very good question.
[19:13:29] <riz_> This is baffling me because I see no use for it
[19:13:45] <riz_> It just makes everything convoluted
[19:13:46] <mhaberler> its not only useless, its counterproductive
[19:13:57] <jepler> because it's the API on which all the user interfaces are built and it's quite low-maintainance
[19:14:04] <jepler> inertia is easy
[19:14:23] <riz_> I'm on a new mission to rip it out
[19:14:31] <mhaberler> and from there goes a direct path to the single CPU restriction which we're just fighting here
[19:14:41] <jepler> do you plan to throw out all the user interfaces, or just rewrite them all from scratch?
[19:14:55] <mhaberler> look - planning please
[19:14:59] <riz_> Rewrite a simple UI
[19:15:18] <mhaberler> this is _exactly_ why I am suggesting using zeromq
[19:15:23] <jepler> anything that involves junking all the existing user interfaces is pretty much a fork
[19:15:29] <jepler> so knock yourself out
[19:15:46] <mhaberler> not if it is done with a bit of a plan
[19:16:23] <mhaberler> for instance, step 1: take out HAL shm requirement out of UI's by using messaging.
[19:16:33] <mhaberler> limited, and doable, breaks nothing else.
[19:17:12] <jepler> there's no requirement for a UI to be a HAL component.
[19:17:48] <mhaberler> if you take it out, where does that leave the current crop?
[19:18:23] <mhaberler> the point is: it is _useful_ its a HAL comp, it just shouldnt be shm, that isnt the same and doesnt follow
[19:18:27] -!- IchGuckLive has quit [Quit: ChatZilla 0.9.87 [Firefox 18.0/20130108033621]]
[19:18:27] <jepler> I didn't say it's not useful for UIs to be HAL components; many improve their usefulness by being HAL components.
[19:18:37] <mhaberler> right, very much so
[19:19:19] <jepler> you said "requirement". I'm still stuck back at it being false that it's a "requirement" that a UI uses HAL shared memory.
[19:19:27] <jepler> I am obviously missing your point.
[19:19:37] <mhaberler> I used the wrog term then, sorry
[19:19:54] <mhaberler> oh, HAL shm requirement?
[19:20:13] <riz_> So, what is the deal with the shared memory in the UI? I am missing the point. Will using shared memory slow something down? Why do you want to move towards messaging?
[19:20:27] <mhaberler> well currently all HAL comps require shm, i.e a single cpu (disregarding halrmt which dont count)
[19:20:54] <mhaberler> its the 'HAL shm' requirement, not the 'GUI HAL' requirement, sorry
[19:21:12] <mhaberler> riz: read up 100 lines, and think where these problems are coming from
[19:21:30] <jepler> riz_: mhaberler is talking about HAL, and you're talking about NML
[19:21:44] <jepler> .. I think
[19:21:57] <jepler> I'm so confused and I don't have a viewpoint to push here so I'm going to try to bow out of the discussion at this point.
[19:22:00] <jepler> wish me luck.
[19:22:10] <mhaberler> ;)
[19:22:26] <mhaberler> I though about the usefulness of middleware, and theres no good reason to have HAL and NML
[19:22:42] <riz_> I concur
[19:22:45] <mhaberler> both, that is
[19:22:54] -!- chopper79 has quit [Quit: Leaving.]
[19:23:01] <mhaberler> thats where my hal argument came from
[19:23:10] <mhaberler> I was jumping ahead though
[19:23:43] <mhaberler> in fact there is almost nothing in NML which cannot be mapped onto HAL except for two things:
[19:23:50] <zultron> skunkworks, you're basically running now, except for the latency spike when doing a screen capture?
[19:24:09] <mhaberler> compount structures (records if you will), and remote operations
[19:24:25] <jepler> nobody cares about operating nml over a socket
[19:24:32] <skunkworks> zultron, I switched to hardware that the nic works - and yes - everything seemed to build.
[19:24:45] <zultron> Ok, good start!
[19:24:52] <mhaberler> I am of 180 degrees opposite opinion
[19:25:09] -!- syyl_ws has quit [Quit: Verlassend]
[19:25:09] <mhaberler> not NML over socket - right
[19:25:10] <zultron> Are you hating being the guinea pig, or would you like to test one more kernel, skunkworks ?
[19:25:10] <jepler> I mean that in the sense that at present I'm aware of nobody who is operating nml over socket
[19:25:17] <mhaberler> oh sure
[19:25:19] <mhaberler> agreed
[19:25:49] <jepler> I know there are people who are interested in using networks somehow with linuxcnc, and they write things like emcrsh because writing thousands of lines of code is apparently less trouble than fixing nml-over-network if it's broken and merely configuring it if it's not
[19:26:07] <skunkworks> zultron, I can't program - so I test...
[19:26:09] <mhaberler> I suffer with you on that.
[19:26:18] <mhaberler> emcrsh, halrsh, the whole gunk, yes.
[19:26:32] <mhaberler> my idea is like so:
[19:26:39] <zultron> :) Ok, do an apt-get update, and apt-get install linux-image-3.5.7.2-xenomai-2.6.2.1-ubuntu
[19:26:49] <zultron> skunkworks, ^^
[19:27:02] <skunkworks> will do
[19:27:12] -!- zlog has quit [Ping timeout: 240 seconds]
[19:27:24] <riz_> So for example. emcCommandBuffer doesnt use a queue, but does it still hold multiple commands in a structure of some sort or is it just a single command?
[19:27:36] <zultron> That's the Xenomai kernel, as before, but with the Ubuntu changes smashed on top.
[19:27:38] <mhaberler> the boat anchor is NML, and HAL is the stronger part - late binding, all that. extend hal to take care of structs, and plug a decent messaging layer ontop. then migrate NML using comps to hal structs (eg replace emcstatus)
[19:27:55] <jepler> my interest is preserving source-level compatiblity for ~135k lines of user interface code (git grep . emc/usr_intf/ | wc -l) and 42k lines of hal components (git grep . hal/components/ hal/drivers/ | wc -l)
[19:27:59] <mhaberler> and _that_ can be done peacemeal
[19:28:04] <jepler> unless there's one big bloody payoff for it all
[19:28:13] <mhaberler> oh absolutely, a big bang is suicide
[19:28:41] <jepler> plus an unknown number of lines of HAL components and NML programs not maintained in the linuxcnc git
[19:28:43] <mhaberler> well not suicide, its just that a ton of affected parts move at the same time
[19:29:05] <mhaberler> well the supported branches dont go away anyway
[19:30:18] <mhaberler> I really see two stumbling blocks: 1) with current code being GPL2 you dont get in the packages you want, only those which leave a lot of work. 2) tcl interfaces - I have no idea who should maintain those, so a decision needs to be made to deprecate them
[19:31:10] <riz_> Just to reiterate in the sea of discussion - So for example. emcCommandBuffer doesnt use a queue, but does it still hold multiple commands in a structure of some sort or is it just a single command?
[19:31:31] -!- andypugh [andypugh!3eed20e2@gateway/web/freenode/ip.62.237.32.226] has joined #linuxcnc-devel
[19:31:52] -!- vladimirek [vladimirek!~vladimire@95.105.250.72] has joined #linuxcnc-devel
[19:32:00] <andypugh> Logging in from a hotel, I might have broken something in master
[19:32:01] <mhaberler> no, senders must track serial numbers and read status before they write
[19:32:01] <skunkworks> zultron, will this be the default boot kernel - or will I need to pick it from grub?
[19:32:54] <zultron> skunkworks, sorry, I don't know. Not a debian user. :)
[19:33:06] <zultron> Install it and check /boot/grub/grub.cfg?
[19:33:09] <mhaberler> skunkworks: yes it will
[19:33:13] <andypugh> a quick bit of coding might be needed, as it will take me a while to get my LinuxCNC dev machine running here in Finland.
[19:34:23] <mhaberler> andy - everything older than 37 hours
[19:35:05] <andypugh> seb_kuzm1nsky: Do you think you could make a couple of small changes by proxy? I think that the sserial_baudrate modparam in hostmot2.c wants to default to -1, and then check_set_baudrate in sserial.c needs to exit doing nothing in the case of a -1 value
[19:35:31] -!- AR__ has quit [Ping timeout: 276 seconds]
[19:36:06] <andypugh> The issue is that it appears that the smart-serial baudrate memory location might not always have been in the same place. So a bogus baudrate is read with old firmwares, then a bogus memory location is set to 250000.
[19:36:50] <cradek> andypugh: is this a 2.5 release issue?
[19:36:58] <andypugh> (Plan B would be to revert the last commit from me)
[19:37:12] <andypugh> cradek: No, only in Master.
[19:37:18] <cradek> thanks
[19:39:42] -!- ybon has quit [Ping timeout: 276 seconds]
[19:40:19] -!- sumpfralle1 has quit [Ping timeout: 272 seconds]
[19:41:27] <skunkworks> zultron, what am I testing - that the network card works on the other hardware?
[19:42:13] <skunkworks> (still screen shot latancy spike)
[19:42:28] <zultron> Yes. Check the network, sounds like you've checked video, and of course if Xenomai is working.
[19:42:32] -!- zlog has quit [Read error: Connection reset by peer]
[19:42:35] -!- Tom_itx has quit []
[19:43:27] <zultron> Can you paste output of uname -r, just to be double sure? ;)
[19:44:35] <andypugh> A proper fix needs to always find the correct sserial baudrate location, but the suggestion I made above will at least mean that things work as normal if users don't specify a baudrate, so normal installations carry on working.
[19:44:44] <pcw_home> andypugh: I dont know if you use them but channel-start and channel-stride per channel data structure pointer were only implemented (correctly) in V34
[19:45:23] <pcw_home> so that may be the issue
[19:45:27] <andypugh> pcw_home: Ah. Yes, channel-start is used, as there is no other way to find the baudrate location, as I understand it.
[19:45:49] <pcw_home> well they were private before
[19:46:40] <pcw_home> (before remote programming support was added to SSLBP firmware)
[19:47:24] <cradek> skunkworks: does the screen shot beep the speaker? (probably does if it uses xwd)
[19:48:20] <skunkworks> zultron,
http://pastebin.ca/2308687
[19:48:30] <skunkworks> cradek, I think it does...
[19:49:21] <skunkworks> (this has a sound card but iirc - it makes some sort of sound.. I could disable the sound card in the bios)
[19:50:10] <pcw_home> On one machine I had I got a real time error every time I backspaced too far (speaker beep problem)
[19:51:05] <kwallace> Isn't the issue the pc speaker module?
[19:51:31] <pcw_home> Yes it was on my old test machine
[19:51:55] <mhaberler> skunkworks: maybe screenshot beeps?
[19:52:10] <skunkworks> I think that is what cradek is getting at...
[19:52:49] <mhaberler> oh, reading does help
[19:52:57] <mhaberler> any output here: lsmod|grep pcspkr
[19:53:31] <mhaberler> oh man.. if it would be that…
[19:55:45] <cradek> I really don't understand all the layers of crap they've smeared on top of the pc speaker to redirect all the old calls to the sound card
[19:56:46] <mhaberler> skunkworks: if you run this command: is there any output? lsmod|grep pcspkr
[19:56:47] -!- mattions has quit [Ping timeout: 272 seconds]
[19:56:48] <zultron> Ah, is that the issue with the pc spkr? Seems so innoculous
[19:57:37] <skunkworks> Umm- would you believe that was the issue???? screen shot - latency <10us
[19:57:43] <skunkworks> disabled the sound card in the bios....
[19:57:51] <mhaberler> gimme a break, really?
[19:58:03] <skunkworks> cradek, you are the man!
[19:58:10] <cradek> PCs started going to hell when they got sound
[19:58:18] <mhaberler> beer! champaign! loose women!
[19:58:29] <cradek> and color
[19:58:33] <zultron> Woo hoo! Ok, I'll turn that thing off.
[19:59:30] <mhaberler> skunkworks: can ypu post a plot - because of the base thread latency? but I dont think that changed
[20:01:57] <zultron> BTW, skunkworks, that AMD system is 64-bit. You should be able to run 64-bit OS, should you ever decide to reinstall.
[20:02:18] <zultron> skunkworks, thanks a ton for all the testing! Very much appreciated.
[20:02:47] -!- riz_ has quit [Quit: Page closed]
[20:02:58] -!- phantoxeD has quit [Ping timeout: 256 seconds]
[20:04:05] <skunkworks> zultron, I wasn't sure - but next time I will.
[20:06:26] <skunkworks> mhaberler, is this what you wanted?
http://imagebin.org/244707
[20:06:33] <skunkworks> that was after quite a few print screens
[20:07:08] <mhaberler> that looks a lot better, in fact
[20:07:22] <mhaberler> we'll see, still twisting knobs
[20:07:52] <skunkworks> yes - let me throw this into the other machine (with the nic problem - and see what the latency does - now that everything is installed...)
[20:08:09] <skunkworks> then if there is latency issues - I will disable the sound card
[20:09:09] <zultron> Yeah, that looks great.
[20:09:31] <zultron> Ah, so you DO have a nic problem.
[20:10:53] -!- Wildhoney has quit [Ping timeout: 246 seconds]
[20:10:55] <skunkworks> zultron, I don't know - if the new kernel you built is supposed to fix it - I have not put the HD it in said machine yet
[20:11:08] <skunkworks> That is next
[20:11:43] <skunkworks> that latency is as good or better than rtai.
[20:12:06] <zultron> skunkworks, it didn't fix mhaberler's NIC, but I'd appreciate if you tested, too.
[20:12:24] <zultron> logger[mah], gimme some skin
[20:12:25] <logger[mah]> zultron: Log stored at
http://linuxcnc.mah.priv.at/irc/%23linuxcnc-devel/2013-01-29.html
[20:12:27] <mhaberler> I think we have the red hands on that one too
[20:15:15] <skunkworks> booting
[20:16:57] <andypugh> Curses! My VirtualPC can't see the network. So can't install Git, so can't try to fix the bug.
[20:18:57] <skunkworks> zultron, no network - bad latency right out of the box
[20:19:47] -!- Sendoushi has quit [Remote host closed the connection]
[20:20:27] <zultron> skunkworks, Ok, thanks for trying. That's the box with the r8169, right?
[20:20:44] <skunkworks> yes
[20:22:51] <zultron> Well, I'd ask for a pastebin of the oops, but that'll be a little hard with no network.
[20:23:59] <zultron> skunkworks, can you dmesg | grep MSI/MSI-X?
[20:24:15] <zultron> Maybe we're looking for no output, or something about an irq.
[20:28:48] <andypugh> Any idea how I might create and submit a patch to the repository with the following hardware. A motherboard with a full LinuxCNC dev system but no keyboard or display, a laptop, an HDMI lead. A hotel room network connection.
[20:29:06] -!- chopper79 has quit [Quit: Leaving.]
[20:29:47] <andypugh> The TV in the room relies on Cathode Rays and Phosphorescent salts, so isn't going to have HDMI input ;-)
[20:30:22] <micges> andypugh: rpi?
[20:31:27] <andypugh> No, it's an Atom D2800, VGA and HDMI
[20:31:51] <andypugh> I might be able to ssh into it via my iPhone...
[20:32:15] -!- vladimirek has quit [Ping timeout: 272 seconds]
[20:32:23] <andypugh> I guess I might have to buy a monitor if I can't find a proxy-coder
[20:34:01] <zultron> Set up dhcp on your laptop, use hotel room net connection ether cable to connect directly, ssh
[20:34:10] <zultron> dhcpd, I mean
[20:35:12] <andypugh> no ssh on the laptop (Win7, work machine)
[20:35:35] <zultron> D'oh
[20:36:05] <zultron> Burn a knoppix CD, or whatever they use these days.
[20:36:20] <zultron> BIOS locked down too?
[20:37:03] -!- rob_h [rob_h!~rob_h@5e0860c9.bb.sky.com] has joined #linuxcnc-devel
[20:37:13] <andypugh> Thinking about it, I have a LinuxCNC boot-USB-stick.
[20:37:34] <andypugh> I might try booting from that
[20:38:03] <andypugh> But getting networking working with VirtualPC / Ubuntu probably ought to be the first thing to try.
[20:38:33] <pcw_home> andypugh I can update Ricks bitfile I dont think the subset of people using master and sserial revs <34 is terribly big
[20:38:58] <skunkworks> disabling nic and sound didn't help - latencies around 100us
[20:39:31] <andypugh> I guess they would be a strange subset of the bleeding-edge and stone-age
[20:40:20] -!- wboykinm has quit [Ping timeout: 252 seconds]
[20:40:46] <pcw_home> Yeah I think it can wait a bit
[20:44:24] <skunkworks> It is actually really consistant at 100us
[20:44:31] <skunkworks> wonder what that means..
[20:45:27] <skunkworks> iirc - rtai was 40us-ish... so whatever. Probably not hardware that will work - atleast for software stepgen
[20:48:14] <zultron> skunkworks, I'm sorry I'm losing track. What CPU and chipset is this?
[20:48:28] tjb1_ is now known as tjb1
[20:49:24] <skunkworks> asus f1 a75-m pro r2.0 motherboard with the amd a4 3400 processor
[20:50:28] <skunkworks> so - if I understand it right - the video is on the processor
[20:50:42] <skunkworks> (but I did install a pci video card with no improvement..)
[20:55:38] <skunkworks> can't use putty?
[20:55:48] <skunkworks> andypugh, can't use putty?
[20:57:59] <andypugh> I am not really meant to install anything.
[20:59:33] <skunkworks> oh
[21:00:37] <skunkworks> zultron,
http://pastebin.ca/2308712
[21:01:21] <skunkworks> zultron,
http://pastebin.ca/2308713
[21:01:48] <zultron> Oh, it's an APU.
[21:01:59] <zultron> putty isn't installed, it's just an executable, btw.
[21:02:12] <zultron> You could run it from your usb stick. :)
[21:03:00] <skunkworks> it seems to be maxing out at about 100us
[21:03:57] <skunkworks> zultron, I did install a pci video card.. No improvement
[21:05:16] <skunkworks> now - lagacy usb, sound and nic disabled in bios
[21:05:37] <zultron> Still with 100us latency, right?
[21:05:44] <skunkworks> yes
[21:05:49] <andypugh> Aha! progress. Networking enabled on the VPC, git installing now
[21:08:31] <zultron> Hmm, sorry skunkworks, nothing's ringing a bell. mhaberler seems to be more creative and tenacious with these problems.
[21:09:15] <zultron> skunkworks, Did you try the same system with RTAI? I think you said 40us?
[21:20:32] <andypugh> when git clone asks for a password, what password should I use?
[21:21:01] -!- vladimirek [vladimirek!~vladimire@95.105.250.72] has joined #linuxcnc-devel
[21:22:12] <andypugh> Or is it not necessary to use the ssh version of git clone on one of the wiki pages?
[21:22:27] <jepler> you can clone with git://
[21:22:43] <jepler> you have to arrange ssh key-based authentication before you can push
[21:22:55] <jepler> (or you can just put up a patch with git format-patch and somebody else can push it for you)
[21:23:28] <andypugh> Well, I do ordinarily have push-access.
[21:23:50] <jepler> on a new machine you need to generate a new ssh keypair and send the public portion to cradek
[21:23:57] <andypugh> Ah, OK.
[21:24:40] <andypugh> I do have the old machine sat in my suitcase. But with no monitor.
[21:25:08] <andypugh> I _might_ be able to VNC into it, it does run headless most of the time.
[21:26:37] <andypugh> Anyway, I have some avenues to progress, and it is time to sleep here.
[21:27:32] -!- andypugh has quit [Quit: Page closed]
[21:34:03] -!- motioncontrol has quit [Quit: Sto andando via]
[21:37:24] -!- Sendoushi has quit [Remote host closed the connection]
[21:41:45] -!- micges has quit [Quit: Leaving]
[21:50:12] -!- micges [micges!~micges@egt68.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[22:00:52] <skunkworks> zultron, yes - around 40us - so not stellar
[22:02:15] -!- sumpfralle has quit [Ping timeout: 252 seconds]
[22:03:47] -!- joru has quit [Read error: Connection reset by peer]
[22:03:58] -!- DJ9DJ has quit [Quit: bye]
[22:05:41] -!- odogono has quit [Ping timeout: 252 seconds]
[22:07:11] -!- FinboySlick has quit [Quit: Leaving.]
[22:07:36] -!- syyl_ has quit [Quit: Leaving]
[22:11:15] -!- i_tarzan has quit [Ping timeout: 244 seconds]
[22:19:34] <skunkworks> zultron, mhaberler, This xnomi kernel is quite a bit better than the one I started testing on.... I just threw it into another machine - the previous kernel was above 30us and this one is under 15us
[22:19:50] <skunkworks> bbl
[22:19:54] <zultron> Great!
[22:20:13] <zultron> skunkworks, which kernel did you start testing on, for reference?
[22:20:28] <skunkworks> I think it was the one mhaberler built
[22:20:39] <skunkworks> originally - it was on the wiki
[22:21:14] <skunkworks> here
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?NewRTInstall
[22:21:47] <skunkworks> So far though - the amd apu systems don't play well
[22:22:46] -!- skunkworks has quit [Read error: Connection reset by peer]
[22:23:39] -!- sumpfralle has quit [Ping timeout: 244 seconds]
[22:45:17] -!- L33TG33KG34R has quit [Ping timeout: 252 seconds]
[23:00:59] -!- wildbilldonovan has quit [Remote host closed the connection]
[23:04:32] -!- vladimirek has quit [Remote host closed the connection]
[23:05:23] -!- skunkworks [skunkworks!~chatzilla@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[23:07:30] -!- plushy has quit [Read error: Operation timed out]
[23:12:23] -!- chopper79 has quit [Quit: Leaving.]
[23:13:32] -!- ravenlock has quit [Remote host closed the connection]
[23:13:40] -!- Wildhoney has quit [Ping timeout: 248 seconds]
[23:26:09] -!- servos4ever has quit [Quit: ChatZilla 0.9.85 [SeaMonkey 2.0.11/20101206162726]]
[23:28:25] -!- L33TG33KG34R has quit [Ping timeout: 264 seconds]
[23:30:43] -!- rob__H [rob__H!rob_h@2002:1f06:12ac::1f06:12ac] has joined #linuxcnc-devel
[23:34:08] -!- rob_h has quit [Ping timeout: 255 seconds]
[23:38:16] -!- mephux has quit [Excess Flood]
[23:40:47] -!- racycle has quit [Quit: racycle]
[23:55:42] -!- XiXora has quit [Ping timeout: 240 seconds]
[23:56:30] -!- ybon has quit [Quit: WeeChat 0.3.8]