Back
[00:13:24] -!- rob_h has quit [Ping timeout: 264 seconds]
[00:15:23] -!- gambakufu has quit [Ping timeout: 252 seconds]
[00:24:25] -!- Nick001-Shop has quit [Remote host closed the connection]
[00:24:36] -!- L33TG33KG34R has quit [Ping timeout: 252 seconds]
[00:28:14] -!- mhaberler has quit [Quit: mhaberler]
[00:34:28] -!- lsu has quit [Quit: Ex-Chat]
[00:36:26] -!- Sendoushi has quit [Remote host closed the connection]
[00:41:36] -!- asdfasd has quit [Ping timeout: 264 seconds]
[00:53:31] -!- servos4ever has quit [Quit: ChatZilla 0.9.85 [SeaMonkey 2.0.11/20101206162726]]
[00:55:44] -!- Keknom has quit [Quit: Leaving.]
[01:14:53] -!- toudi_ has quit [Quit: Wychodzi]
[01:17:56] -!- maximilian_h [maximilian_h!~bonsai@f052030012.adsl.alicedsl.de] has joined #linuxcnc-devel
[01:18:12] -!- maximilian_h has quit [Client Quit]
[01:22:15] -!- r00t4rd3d has quit [Quit: Leaving]
[01:35:34] -!- plushy has quit [Quit: Leaving.]
[01:49:34] -!- Valen has quit [Quit: Leaving.]
[01:51:29] -!- joe9 [joe9!~joe9@c-24-98-97-215.hsd1.ga.comcast.net] has joined #linuxcnc-devel
[01:57:43] -!- gmag has quit [Quit: Enough small talk...]
[02:07:40] -!- Wildhoney has quit []
[02:12:32] -!- adb has quit [Ping timeout: 252 seconds]
[02:16:11] -!- ve7it has quit [Remote host closed the connection]
[03:31:00] -!- tandoori has quit [Ping timeout: 248 seconds]
[03:37:24] -!- sumpfralle has quit [Ping timeout: 264 seconds]
[04:02:55] -!- Keknom has quit [Quit: Leaving.]
[04:11:35] -!- FinboySlick has quit [Remote host closed the connection]
[04:21:48] -!- Valen has quit [Quit: Leaving.]
[04:44:50] toastyde2th is now known as toastydeath
[04:45:43] -!- Dupe has quit [Quit: Leaving]
[04:59:14] -!- dgarr has quit [Quit: Leaving.]
[05:00:04] -!- tjb1 has quit [Remote host closed the connection]
[05:00:22] -!- tayy has quit [Remote host closed the connection]
[05:03:28] -!- joe9 has quit [Quit: leaving]
[06:02:10] -!- Fox_Muldr has quit [Ping timeout: 260 seconds]
[06:39:56] -!- zzolo has quit [Quit: zzolo]
[06:41:23] -!- mhaberler [mhaberler!~mhaberler@extern-187.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[06:58:36] -!- zzolo has quit [Quit: zzolo]
[06:59:39] -!- kwallace [kwallace!~kwallace@tmb-209.sonnet.com] has parted #linuxcnc-devel
[07:14:54] -!- pingufan has quit [Read error: Operation timed out]
[07:20:02] <KGB-linuxcnc> 03seb 05v2.5_branch f9ea0d6 06emc2 10tests/t0/ 10(21 files in 5 dirs) * add tests for t0 handling
[07:20:02] <KGB-linuxcnc> 03seb 05v2.5_branch 9814b2d 06emc2 10src/emc/rs274ngc/interp_convert.cc * fix a t0 bug in Interp::convert_setup_tool
[07:20:04] <KGB-linuxcnc> 03seb 05v2.5_branch 873b4b3 06emc2 10docs/src/gcode/gcode.txt * docs: note that G10 cannot set TLO for tool 0
[07:20:12] <KGB-linuxcnc> 03seb 05v2.5_branch 751d31b 06emc2 10docs/src/gcode/other-code.txt * docs: update T-word documentation to match reality
[07:20:19] <KGB-linuxcnc> 03seb 05v2.5_branch e39cd7f 06emc2 10docs/src/gcode/tool_compensation.txt * docs: add an anchor for the Tool Changers section
[07:20:26] <KGB-linuxcnc> 03seb 05v2.5_branch 478c7b7 06emc2 10docs/src/gcode/gcode.txt * docs: clean up the G43 section a bit
[07:20:32] <KGB-linuxcnc> 03seb 05v2.5_branch 08b4812 06emc2 10docs/src/gcode/gcode.txt * docs: note funny behavior of G41/G42 D0
[07:33:03] -!- pingufan has quit [Quit: Konversation terminated!]
[07:43:39] <KGB-linuxcnc> 03chrisinnanaimo 05v2.5_branch 94e681c 06emc2 10src/emc/usr_intf/pncconf/pncconf.py * pncconf -fix a missing signal in openloop test.
[07:51:10] -!- psha[work] [psha[work]!~psha@195.135.238.205] has joined #linuxcnc-devel
[08:27:20] -!- vladimirek [vladimirek!~vladimire@95.105.250.72] has joined #linuxcnc-devel
[08:38:03] -!- tjb1 has quit [Quit: tjb1]
[08:50:22] -!- rob_h [rob_h!~rob_h@5e0860c9.bb.sky.com] has joined #linuxcnc-devel
[08:57:28] -!- racycle has quit [Quit: racycle]
[09:03:33] -!- mhaberler has quit [Quit: mhaberler]
[09:06:04] -!- mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[09:08:37] -!- Dupe has quit [Read error: Connection reset by peer]
[09:23:55] -!- Adventsparky has quit [Quit: KVIrc 4.1.3 Equilibrium http://www.kvirc.net/]
[09:24:14] -!- Loetmichel has quit [Ping timeout: 256 seconds]
[09:27:02] Cylly is now known as Loetmichel
[10:06:28] -!- emel has quit [Excess Flood]
[10:13:54] -!- pikeaero has quit [Read error: Connection reset by peer]
[10:48:05] -!- plushy has quit [Quit: Leaving.]
[10:55:11] -!- L84Supper has quit [Quit: <puff of smoke>]
[10:58:42] -!- L84Supper [L84Supper!~Larch@unaffiliated/l84supper] has joined #linuxcnc-devel
[11:08:26] -!- micges [micges!~micges@adcs173.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[11:46:35] -!- Sendoushi has quit [Remote host closed the connection]
[11:47:51] -!- dhoovie has quit [Read error: Connection reset by peer]
[11:54:02] -!- sumpfralle has quit [Ping timeout: 256 seconds]
[12:22:36] -!- tjb1 has quit [Client Quit]
[12:25:29] -!- pikeaero has quit [Remote host closed the connection]
[12:49:56] -!- skunkworks has quit [Remote host closed the connection]
[12:53:46] -!- peroht has quit [Remote host closed the connection]
[12:55:15] -!- plushy has quit [Quit: Leaving.]
[13:02:00] -!- odogono has quit [Read error: Connection reset by peer]
[13:15:19] -!- James628 has quit [Quit: Page closed]
[13:15:39] <cradek> seb_kuzminsky: yay!
[13:16:17] -!- dgarr [dgarr!~dgarrett@75-171-116-61.phnx.qwest.net] has joined #linuxcnc-devel
[13:27:47] -!- ravenlock has quit [Ping timeout: 246 seconds]
[13:30:02] -!- Santolina has quit [Ping timeout: 245 seconds]
[13:32:42] -!- psha[work] has quit [Quit: Lost terminal]
[13:36:58] -!- skunkworks [skunkworks!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[13:50:22] -!- plushy has quit [Quit: Leaving.]
[13:56:50] -!- mattions has quit [Ping timeout: 246 seconds]
[14:02:36] -!- rwam has quit [Quit: Leaving.]
[14:21:33] -!- holgi_ has quit [Quit: ChatZilla 0.9.90 [Firefox 18.0.2/20130201233328]]
[14:21:51] -!- mk0 has quit [Quit: Leaving]
[14:22:07] -!- Pitu has quit [Ping timeout: 245 seconds]
[15:01:28] <seb_kuzminsky> cradek: it's only a little yay, i still have the toolno/pocketno bug to push :-/
[15:07:05] -!- Poincare has quit [Ping timeout: 276 seconds]
[15:07:06] -!- cherry_lin has quit [Ping timeout: 276 seconds]
[15:07:06] -!- zlog has quit [Ping timeout: 276 seconds]
[15:07:07] -!- toastydeath has quit [Ping timeout: 276 seconds]
[15:07:07] -!- jst_ has quit [Ping timeout: 276 seconds]
[15:07:07] -!- archivist_herron has quit [Ping timeout: 276 seconds]
[15:11:50] <KGB-linuxcnc> 03TODO: deletor 05t0-test cae2f58 06emc2 04. * branch deleted
[15:12:44] _Poincare is now known as Poincare
[15:16:20] <mhaberler> pcw_home: around?
[15:28:33] -!- psha [psha!~psha@213.208.162.67] has joined #linuxcnc-devel
[15:29:23] -!- plushy has quit [Quit: Leaving.]
[15:36:56] <mhaberler> opinions on license compatibiliy?:
http://www.portaudio.com/license.html - since it's MIT style, I'd consider it compatible with current and maybe future GPL2+ licensing
[15:43:37] <cradek> http://www.gnu.org/licenses/license-list.html#Expat
[15:44:31] <cradek> I agree it looks like it's compatible
[15:50:08] <mhaberler> thanks
[15:50:48] -!- kwallace [kwallace!~kwallace@smb-23.sonnet.com] has joined #linuxcnc-devel
[15:55:26] -!- ybon has quit [Quit: WeeChat 0.3.8]
[16:00:02] -!- kwallace has quit [Ping timeout: 256 seconds]
[16:06:02] -!- tandoori has quit [Changing host]
[16:12:01] -!- zzolo has quit [Quit: zzolo]
[16:14:44] -!- kwallace [kwallace!~kwallace@smb-30.sonnet.com] has joined #linuxcnc-devel
[16:15:22] <zultron> mhaberler, looks like it'll be kosher. Problem is before you can get it into a distro, the lawyers will have to check it out. :P
[16:15:56] <mhaberler> duh
[16:16:13] <zultron> Just an extra step. Should be ok.
[16:16:37] -!- norbert [norbert!~norbert@a89-182-164-78.net-htp.de] has joined #linuxcnc-devel
[16:17:00] -!- joe9 [joe9!~joe9@c-24-98-97-215.hsd1.ga.comcast.net] has joined #linuxcnc-devel
[16:20:20] -!- adb has quit [Ping timeout: 246 seconds]
[16:24:16] -!- vladimirek has quit [Remote host closed the connection]
[16:26:13] -!- vladimirek [vladimirek!~vladimire@95.105.250.72] has joined #linuxcnc-devel
[16:30:15] -!- phantoneD has quit [Ping timeout: 260 seconds]
[16:36:26] -!- mattswe has quit [Ping timeout: 246 seconds]
[16:37:50] -!- tanepiper has quit [Ping timeout: 246 seconds]
[16:38:11] -!- toastyde1th has quit [Ping timeout: 246 seconds]
[16:42:06] -!- tjb1 has quit [Read error: Connection reset by peer]
[16:43:23] <skunkworks> zultron, I don't know what to do with this computer - the test suite ran with peak latency of 39us. Not stellar - but then I ran the latency-test and instantly got 100+us
[16:45:32] <skunkworks> 130us
[16:48:46] <pcw_home> I wonder how this will do (though may need Ubuntu 12.10)
[16:48:48] <pcw_home> http://www.newegg.com/Product/Product.aspx?Item=N82E16813128585
[16:50:05] <cradek> yeah, probably the intel video that doesn't work in U10
[16:51:05] <skunkworks> pcw_home, that would give you one nic for your ethernet solution!
[16:51:16] <zultron> skunkworks, if you run latency-test, and then reset the stats after the first 100+ us, does it hit 100+ us again after that?
[16:51:32] <skunkworks> doing that now
[16:51:52] <cradek> I can't find anything about the video chipset
[16:52:00] <pcw_home> Yeah its an slow I3 so has Intel HD video
[16:52:15] <skunkworks> been running for 5+ minuts and the peak latency is 55us so far
[16:52:54] <zultron> Hmm, not too hot.
[16:53:01] <zultron> But not 100+ either.
[16:54:15] <zultron> skunkworks, So, you say you run the latency-test and 'instantly' get the 100+us. Would you say the pattern is 100+us only at the very beginning?
[16:54:30] <skunkworks> so far
[16:55:09] <pcw_home> even 100 is livable in a servo thread only machine if you busy wait until the clock is right
[16:55:52] <zultron> Ok. It'll be good if we can establish the pattern. mhaberler will take a look in a few minutes, and we can gather info for the xeno list, if needed.
[16:56:49] <pcw_home> Is this a AMD Hudson CPU?
[16:57:35] <zultron> I believe it's one of the 'Fusion' APUs with GPU on board.
[16:57:41] <zultron> Does that answer the q? :)
[16:58:08] <mhaberler> skunkworks: any link to the board spec?
[16:58:13] <zultron> Here's the dmesg:
http://pastebin.ca/2311945
[16:58:48] <zultron> http://www.asus.com/Motherboard/F1A75M_PRO/
[16:58:51] <zultron> Should be this one
[17:00:15] <skunkworks> yes - with a amd a4 3400 processor
[17:00:22] <mhaberler> yes, Hudson
[17:01:23] <zultron> pcw_home, Is there a reason you brought up the Hudson?
[17:06:34] <mhaberler> stab in the dark:
http://aptosid.com/index.php?name=PNphpBB2&file=viewtopic&t=2335
[17:06:52] <mhaberler> line 907 in dmesg
[17:08:58] <zultron> Ugh
[17:09:17] <pcw_home> Just that I have one
[17:10:13] <skunkworks> pcw_home, have you runany tests?
[17:10:20] <skunkworks> (latency)
[17:12:05] <pcw_home> around 30 usec (RTAI Ubuntu 10.04)
[17:13:04] <skunkworks> that is what I remember with rtai - not great but ok for servo systems
[17:15:53] <skunkworks> is there something that happens when the latency-test overruns that causes the latency to be worse? (writing to dmesg or such)
[17:18:21] <skunkworks> how would I add the amd64 micro code repo to try?
[17:19:01] <mhaberler> just looking that up
[17:19:16] <mhaberler> it seems there's a amd64-microcode deb
[17:20:05] <mhaberler> in debian for sure
[17:20:23] <mhaberler> can you try 'apt-cache search amd64-microcode' ?
[17:22:40] <mhaberler> it seems there's no such thing in precise, only raring and quetzal
[17:22:56] <skunkworks> I get nothing returned
[17:22:58] <mhaberler> maybe download and dpkg -i the quantal package
[17:23:30] <mhaberler> try… and dont shoot the piano player ;) wget
https://launchpad.net/ubuntu/+archive/primary/+files/amd64-microcode_1.20120910-1_amd64.deb
[17:24:06] <mhaberler> then 'dpkg -i amd64-microcode_1.20120910-1_amd64.deb'
[17:24:39] <mhaberler> on reboot, the line 907 in dmesg: [ 11.497779] microcode: failed to load file amd-ucode/microcode_amd.bin
[17:24:48] <mhaberler> should be gone (hopefully)
[17:25:10] <mhaberler> I have no idea if that changes anything, but usually that patches errata in the CPU design
[17:28:40] <skunkworks> well - I am running 32bit here?
[17:28:59] <skunkworks> so it errors. I could setup a 64 bit drive.
[17:29:07] <skunkworks> i386
[17:29:18] -!- vladimirek has quit [Remote host closed the connection]
[17:29:27] <skunkworks> or is there a 32 bit version of the bitcode?
[17:29:39] <mhaberler> yes
[17:30:21] <mhaberler> sorry. my bad - no
[17:31:27] <mhaberler> salto #2: yes there is:
https://launchpad.net/ubuntu/+source/amd64-microcode/1.20120910-2/+build/3935707/+files/amd64-microcode_1.20120910-2_i386.deb
[17:32:07] <mhaberler> please explain: this is an i386 install??
[17:32:44] <mhaberler> did you install the root this on this board?
[17:32:51] <mhaberler> root disk
[17:42:41] -!- ybon has quit [Ping timeout: 255 seconds]
[17:45:02] -!- dway has quit [Quit: NOOOOOOooooooooo……]
[17:47:55] <zultron> skunkworks, can you check that AMD PowerNow and any other suspicious BIOS settings are disabled?
[17:48:37] <zultron> Gotta run, time to start preparing for tax day with the accountant. :P
[17:48:40] -!- vladimirek [vladimirek!~vladimire@95.105.250.72] has joined #linuxcnc-devel
[17:50:17] -!- V0idExp has quit [Ping timeout: 252 seconds]
[17:51:48] -!- sumpfralle has quit [Ping timeout: 264 seconds]
[17:59:36] <skunkworks> yes - At the time I didn't know if the xenomi kernel worked on 64..
[18:00:50] -!- Holgi has quit [Disconnected by services]
[18:03:52] <mhaberler> aha
[18:05:20] <mhaberler> well I have no if this has any performance or functionality implications
[18:06:43] <mhaberler> maybe a x86_64 install? just to exclude the possibility
[18:07:15] <mhaberler> btw, did the i386 ucode deb install, and is the message gone now?
[18:07:47] <zultron> Should the i386 or the amd64 deb be installed in this case? :)
[18:09:16] <skunkworks> working on it :)
[18:09:21] -!- sumpfralle1 has quit [Ping timeout: 276 seconds]
[18:10:11] <mhaberler> well on amd64 install you'd want the amd64 deb I guess
[18:10:28] <mhaberler> if you have the box still running, please pastebing output of 'dmidecode -t 4'
[18:10:46] <zultron> That was my first thought. But will the i386 .deb include the microcode for amd64 CPUs?
[18:10:49] <mhaberler> this will retrieve the exact CPU ID - for checking errata
[18:11:46] <mhaberler> I dont think I'd want to play with mixed setups now
[18:11:55] <mhaberler> I would think so
[18:12:12] <zultron> We'll soon find out. :)
[18:12:19] <mhaberler> but I want to exclude any mixed architecture snafus
[18:12:35] <zultron> Right, good thinking. I like to over-complicate.
[18:12:59] <zultron> skunkworks: be sure to check the AMD PowerNow & other power options in the BIOS when you reboot.
[18:21:48] <skunkworks> http://pastebin.com/38XrxNBy
[18:21:56] <skunkworks> I disabled power now
[18:22:03] <skunkworks> could not see anything else
[18:22:41] <mhaberler> looks like the ucode loaded now
[18:22:58] <zultron> Was PowerNow already disabled, or did you just disable it?
[18:23:11] -!- Loetmichel has quit [Ping timeout: 255 seconds]
[18:23:24] <skunkworks> I diabled it
[18:23:28] <skunkworks> disabled
[18:23:43] <mhaberler> when?
[18:23:59] <zultron> Just now, or last week?
[18:24:16] <zultron> Before or after the previous latency-test run with the 130us latencies, I should ask?
[18:25:28] <skunkworks> just now
[18:25:42] <skunkworks> doesn't really seem to effect anything
[18:26:05] <skunkworks> http://imagebin.org/246285
[18:26:08] <zultron> So, still the 100+us?
[18:26:22] <zultron> D'oh!
[18:26:33] <skunkworks> ran it a few time.. If I do reset it - it seems to peak around 50us
[18:26:42] -!- vladimirek has quit [Quit: Leaving]
[18:27:04] <mhaberler> that's completely outlandish on the base thread
[18:27:15] Cylly is now known as Loetmichel
[18:27:47] <mhaberler> what does xeno-regression-test has to say now? I wonder where those discrepancies come from
[18:28:24] <zultron> skunkworks, just to confirm one more time, the 100+us spikes *always* occur *immediately* after starting latency-test, correct?
[18:28:30] <skunkworks> If I run the regression test - < 5 min I get less than 20us
[18:28:42] <skunkworks> if I run it for 12 hours - I get around 39us
[18:28:56] <skunkworks> zultron, so far yes
[18:29:20] <zultron> Thanks, I think that's important.
[18:29:25] <mhaberler> so xeno-regressio-test is terminal, and latency-test is gui.. I wonder if thats related
[18:29:59] <mhaberler> we have this command-line latency too.. where was that again
[18:30:09] <zultron> The xeno-regression-test has an initial 'warm-up' period. I haven't checked, but I'm tempted to interpret that as something that could get it past this initial spike.
[18:32:14] -!- andypugh [andypugh!~andy2@cpc16-basl9-2-0-cust685.20-1.cable.virginmedia.com] has joined #linuxcnc-devel
[18:32:52] <skunkworks> I do run glxgears (opengl) while running both
[18:34:56] -!- kwallace1 [kwallace1!~kwallace@smb-137.sonnet.com] has joined #linuxcnc-devel
[18:36:20] -!- kwallace has quit [Ping timeout: 240 seconds]
[18:36:52] <skunkworks> I wonder if this is part of it then... If I run the latency-test after running the regression tests - the latency starts out at <10us
[18:37:16] <skunkworks> is there something that isn't getting set in the linuxcnc test?
[18:38:41] <skunkworks> I wonder if that is why that atom seemed to start working - i bet I ran the latency-test after running the regression test.
[18:38:55] <skunkworks> http://imagebin.org/246287
[18:39:11] <mhaberler> ah, now we're talking
[18:39:31] <mhaberler> looks like we hava bit of an artefact here
[18:39:51] <mhaberler> does that remain stable?
[18:40:25] <skunkworks> I will let it run - but so far yes
[18:40:40] <skunkworks> And the atom - Which I think I did the same thing... Ran stable overnight
[18:41:23] -!- odogono has quit [Read error: Connection reset by peer]
[18:41:38] <skunkworks> (matched the regression test numbers iirc)
[18:41:40] <mhaberler> mine too, I'm getting 7.5/16 or so on the d5252mw
[18:42:10] -!- mrsun has quit [Quit: Leaving]
[18:43:19] <skunkworks> I think mine topped out in the 20us range - but I could be wrong. (it is older)
[18:43:45] <skunkworks> so does linuxcnc need a warm up ;)
[18:44:07] <skunkworks> probably on the low end of hp for 12.04
[18:44:12] <mhaberler> no, latency-test needs a review..
[18:45:06] -!- AndChat|244209 has quit [Ping timeout: 276 seconds]
[18:45:37] <skunkworks> are you saying - If I started a realtime linuxcnc instance (like one of the printer port configs) I would not get overruns begining at boot?
[18:46:22] <skunkworks> (I would not have to run the regression tests first?)
[18:46:29] <mhaberler> No, - I just wonder where the dependency comes from, and if there is a repeatable relation
[18:46:51] <mhaberler> like 'cpu now kicked into overdrive' or so ;)
[18:47:00] <skunkworks> 16.7us
[18:47:11] <skunkworks> ah
[18:49:06] <mhaberler> well there's always the ipipe-trace kernel option, but I dont know how to operate that sledgehammer
[18:49:38] <skunkworks> pcw_home, when you get a chance - will you remember to make that bit file?
[18:50:05] <skunkworks> that makes sense - I wonder if there is any processor scalling that can be disabled in the bios
[18:50:52] <mhaberler> if you reboot, and run latency-test again, the spikes reappear?
[18:51:14] <mhaberler> without doing xeno-regression-test before, that is?
[18:52:40] -!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc-devel
[18:55:00] -!- Thetawaves_ has quit [Quit: Leaving]
[19:02:21] <skunkworks> let me try
[19:04:20] <skunkworks> rebooting now - latency before reboot was still under 17us
[19:04:34] <mhaberler> ok
[19:06:40] <skunkworks> Yes - reboot latency is >100us
[19:06:48] <skunkworks> ran it a few times
[19:06:55] <mhaberler> bing
[19:06:56] <mhaberler> o
[19:07:19] <skunkworks> seeing anything?
[19:07:24] <mhaberler> stop latency, run again, check if you get the spikes again
[19:07:36] <skunkworks> I did - a few times
[19:07:46] <mhaberler> always spikes, hm?
[19:08:03] <skunkworks> so far - 5 + times
[19:08:27] <mhaberler> good. now run xeno-regression-test, and when that is done, run latency-test again
[19:08:43] <mhaberler> we need to verify if it is repeatable
[19:08:51] <skunkworks> If I reset the statisics - it usually doesn't go over 50us
[19:08:56] <skunkworks> *60us
[19:09:13] <skunkworks> the test I have been running?
[19:09:31] <skunkworks> or sudo xeno-regression-test
[19:09:40] <mhaberler> the latter
[19:10:14] <mhaberler> we need to find out whether xeno-regression-test has an impact on a later latency-test
[19:10:45] <skunkworks> running now
[19:11:08] <zultron> mhaberler's tenacity is impressive. Looks like you're onto something.
[19:14:11] <skunkworks> anyone know off hand how long the default regression test runs?
[19:14:41] <mhaberler> dont ^C out
[19:15:03] <mhaberler> we need that repeatable, so be patient
[19:15:17] <skunkworks> I won't - I just have to get up and look..
[19:15:24] <zultron> Which is the 'default'? Command line?
[19:15:45] <zultron> The 'heavy' test takes just a few minutes.
[19:16:02] <zultron> The 'light' test with the '100' argument takes maybe 5 mins.
[19:16:04] <skunkworks> jsut sudo xeno-regression-test
[19:16:14] -!- James628 has quit [Quit: Page closed]
[19:16:26] <mhaberler> make sure you run this only once, this is important
[19:16:27] <zultron> Oh, that runs indefinitely.
[19:16:51] <skunkworks> oh - well - then I am going to have to break out of it...
[19:16:58] <zultron> But you can ^C out after a few minutes, not a problem.
[19:17:12] <zultron> Best you copy & paste the command line on the wiki page.
[19:17:13] <mhaberler> reboot before doing it again
[19:17:30] <skunkworks> well - that is what I will do - then check latency - then reboot and run the regression test for say 5 minuts
[19:18:44] <skunkworks> sudo xeno-regression-test
[19:18:50] <skunkworks> heh
[19:18:51] <skunkworks> http://imagebin.org/246292
[19:19:07] <skunkworks> best case ;)
[19:19:25] <mhaberler> what was the sequence: reboot, xeno-regression-test, latency?
[19:19:32] <skunkworks> yes
[19:19:43] <skunkworks> but I had to break out of the regression test
[19:19:56] <mhaberler> ok, I think we have a red hand to show over at the xenomai mailing list
[19:20:10] <zultron> Woo hoo! I think that's the info we need.
[19:20:35] <mhaberler> I would love if you could repeat that once more, I want to be really sure we dont get the guys going on loose facts
[19:20:57] <skunkworks> ok - so what orderw would you like?
[19:21:03] <zultron> Yes please.
[19:21:29] <zultron> I'll have to add skunkworks to the list of folks with impressive tenacity.
[19:21:41] <mhaberler> reboot - latency-test - make sure spike appears
[19:21:58] <skunkworks> boot - run latency-test, (see that it is >100us) run regression test for 5 minuts - then latency test again?
[19:22:02] <mhaberler> then 'sudo xeno-regression-test' as you just run it
[19:22:22] <mhaberler> then latency-test again, and confirm the spikes are gone
[19:22:30] <zultron> I'd put the time length argument in there.
[19:22:31] -!- Wildhoney has quit [Ping timeout: 245 seconds]
[19:23:00] <mhaberler> where?
[19:23:01] <zultron> sudo xeno-regression-test -l "/usr/lib/xenomai/testsuite/dohell -m /tmp 100" -t 2
[19:23:05] <mhaberler> I see
[19:23:09] <mhaberler> great
[19:23:25] <zultron> Without the 100, xeno-regression-test does essentially the same thing, but runs 'dohell' indefinitely.
[19:23:36] <mhaberler> aja
[19:30:10] <skunkworks> http://imagebin.org/246295
[19:30:35] <mhaberler> meaning what?
[19:30:40] <mhaberler> after reboot?
[19:30:48] <mhaberler> or after xeno-regression test?
[19:32:27] <mhaberler> ping?
[19:32:41] <skunkworks> right after boot..
[19:32:46] <skunkworks> running regression test now
[19:32:49] <mhaberler> ok
[19:33:18] -!- Holgi has quit [Client Quit]
[19:33:27] <mhaberler> fine, so spike is back
[19:33:52] <mhaberler> after xeno-regression-test, please leave latency-test running
[19:34:17] <mhaberler> for like overnight or so
[19:36:10] tjb1_ is now known as tjb1
[19:43:22] -!- AFarnsworth has quit [Ping timeout: 245 seconds]
[19:43:42] <skunkworks> ok - the plot thickens thicker.....
[19:43:48] -!- Pitu has quit [Ping timeout: 245 seconds]
[19:43:58] <mhaberler> no more spikes?
[19:44:39] <skunkworks> it seems that if I break out of the regression test - the latency-test is good. If I let the regression test end - the latency-test is bad (>100us)
[19:44:55] <zultron> Whoa!
[19:44:59] <mhaberler> we ned to do a second experiment
[19:45:14] <mhaberler> please do the following steps in order:
[19:45:16] <mhaberler> 1. reboot
[19:45:28] <mhaberler> 2. latency-test in a window
[19:45:35] <mhaberler> 3. wait until spike appears
[19:45:40] <zultron> I start to wonder if LCNC is initializing Xeno properly.
[19:45:57] <mhaberler> 4. open second window
[19:45:58] <mhaberler> hold on
[19:46:16] <mhaberler> 5. in second window, run sudo xeno-regression-test -l "/usr/lib/xenomai/testsuite/dohell -m /tmp 100" -t 2
[19:46:30] <mhaberler> 6. immediately reset the statistics on latency test
[19:47:00] <mhaberler> ok?
[19:47:04] <skunkworks> You can run the latency-test and the regression test at the same time?
[19:47:12] <mhaberler> yes you can
[19:47:14] <skunkworks> cool
[19:47:15] <skunkworks> sure
[19:47:19] <skunkworks> give me a second
[19:47:20] <mhaberler> i just verified that on my atom
[19:47:38] <mhaberler> it had no impact on the latency-test I could discern
[19:48:32] <skunkworks> I am though 99% sure of what I stated above.
[19:49:04] <mhaberler> that is very weird; do you remember where in the regression test you broke out?
[19:49:19] -!- Pitu has quit [Client Quit]
[19:50:49] <skunkworks> I did it quite a few times.. Break out - good latency-test, run regression to compleation bad latency-test
[19:51:06] <skunkworks> durring the part is shows max latency (the end part)
[19:51:18] <mhaberler> I see
[19:51:25] -!- sirdancealot1 has quit [Read error: Operation timed out]
[19:52:16] <mhaberler> well one possibility is that the xenomai rtapi misses some initialisation, and the xeno-regression-test does it 'for him'
[19:52:46] <mhaberler> that would be a possible explanation of what we see here
[19:53:18] <mhaberler> we might be drilling the wrong board
[19:54:38] <mhaberler> skunkworks: if you manage to break out at the right time, yould you post the last line of output from xeno-regression-test?
[19:54:52] <mhaberler> so I can try to reproduce
[19:55:58] <skunkworks> ok - the latency is quite bad until a certain part of the test (and I don't know when that is exactly) latency will peak >50us After reseting the statistics until a certain point of the regressiont test - then it stays under 20us
[19:56:40] <mhaberler> any chance I get the last line of output before ^C?
[19:56:51] <skunkworks> heh - until the refression test ends.. then the latency goes back to > 50us
[19:56:56] <skunkworks> *regression
[19:57:21] -!- syyl_ws has quit [Quit: Verlassend]
[19:57:27] <skunkworks> here from before
http://imagebin.org/246292
[19:57:37] <mhaberler> well if xeno-regression-test 'tries to clean up', that'd be consistent with the above hypothesis
[19:58:00] <mhaberler> I really need that last line of regression test in that scenario
[19:58:53] <skunkworks> did you see 'here from before
http://imagebin.org/246292'
[19:59:06] <mhaberler> oh, sorry. Duh.
[19:59:16] <mhaberler> let me try here
[19:59:16] <skunkworks> You can see the ^c
[19:59:26] <mhaberler> yes, perfect, that was it! thanks+
[19:59:37] <mhaberler> I overlooked the obvious..
[20:03:04] <mhaberler> I tried to reproduce your steps, but it doesnt seem to have an impact on the atom; that doesnt mean there's no causality though
[20:03:15] <mhaberler> I had no spikes on that before to start with
[20:03:35] <mhaberler> can you run the latency test now?
[20:03:44] <mhaberler> I mean 'leave running'
[20:04:14] <mhaberler> looks like copping out of xeno-regression-test is needed to prime the board for linuxcnc ;)
[20:05:22] <mhaberler> we'll have that tried with another fellow who has a 'bad box', see if it makes a difference for him as well
[20:06:05] -!- ravenlock has quit [Ping timeout: 246 seconds]
[20:08:02] <mhaberler> skunkworks: well thanks for all the patient trying, I think we have something to start from; the difference is so dramatic - that suggests some causality
[20:09:03] <mhaberler> I have saved these images for reference, and will put them on a/the wiki page so others can try to reproduce
[20:09:22] <mhaberler> that is a substantial result, even if it has no solution as of now
[20:10:12] <mhaberler> its like a decent smoke cloud in electronics - much easier to locate than a flaky chip
[20:11:32] <mhaberler> skunkworks: just to confirm: the command line of xeno-regression-test - was it exactly this? :
[20:11:42] <mhaberler> sudo xeno-regression-test -l "/usr/lib/xenomai/testsuite/dohell -m /tmp 100" -t 2
[20:11:45] <mhaberler> ?
[20:12:39] <mhaberler> bbl, will read back
[20:13:31] <skunkworks> http://pastebin.ca/2312926
[20:19:19] <mhaberler> thanks, all facts collected
[20:19:40] <skunkworks> could it by my i386 install?
[20:19:53] <mhaberler> ah, thats still i386?
[20:20:14] <skunkworks> I bet my atom is the same way - I bet I broke out of the regression test to run the latency test.
[20:20:19] <skunkworks> yes
[20:20:22] <mhaberler> well *please* verify this is identical on a amd64 install, this is *essential*
[20:20:41] <skunkworks> I will install 64bit on a hd to see.
[20:20:47] <mhaberler> super, thanks
[20:20:47] <skunkworks> but it will take a few days
[20:20:55] <skunkworks> or atleast a day ;)
[20:21:07] <mhaberler> hey, thats going on for months, so what does that matter
[20:21:13] <skunkworks> :)
[20:23:32] <mhaberler> I'd be very curious of the results; also what you find out with that 'process' with other 'patients'
[20:24:39] <skunkworks> No problem - I am glad to troubleshoot
[20:25:26] -!- PCW [PCW!~chatzilla@99.88.10.65] has joined #linuxcnc-devel
[20:25:32] <mhaberler> I'm silently going through my potential list of sins in the xenomai rtapi ;)
[20:26:07] <zultron> mhaberler, another tack is to edit the xeno-regression-test script & chop out tests.
[20:26:20] <zultron> You might be able to isolate a single test that will do the needed 'priming'.
[20:26:35] <mhaberler> hm, sounds like bisection, yes
[20:26:40] <zultron> Then it might be easier to figure out what they're doing that you're not.
[20:27:04] <zultron> Yes, like bisection, but there aren't many tests. Take a look, it's basically a shell script.
[20:27:11] <mhaberler> I wish I had such a 'broken' board
[20:27:35] <zultron> Ah that would help, forgot.
[20:27:48] -!- Mr_Wolfs has quit [Ping timeout: 264 seconds]
[20:27:57] <mhaberler> we just rummage skunkworks's wastebin ;)
[20:28:20] <mhaberler> the standard process of identifying linuxcnc-capable hardware;)
[20:28:44] <mhaberler> ya know, that pentinum...
[20:29:20] -!- JT-Shop has quit [Read error: No route to host]
[20:30:55] <zultron> Ha ha!
[20:31:19] <mhaberler> default approach: start with the test where he hit ^C
[20:32:37] <mhaberler> looks like that was /usr/lib/xenomai/testsuite/switchtest
[20:32:47] <zultron> Yes, that's my guess
[20:33:23] <mhaberler> nope the last ones look very similar
[20:33:27] <zultron> I've run other ones of those tests straight from the command line. Maybe that one will work too.
[20:33:45] <mhaberler> this is similar in outout: /usr/lib/xenomai/testsuite/latency
[20:33:54] <zultron> I think it's running a few things in parallel.
[20:34:08] <mhaberler> could be
[20:34:08] <zultron> latency is responsible for firing off 'dohell'.
[20:34:19] <zultron> Maybe it's the one doing things in parallel, not sure.
[20:34:38] <mhaberler> skunkworks: still around? could you do an extra round of the above?
[20:34:47] <mhaberler> I see
[20:35:00] <skunkworks> reading back
[20:35:18] <zultron> Let me see if I can get a working command line....
[20:35:19] <PCW> skunkworks: freeby.mesanet.com/990.tgz Rutex R990 pinout step/dir config for 5I25 and update script
[20:35:43] <skunkworks> pcw, thanks!!
[20:36:09] <mhaberler> instead of xeno-regression-test, try '/usr/lib/xenomai/testsuite/switchtest'
[20:37:05] <mhaberler> it's be super valuable if that had the same effect (assuming you break out of it)
[20:37:49] <mhaberler> zultron: pretty sure thats the one, compare output to skunkworks screenshot
[20:38:43] <zultron> Sounds believable.
[20:39:03] <skunkworks> well - does it do anything more than the ctx switch test?
[20:39:13] <skunkworks> because that doesn't seem to help the latency
[20:39:23] <mhaberler> no change?
[20:39:36] <skunkworks> no
[20:39:49] <skunkworks> latency jumps up after reset to >60us
[20:39:52] <mhaberler> ok, a few more tries.. :
[20:39:57] <zultron> latency next.
[20:40:22] <zultron> /usr/lib/xenomai/testsuite/latency
[20:40:29] <zultron> sudo /usr/lib/xenomai/testsuite/latency
[20:40:36] <zultron> And ^C out
[20:42:25] <skunkworks> nope
[20:42:27] <skunkworks> http://pastebin.ca/2312935
[20:42:39] <skunkworks> it actually start to show the latency-test issues
[20:43:20] <skunkworks> (I didn't let it run too long)
[20:43:58] <mhaberler> you're doing that in parallel in a separate window now?
[20:44:02] <skunkworks> yes
[20:44:04] <mhaberler> good
[20:44:13] <skunkworks> hitting reset as the tests run
[20:44:18] <skunkworks> and after
[20:44:30] <zultron> mhaberler, should we put the last 5 lines of xeno_regr_test into a separate script, just to be sure we're isolating it?
[20:44:33] <mhaberler> a slight chance: try /usr/lib/xenomai/testsuite/switchtest -s 1000
[20:44:42] <mhaberler> yes
[20:44:55] <mhaberler> but its chinese newyear, maybe we have a lucky punch
[20:45:14] <zultron> It's the year of the snake, not the year of the kangaroo
[20:45:43] <mhaberler> a, snake, all Python then this year
[20:46:02] <skunkworks> Ok - something in that script
[20:46:07] <skunkworks> 5us latency
[20:46:16] <zultron> That's it? Wow
[20:46:30] <zultron> Manpage for 'switchtest' doesn't describe the -s switch. :P
[20:46:52] <skunkworks> It somewhere around where the ctx switch starts
[20:47:12] <mhaberler> 5us latency when copping out of siwtchtest -s 100ß ?
[20:47:43] <skunkworks> well - up to 7us now
[20:47:45] <skunkworks> yes
[20:47:49] <zultron> "--stress <period> or -s <period> enable a stress mode where:\n"
[20:47:52] <zultron> " context switches occur every <period> us;\n"
[20:47:55] <zultron> " a background task uses fpu (and check) fpu all the time.\n"
[20:48:27] <skunkworks> wait - when you ^c out - latency goes back up
[20:48:39] <mhaberler> ha
[20:48:42] <mhaberler> would you mind verifying exavtly that after a reboot?
[20:48:57] <mhaberler> (and when you have the amd64 install of course)
[20:49:22] <skunkworks> sure - do you want me to reboot - run latency test and the above -s 1000 and see if latency gets better?
[20:49:31] <mhaberler> yes, exactly
[20:50:53] <mhaberler> hey, I have a fix, we just smuggle switchtest into the linuxcnc startup script and run it if '-F' for 'Fixit!' is passed ..
[20:51:15] * zultron just vomited into his mouth a little bit
[20:51:36] <mhaberler> you dont appreciate the short customer turnaround time of that fix
[20:52:01] -!- g4ll13n_map has quit [Quit: Leaving]
[20:52:07] -!- V0idExp has quit [Quit: Leaving.]
[20:52:18] <zultron> Ho, hum, that'll be why my business never succeeds, I guess.
[20:52:35] <skunkworks> ok - reboot - bad latency-test - run script - reset latency - good
[20:52:43] <skunkworks> ^c out - bad latency
[20:52:49] <mhaberler> superb!
[20:53:31] <mhaberler> we have some reading to do.. and introspection:
http://git.xenomai.org/?p=xenomai-2.6.git;a=blob;f=src/testsuite/switchtest/switchtest.c;h=3b3c24a65e6bac303e340a993a5d6ab4f4e679ac;hb=d4f8b82905930ceba4d4399d1b2e52ff98860e2a
[20:53:55] <skunkworks> ok - if you don't have anything else you want to try atm - I am going to install 12.04 64bit on a new hd on this system
[20:54:16] <mhaberler> perfect
[20:54:25] <mhaberler> no, you're off the hook
[20:54:42] <skunkworks> I wonder if that is similar to the 'do nothing' script for better latencies on rtai..
[20:54:51] <mhaberler> not unlikely
[20:55:03] * skunkworks loves double negatives...
[20:55:06] <mhaberler> caches do wonderous things to RT
[20:55:16] <mhaberler> a germanism
[20:55:56] <mhaberler> like 'Dieser Vergleich hinkt!" (literally 'this comparison limps')
[20:56:08] <mhaberler> corollary: not everything that limps is a comparison
[20:57:15] -!- odogono has quit [Quit: odogono]
[20:57:57] <mhaberler> skunkworks: I might come back with a modified version of that program divying up in sections so we can nail which section in this 1500lines of C makes the difference
[20:58:21] <mhaberler> hey, superb session, folks - thanks for the patience
[20:59:50] -!- sumpfralle1 has quit [Read error: No route to host]
[21:00:40] -!- sumpfralle has quit [Ping timeout: 276 seconds]
[21:00:52] <skunkworks> no problem - I am keeping the 32bit version hd
[21:01:13] <mhaberler> good, just in case
[21:03:51] <mhaberler> just to verify: the '-s 1000' made the difference? that narrows it down in the code
[21:04:37] <skunkworks> yes
[21:05:07] <mhaberler> ok, thanks
[21:06:49] <mhaberler> remember a link to that idle script you mentioned?
[21:09:01] <skunkworks> trying to find it..
[21:10:04] <mhaberler> super; I dimly remember something
[21:10:16] -!- JT-Shop [JT-Shop!~John@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[21:10:48] <skunkworks> mhaberler,
http://article.gmane.org/gmane.linux.distributions.emc.user/10974/match=do+nothing+script
[21:10:56] <skunkworks> http://article.gmane.org/gmane.linux.distributions.emc.user/10974/match=do+nothing+script
[21:11:12] <skunkworks> Running the bash script `while true ; do echo
[21:11:12] <skunkworks> > "nothing" > /dev/null ; done
[21:11:24] <mhaberler> right
[21:11:33] <mhaberler> would you mind trying that?
[21:11:56] <skunkworks> sure - after I try the 64bi
[21:11:57] <skunkworks> bit
[21:13:16] <mhaberler> JMK's theory is still worth considering, it makes all sense
[21:15:33] <mhaberler> the salient part of switchtest seems to be that with -s it forces a high rate of context switches
[21:16:12] <mhaberler> that isnt all to far away from swpadnos script
[21:20:43] <skunkworks> yes - that is where I remember it from
[21:21:08] <skunkworks> oh
[21:21:15] <skunkworks> I understand what you where saying
[21:24:10] <mhaberler> I almost exclude cache issues because 90uS difference cannot be explained that way
[21:24:49] <mhaberler> that suggests looking more closely a CPU frequency scaling, power save, that kind of thing
[21:25:10] <mhaberler> that would likely get shot down by such a script, and switchtest
[21:25:59] <mhaberler> skunkworks: would you pastebin the output of 'dmidecode -t 4'
[21:26:33] <mhaberler> that tells the exact CPUID, version, errata, etc
[21:27:24] -!- micges has quit [Quit: Leaving]
[21:27:56] <mhaberler> btw I'm just trying that script on my atom; need to leave it on overnight but gut feeling it improves things a bit here too
[21:30:01] -!- norbert has quit [Quit: Verlassend]
[21:32:49] <mhaberler> anyway, I'm off for the day - thanks!
[21:32:52] <skunkworks> hold
[21:32:57] <mhaberler> ah!
[21:33:11] <skunkworks> http://pastebin.ca/2312954
[21:33:36] <mhaberler> yes, that was it, thanks
[21:33:56] <skunkworks> another 5 -10 minuts and I would have the latency test running (I think)
[21:37:21] <mhaberler> ok, I'll be back in 10mins
[21:37:21] -!- psha has quit [Quit: leaving]
[21:39:07] <skunkworks> Ok - first run of latency test - >100us
[21:42:38] -!- mhaberler has quit [Ping timeout: 255 seconds]
[21:44:19] -!- mhaberler [mhaberler!~mhaberler@extern-187.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[21:44:24] <skunkworks> and running /usr/lib/xenomai/testsuite/switchtest -s 1000
[21:44:41] <skunkworks> make the latency <10us
[21:44:55] <skunkworks> so - seems to run exactly as the 32 bit install
[21:44:57] <skunkworks> whew
[21:45:31] <skunkworks> zultron, I don't know if you where listening - but I bet that is exactly what was happening on the atom....
[21:45:39] <skunkworks> but I will boot that tomorrow
[21:45:53] <mhaberler> very well
[21:46:14] <mhaberler> you mean you already installed an amd64 root and all?
[21:46:28] <skunkworks> would a 'do nothing' script cause the system to be slower?
[21:46:47] <skunkworks> mhaberler, yes - installed your linuxcnc and stuff
[21:47:27] <skunkworks> (and zultron's kernel)
[21:47:29] <mhaberler> that 'do nothing' isnt a good fix, but it'd be interesting to see if it has a similar effect
[21:47:47] <skunkworks> how would I do that? (I don't do scripts )
[21:48:01] <mhaberler> hold on
[21:48:13] <skunkworks> I could test that right now
[21:49:48] <zultron> skunkworks, didn't we fix the problem on the atom, even though we weren't sure which tweak finally did the trick?
[21:50:02] <mhaberler> wget
http://static.mah.priv.at/public/latency/donothing.sh
[21:50:12] <skunkworks> well - I don't knnow. We did the smi - but I also ran the regression testing
[21:50:12] <mhaberler> then run as 'sh donothing.sh'
[21:50:43] <zultron> Ah, interesting.
[21:52:08] -!- syyl has quit [Quit: Leaving]
[21:52:53] <mhaberler> wanna try the donothing in lieu of switchtest -s ?
[21:53:11] -!- l2 has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
[21:53:51] <skunkworks> that seems to have the same efffect
[21:53:59] <mhaberler> oh
[21:54:00] <skunkworks> latencies sub 10us initally
[21:54:14] <skunkworks> as it is running - sub 10us
[21:54:25] <mhaberler> ha!
[21:54:27] <skunkworks> break out - back up to 60+us
[21:54:49] <mhaberler> leave latency-test running, just reset stats
[21:54:53] <skunkworks> (ok - aprox 15us)
[21:54:57] <skunkworks> yes
[21:55:04] <mhaberler> try with or without script in separate window
[21:55:16] <skunkworks> yes
[21:55:21] -!- frallzor has quit []
[21:55:40] <skunkworks> (2 terminals - one running latency-test and one running donothing script)
[21:55:47] <mhaberler> good
[21:56:21] -!- Tom_L has quit []
[21:56:46] -!- DJ9DJ has quit [Quit: bye]
[21:56:54] <mhaberler> well it looks that is now narrowed down sufficiently; at least that doesnt require wading through tons of test cases
[21:57:07] <zultron> Sorry, I've been paying attention to something else. This doesn't explain why switchtest -s 1000 ^C fixes the problem, right?
[21:57:54] <mhaberler> it does
[21:58:03] <mhaberler> ^C removes the context switching load
[21:58:10] <mhaberler> bang, spike is back
[21:58:18] -!- skunkworks_ [skunkworks_!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[21:58:22] <mhaberler> well if I understand it correctly, donothing.sh has the same effect as switchtest -s 1000 running
[21:58:29] <mhaberler> ah, back he is
[21:59:09] <mhaberler> skunkworks: would you subscribe to that? 'donothing.sh has the same effect as switchtest -s 1000 running'
[21:59:23] <zultron> Yes, but I thought the first thing we found was after running xeno-regression-test and ^C, the latency-test ran fine?
[21:59:42] <mhaberler> hm, good point
[21:59:55] <mhaberler> it isnt equivalent
[22:00:01] <mhaberler> you're right
[22:00:12] <zultron> Could xeno-regression-test ^C have left an orphan process running behind?
[22:00:28] <zultron> Try again while running 'top'?
[22:00:46] -!- FinboySlick has quit [Quit: Leaving.]
[22:01:05] -!- skunkworks has quit [Ping timeout: 255 seconds]
[22:01:10] <zultron> D'oh
[22:02:50] <skunkworks_> same as running /usr/lib/xenomai/testsuite/switchtest -s 1000
[22:03:19] <skunkworks_> (or ^cing out of the regression test)
[22:03:48] <skunkworks_> have to go - bbl
[22:04:03] <mhaberler> sure
[22:04:05] <skunkworks_> staying under 20us
[22:04:07] <mhaberler> cu!
[22:04:48] -!- Sendoushi has quit [Read error: Connection reset by peer]
[22:06:42] <mhaberler> that permanent improvement after ^C leaves me puzzled
[22:08:06] -!- Nick001 has quit [Ping timeout: 252 seconds]
[22:08:10] -!- MarkusBec has quit [Ping timeout: 260 seconds]
[22:08:39] -!- andypugh has quit [Quit: andypugh]
[22:10:39] -!- skunkworks_ has quit [Read error: Connection reset by peer]
[22:20:48] -!- andypugh [andypugh!~andy2@cpc16-basl9-2-0-cust685.20-1.cable.virginmedia.com] has joined #linuxcnc-devel
[22:23:48] -!- toudi_ [toudi_!~toudi@adcs173.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[22:23:48] toudi_ is now known as micges
[22:32:21] -!- micges has quit [Quit: Leaving]
[22:33:58] -!- Tom_L has quit []
[22:34:26] -!- toudi_ [toudi_!~toudi@adcs173.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[22:34:30] toudi_ is now known as micges
[22:36:30] -!- wildbilldonovan has quit [Quit: EOT]
[22:43:50] -!- Nick001-Shop has quit [Ping timeout: 255 seconds]
[22:44:02] Nick001-Shop_ is now known as Nick001-Shop
[22:48:35] -!- skunkworks [skunkworks!~chatzilla@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[22:50:51] <skunkworks> logger[ps
[22:50:54] <skunkworks> logger[psha]:
[22:59:32] -!- AFarnsworth has quit [Quit: Page closed]
[23:14:34] -!- sumpfralle has quit [Read error: Operation timed out]
[23:15:20] -!- skorasaurus has quit [Quit: left the building.]
[23:15:38] -!- Brandonian has quit [Quit: Brandonian]
[23:17:26] -!- sumpfralle1 has quit [Ping timeout: 248 seconds]
[23:19:23] -!- mhaberler has quit [Quit: mhaberler]
[23:26:23] -!- ravenlock has quit [Ping timeout: 245 seconds]
[23:27:02] -!- sirdancealot1 has quit [Ping timeout: 255 seconds]
[23:35:52] -!- racycle has quit [Quit: racycle]
[23:36:38] -!- andypugh has quit [Quit: andypugh]
[23:40:57] -!- micges has quit [Quit: Wychodzi]
[23:49:18] -!- toudi_ [toudi_!~toudi@adcs173.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[23:49:22] toudi_ is now known as micges
[23:49:43] -!- sumpfralle2 has quit [Ping timeout: 245 seconds]
[23:51:32] -!- sumpfralle has quit [Read error: Operation timed out]
[23:51:33] -!- zzolo has quit [Quit: zzolo]
[23:52:39] -!- smsfail has quit [Remote host closed the connection]