Back
[00:18:17] -!- adb has quit [Ping timeout: 252 seconds]
[00:18:38] -!- i_tarzan has quit [Ping timeout: 252 seconds]
[00:25:44] -!- gedw has quit [Quit: Page closed]
[00:37:06] -!- kwallace [kwallace!~kwallace@tmb-246.sonnet.com] has joined #linuxcnc-devel
[00:39:23] -!- kwallace1 has quit [Ping timeout: 255 seconds]
[01:04:07] -!- nOStahl has quit [Quit: nOStahl]
[01:04:41] -!- rob_h has quit [Ping timeout: 255 seconds]
[01:08:19] -!- Gene34 has quit []
[01:29:00] -!- micges has quit [Quit: Leaving]
[01:39:47] -!- mattions has quit [Ping timeout: 248 seconds]
[01:40:31] -!- servos4ever has quit [Quit: ChatZilla 0.9.85 [SeaMonkey 2.0.11/20101206162726]]
[01:51:51] -!- stsydow has quit [Ping timeout: 260 seconds]
[01:53:22] -!- stsy has quit [Remote host closed the connection]
[02:07:54] -!- sumpfralle has quit [Ping timeout: 252 seconds]
[02:10:03] -!- sumpfralle1 has quit [Ping timeout: 260 seconds]
[02:18:11] -!- sumpfralle2 has quit [Ping timeout: 256 seconds]
[02:28:20] <KGB-linuxcnc> 03chrisinnanaimo 05master 32f6dcd 06emc2 10lib/python/ 10gladevcp/offsetpage.glade 10gladevcp/offsetpage_widget.py * gladevcp -add editing and zero g92 options to offsetpage widget
[02:33:23] -!- asdfasd has quit [Ping timeout: 260 seconds]
[02:55:14] -!- danielfalck [danielfalck!~danielfal@static-50-53-1-104.bvtn.or.frontiernet.net] has joined #linuxcnc-devel
[03:15:38] -!- ravenlock has quit [Remote host closed the connection]
[03:24:42] -!- sumpfralle has quit [Ping timeout: 264 seconds]
[03:26:09] -!- paideia has quit [Quit: Leaving]
[03:27:54] -!- skunkworks has quit [Remote host closed the connection]
[03:29:39] -!- sumpfralle1 has quit [Ping timeout: 248 seconds]
[03:47:26] <seb_kuzminsky> hi danielfalck, long time no see
[04:03:35] -!- JT-Shop has quit [Ping timeout: 256 seconds]
[04:03:35] -!- jthornton_ [jthornton_!~john@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[04:03:36] -!- JT-Shop-2 [JT-Shop-2!~John@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[04:03:36] -!- jthornton has quit [Read error: Connection reset by peer]
[04:12:47] -!- Wildhoney has quit [Ping timeout: 255 seconds]
[04:34:11] -!- cmorley [cmorley!~chris@S010600c09fc019c2.no.shawcable.net] has joined #linuxcnc-devel
[04:36:07] <linuxcnc-build_> build #785 of hardy-i386-realtime-rip is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-realtime-rip/builds/785 blamelist: Chris Morley <chrisinnanaimo@hotmail.com>
[04:36:41] -!- cmorley1 has quit [Ping timeout: 245 seconds]
[04:37:54] <linuxcnc-build_> build #783 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/783 blamelist: Chris Morley <chrisinnanaimo@hotmail.com>
[04:40:54] -!- mikegg has quit [Ping timeout: 264 seconds]
[04:41:24] -!- Valen has quit [Quit: Leaving.]
[04:44:11] <danielfalck> hi seb_kuzminsky
[04:52:31] -!- Tom_itx has quit [Ping timeout: 252 seconds]
[04:58:07] -!- cmorley1 [cmorley1!~chris@S010600c09fc019c2.no.shawcable.net] has joined #linuxcnc-devel
[05:00:11] -!- cmorley has quit [Ping timeout: 240 seconds]
[05:01:24] -!- Tom_itx has quit [Ping timeout: 252 seconds]
[05:02:25] -!- hdokes has quit [Ping timeout: 248 seconds]
[05:18:32] <seb_kuzminsky> that buildbot failure is another mdi command getting dropped in task
[05:18:58] <seb_kuzminsky> buildbot.linuxcnc.org/buildbot/builders/hardy-i386-realtime-rip/builds/785/steps/runtests/logs/stdio
[05:19:03] <seb_kuzminsky> search for "checkresult"
[05:19:28] <seb_kuzminsky> notice that the difference between the test output and the expected output is that the output lacks a couple of lines
[05:19:41] <seb_kuzminsky> each line in the output is produced by an mdi call
[05:20:07] <seb_kuzminsky> sequence numbers 100 and 200 follow the only two M6 calls in the test
[05:20:29] <seb_kuzminsky> M6 is the only long-running MDI call in this test, so the only call that causes mdi queueing to be exercised
[05:21:01] <seb_kuzminsky> i have a new way of fixing the mdi queue bug, better than the branch i pushed last night, i'll push it soon
[05:21:09] -!- cmorley [cmorley!~chris@S010600c09fc019c2.no.shawcable.net] has joined #linuxcnc-devel
[05:24:20] -!- cmorley1 has quit [Ping timeout: 256 seconds]
[05:41:52] -!- cmorley1 [cmorley1!~chris@S010600c09fc019c2.no.shawcable.net] has joined #linuxcnc-devel
[05:43:36] -!- sumpfralle has quit [Ping timeout: 256 seconds]
[05:45:02] -!- cmorley has quit [Ping timeout: 252 seconds]
[05:49:25] -!- mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[05:49:37] -!- tcb_ has quit [Ping timeout: 245 seconds]
[05:52:33] <seb_kuzminsky> mhaberler: i have a simpler mdi queue fix nearly ready to push
[05:52:45] <mhaberler> Hi Seb!
[05:53:26] <mhaberler> I tried in a VM, and was unable to trigger your fix into action (no errors); I tried on the bb and mdi-queue-fix kept failing
[05:54:04] <mhaberler> I might have made a mistake, but on the bb the 'reset emcCommand' branch isnt executed
[05:54:22] <mhaberler> I think we need a more reliable way of reproducing the error
[05:54:53] <seb_kuzminsky> i can repro the bug every time
[05:55:03] <mhaberler> in a VM with load?
[05:55:22] <seb_kuzminsky> you checked out the commit that adds the test but not the commit that adds the fix, loaded the VM way down, and you couldn't repro the bug?
[05:55:32] <seb_kuzminsky> yes, my VM is very busy
[05:55:47] <KGB-linuxcnc> 03seb 05mdi-queue-bugfix-2 ad79255 06emc2 10src/emc/task/emctaskmain.cc * fix an mdi queueing bug
[05:56:10] <mhaberler> ok, I can back out the fix and retry on the VM; what I did is add a message to milltask which would tell if the emcCommand reset happens
[05:56:20] <mhaberler> ok, I'll read it
[05:56:52] <seb_kuzminsky> you saw the mdi-queue-bugfix branch fail on the buildbot? i've never seen that
[05:57:22] <mhaberler> no, I didnt - on my mac in a vbox VM
[05:58:24] <seb_kuzminsky> ah ok
[05:59:03] <seb_kuzminsky> so in a vm on your mac, you saw the mdi-queue-bugfix branch's mdi-queue test fail?
[05:59:21] -!- nOStahl has quit [Quit: nOStahl]
[05:59:24] <seb_kuzminsky> i guess i don't understand what exeriments you've run and what the results were
[05:59:44] <seb_kuzminsky> my results are this:
[06:00:40] <seb_kuzminsky> commit 877511a5 (which adds the mdi-queue test on top of origin/master) fails every time on a heavily loaded VM
[06:01:23] <seb_kuzminsky> commit ad79255a (the tip of the mdi-queue-bugfix-2 branch i just pushed) hasn't failed yet under the same load, still running (i'll let it run overnight)
[06:02:07] <mhaberler> two questions:
[06:02:14] <seb_kuzminsky> commit 32cf64887 (the tip of the mdi-queue-bugfix branch i pushed last night) has never failed under the same load, but it's more invasive and i don't trust the fix as well
[06:02:32] -!- AR__ has quit [Ping timeout: 252 seconds]
[06:03:04] <seb_kuzminsky> also, the t0 and linuxcncrsh tests in master currently fail occasionally on the buildbot when folks push to master (and they don't fail on 2.5 on the buildbot, which further implicated mdi queueing)
[06:03:05] -!- Fox_Muldr has quit [Ping timeout: 260 seconds]
[06:03:05] <mhaberler> the way I read your new fix is: you update task.echo_serial_number annd echo_serial_number in emcStatus only after the MDI queue has been emptied, correct?
[06:04:06] <mhaberler> (bottom part of
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=commitdiff;h=ad79255a7f6f072835ede1a70aee813dcdc6c7fb)
[06:04:39] <seb_kuzminsky> almost
[06:04:54] <mhaberler> what's missing in my reading?
[06:06:28] <seb_kuzminsky> if a non-mdi command comes in while the mdi queue is non-empty, i think it gets to run immediately, which might be a new bug :-/
[06:07:21] <mhaberler> depends on the command; eg an abort should be executed immediately
[06:07:46] <seb_kuzminsky> i dont really understand the triply-nested switch in emcTaskPlan()...
[06:08:02] <seb_kuzminsky> the goal of mdi-queue-bugfix-2 was this:
[06:08:07] <mhaberler> welcome to the club
[06:09:09] <seb_kuzminsky> keep track of where the currently running command came from (mdi queue of NML Command channel) and only update the echo_serial_number if we actually took something off the NML command channel
[06:09:44] <mhaberler> yes, that implies you dont update it while working through the MDI queue
[06:10:51] <seb_kuzminsky> yeah, i'm just not sure of how it interacts with non-mdi commands while the mdi queue is in use
[06:11:14] <seb_kuzminsky> that's the only caveat, other than that your reading is right
[06:11:23] <mhaberler> the question which is open to me is (since theres no spec I could see):
[06:12:03] <mhaberler> is there an assumption on ordering of serials? there are equality or greater-than tests I've seen
[06:12:43] -!- danielfalck has quit [Ping timeout: 260 seconds]
[06:13:03] <mhaberler> but before going into details, lets stand back a sec:
[06:13:33] <mhaberler> a) the 'MDI queuing feature' in 2.5 never was one, and it was terminally broken because it happened by accident
[06:13:59] <mhaberler> b) my first stab was to NOT accept commands if interp isnt idle
[06:14:24] <mhaberler> c) the crowd started howling how terminally useful this queueing feature is - read back on ML
[06:14:44] <mhaberler> d) I said: ok, in that case lets do it, buth planned, not ad-hack
[06:14:57] <mhaberler> there are really two options;
[06:15:09] <mhaberler> either queue in the UI, or queue in task
[06:15:44] <mhaberler> I opted for the latter, but it might not be the best place
[06:16:01] <seb_kuzminsky> seems like the right place to me
[06:16:43] <seb_kuzminsky> it's a useful feature (at least i use it), and it's nice to code once and let all UIs benefit from it
[06:16:51] <mhaberler> not totally sure; if for instance MDI queueing has the side effect of postponing processing an abort, that is a bummer
[06:17:13] <mhaberler> that was my thinking at the time, yes - do it once right
[06:17:13] <seb_kuzminsky> reading emcTaskPlan more closely, i think it does not delay ABORT
[06:17:24] <seb_kuzminsky> famous last words ;-)
[06:17:44] <mhaberler> well if it short-circuites immediate commands instead of queuing them that would be fine
[06:17:53] <mhaberler> worth a read, as you say
[06:18:39] <seb_kuzminsky> line 1389 of emctaskmain.cc
[06:18:46] <mhaberler> I might have forgotten: where exactly is a command lost?
[06:19:34] <seb_kuzminsky> the condition that causes an mdi command to be lost is this:
[06:19:44] <seb_kuzminsky> 1. mdi queue len > 0
[06:20:05] <seb_kuzminsky> 2. interp idle (so it just finished working and is ready for the next thing)
[06:20:20] <seb_kuzminsky> 3. new mdi command on NML Command channel
[06:20:46] <seb_kuzminsky> if 2 and 3 happen at the same time (ie on the same invocation of emcTaskPlan()), then the command on the NML channel is lost
[06:20:48] <mhaberler> so it pulls 3) instead of from q?
[06:20:59] <mhaberler> oh I see
[06:21:00] <seb_kuzminsky> it drops 3 and runs the command from the queu
[06:21:24] <seb_kuzminsky> i'm surprised (and a little worried) that you can't repro the bug using the mdi-queue test
[06:21:37] <mhaberler> me too
[06:21:40] -!- toxx has quit [Ping timeout: 276 seconds]
[06:21:50] <seb_kuzminsky> would you try checking out just that commit (without either of the two alternative bug-fix commits that follow it) and run it repeatedly on a loaded VM?
[06:21:58] <mhaberler> sure
[06:22:18] <mhaberler> what I'd like to see is the corrective action kicking in
[06:23:01] <seb_kuzminsky> i'll push another commit on the mdi-queue-bugfix-2 branch that adds the debug printing i've been using, if you cherry-pick that commit on top of the commit that adds the test, the problem becomes more clear
[06:23:11] <mhaberler> ok
[06:23:35] <seb_kuzminsky> hm, the debug print commit won't apply cleanly on that commit, hold on
[06:25:40] <mhaberler> let me go back to the condition
[06:26:02] <mhaberler> 2, and 3, - does that imply this:
[06:26:43] <mhaberler> finishing the queued command causes an update of the serial number, which makes the sender believe the new NML command was processed, whereas in fact the serial update was for a queued command?
[06:26:48] <KGB-linuxcnc> 03seb 05mdi-queue-bug e1d9256 06emc2 10src/emc/ 10task/emctask.cc 10task/emctaskmain.cc 10usr_intf/emcrsh.cc 10usr_intf/shcom.cc * some useful debug printing for the mdi queue bug
[06:26:56] <seb_kuzminsky> no
[06:27:17] <mhaberler> but?
[06:27:18] <seb_kuzminsky> the serial number is updated when the command is moved from the NML Command channel to the mdi queue
[06:27:25] <mhaberler> ok
[06:28:06] <mhaberler> then why is the command lost
[06:28:13] <seb_kuzminsky> ok, if you check out mdi-queue-bug, run the mdi-queue test, and inspect /tmp/linuxcnc.print.*, and the bug bites, you'll see exactly what happens
[06:28:31] <mhaberler> ok
[06:28:50] <seb_kuzminsky> but the wonky linuxcnc starter script likes to remove the log file when linuxcnc finishes, so make sure you open it in less before the test is over
[06:29:03] <mhaberler> ah
[06:29:36] <mhaberler> I always wondered where these mythical log files are ;)
[06:29:36] -!- cmorley [cmorley!~chris@S010600c09fc019c2.no.shawcable.net] has joined #linuxcnc-devel
[06:29:57] <mhaberler> fair enough, it might take a while
[06:30:27] <seb_kuzminsky> yeah, making the logfiles more accessible & useful is on my list, somewhere...
[06:30:46] <seb_kuzminsky> i find myself fixing logging each time i chase a bug, it's kind of annoying
[06:31:04] <mhaberler> it shouldnt delete if some debug flag is given
[06:31:45] <mhaberler> anyway I pull mdi-queue-bug, build, run mdi-queue tests and hope to catch and read the logfiles. Correct?
[06:32:01] -!- cmorley1 has quit [Ping timeout: 248 seconds]
[06:32:48] -!- FinboySlick has quit [Quit: Leaving.]
[06:33:35] <seb_kuzminsky> yeah
[06:33:46] <seb_kuzminsky> or look here:
http://highlab.com/~seb/linuxcnc/mdi-queue
[06:34:11] <mhaberler> You don't have permission to access /~seb/linuxcnc/mdi-queue/linuxcnc.print.Wps8g9 on this server.
[06:34:25] <seb_kuzminsky> hm
[06:34:44] <mhaberler> I can read runtest-output though
[06:35:23] <seb_kuzminsky> try now
[06:35:24] <mhaberler> do I need to load the VM or 'will it fail reliably' ;-?
[06:35:38] <mhaberler> yep, that did it
[06:35:39] -!- The_Ball has quit [Ping timeout: 244 seconds]
[06:35:41] <seb_kuzminsky> it fails reliably for me when the VM is loaded
[06:35:48] <mhaberler> ok
[06:35:50] <seb_kuzminsky> it fails but less reliably when the VM is not loaded
[06:36:03] <seb_kuzminsky> not my favourite test, but timing stuff is hard to test reliably
[06:36:14] <mhaberler> where on earth do I get I slow Mac from
[06:36:24] <seb_kuzminsky> ok, in the runtest-output, notice that P5, P108, P372, etc, all got dropped
[06:36:39] <seb_kuzminsky> then in the log file, search for (for example) P5
[06:36:56] <mhaberler> yes, I see
[06:37:03] <seb_kuzminsky> the first instance is linuxcncrsh telling you it read that mdi command on its input socket
[06:37:35] <seb_kuzminsky> then it's linuxcncrsh saying it's sending it as an MDI command on the NML channel
[06:38:26] <seb_kuzminsky> immediately after that, task says it's running emcTaskPlan(), interp is idle, it's got serial number 14 in the NML channel, it's echoed serial number 13, and there are two mdi commands in the queue
[06:38:49] <seb_kuzminsky> task notices there's a new command (NML serial number != echo serial number)
[06:39:19] <seb_kuzminsky> at this point it *should* take the new command off the NML channel and put it in the mdi queue, then dequeue the next thing from the mdi queue, right?
[06:40:04] <mhaberler> give me some time to reproduce and think through it
[06:40:09] <seb_kuzminsky> it dequeues the P3 mdi command and runs it (notice that echo serial number moves back from 13 to 12)
[06:40:20] <mhaberler> aja
[06:41:14] <seb_kuzminsky> then while interp is chewing on the P3 MDI, in the next couple of invocations of emcTaskPlan, it incorrectly echoes serial number 14 without queueing it, and that's how the command is lost
[06:41:17] <mhaberler> need to look at shcom.cc - what is the serial number condition to send a new command?
[06:41:36] <mhaberler> euality with current? greater-than?
[06:41:39] <seb_kuzminsky> it's not shcomm's fault, it's task
[06:41:47] <seb_kuzminsky> i don't know what shcomm does
[06:42:03] <seb_kuzminsky> the command that gets lost was sent at the correct time, and nothing new gets sent until after it's been lost
[06:42:10] <mhaberler> I am not talking faults, I want to understand the condition under which a new command is sent
[06:42:17] <mhaberler> let me see
[06:42:26] <seb_kuzminsky> i got to go, good night! i think mdi-queue-bugfix-2 is the correct fix
[06:42:49] <mhaberler> fair enough, I'll give it a workout
[06:43:01] <mhaberler> good night
[06:43:02] <seb_kuzminsky> i'll not be on irc much until wednesday, but i'll be on email occasionally
[06:43:06] <seb_kuzminsky> talk to you later
[06:43:13] <mhaberler> ok
[06:44:02] <mhaberler> if (emcStatus->echo_serial_number == serial_number) {
[06:44:06] <mhaberler> it is equality
[06:44:47] <mhaberler> maybe the cause is: if it sees a lower serial due to MDI dequeing it thinks its good to go
[06:45:13] <mhaberler> I will try a modified test there just to make sure thats whats happening
[06:45:27] <mhaberler> the serial going back might trigger the new command queuing
[06:45:38] <mhaberler> line 294 shcom.cc
[06:50:32] <mhaberler> bug seen on first run now
[07:01:49] <mhaberler> ok, I think I have digested your description of the sequence of events to failure
[07:03:44] <mhaberler> IMO there are two ways dealing with it; eager and lazy
[07:04:08] <mhaberler> eager would mean: fetch and enqueue MDI command if space in queue
[07:04:46] -!- kwallace [kwallace!~kwallace@tmb-246.sonnet.com] has parted #linuxcnc-devel
[07:04:47] <mhaberler> lazy would mean: stop updating serials until MDI queue empty
[07:05:38] <mhaberler> so your approach is to suppress serial update if working the MDI queue
[07:05:59] <mhaberler> eager would really just postpone the problem to MDI queue full
[07:06:49] <mhaberler> I think it's worth spelling out the rule under which serials may be updated; IMO this is:
[07:07:16] <mhaberler> a serial may be updated if either the command has been passed to the interp, or it has been added to the MDI queue
[07:07:31] <mhaberler> obviously we fail here
[07:13:13] <mhaberler> holy cow, that whole shcom.cc fluff is duplicated in halui.cc
[07:14:41] <mhaberler> aaarrrgh - seems we're not doing libraries out here, what a wart
[07:16:23] -!- Keknom has quit [Quit: Leaving.]
[07:38:49] -!- tjb1 has quit [Quit: tjb1]
[08:04:19] -!- ravenlock has quit [Ping timeout: 248 seconds]
[08:26:28] <linuxcnc-build_> build #788 of precise-i386-sim is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-sim/builds/788 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[08:29:54] <linuxcnc-build_> build #790 of precise-amd64-sim is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-sim/builds/790 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[08:37:25] -!- rob_h [rob_h!~rob_h@5e04027e.bb.sky.com] has joined #linuxcnc-devel
[08:50:01] <linuxcnc-build_> build #786 of lucid-i386-sim is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-sim/builds/786 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[08:57:54] <linuxcnc-build_> build #786 of lucid-amd64-sim is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-amd64-sim/builds/786 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[08:58:22] <linuxcnc-build_> build #787 of lucid-i386-realtime-rip is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-realtime-rip/builds/787 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[09:06:38] <linuxcnc-build_> build #785 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/785 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[09:21:54] -!- skullworks has quit [Quit: Page closed]
[09:48:23] -!- V0idExp has quit [Ping timeout: 255 seconds]
[09:51:12] -!- mattions has quit [Quit: Leaving]
[10:00:16] -!- rob_h has quit [Quit: Leaving]
[10:15:33] -!- skorasaurus has quit [Ping timeout: 245 seconds]
[10:21:13] -!- racycle has quit [Quit: racycle]
[10:33:10] -!- L33TG33KG34R has quit [Ping timeout: 256 seconds]
[10:45:11] -!- _ink has quit [Ping timeout: 255 seconds]
[11:41:26] -!- syyl_ has quit [Ping timeout: 255 seconds]
[11:47:56] -!- stsydow has quit [Ping timeout: 245 seconds]
[11:56:12] -!- V0idExp1 has quit [Quit: Leaving.]
[12:32:39] -!- i_tarzan has quit [Read error: Connection reset by peer]
[13:05:12] jthornton_ is now known as jthornton
[13:45:17] -!- psha [psha!~psha@213.208.162.67] has joined #linuxcnc-devel
[13:56:29] -!- V0idExp has quit [Ping timeout: 252 seconds]
[14:01:04] -!- skunkworks [skunkworks!~chatzilla@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[14:10:57] -!- norbert [norbert!~norbert@a89-182-179-43.net-htp.de] has joined #linuxcnc-devel
[14:41:44] -!- motioncontrol has quit [Read error: Operation timed out]
[14:45:46] -!- holgi has quit [Quit: ChatZilla 0.9.90 [Firefox 18.0.2/20130201233328]]
[15:06:36] -!- kwallace [kwallace!~kwallace@smb-62.sonnet.com] has joined #linuxcnc-devel
[15:07:59] <seb_kuzminsky> mhaberler: the serial check should probably be equality, to handle wrap-arounds of the serial number
[15:42:27] -!- Dupe has quit [Quit: Leaving]
[15:50:38] -!- V0idExp has quit [Ping timeout: 255 seconds]
[15:50:52] -!- karavanjoW has quit [Client Quit]
[15:51:49] -!- karavanjoW has quit [Client Quit]
[15:59:48] -!- karavanjoW has quit [Quit: KVIrc 4.0.4 Insomnia http://www.kvirc.net/]
[16:06:11] -!- micges [micges!~toudi@acwc172.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[16:07:05] JT-Shop-2 is now known as JT-Shop
[16:07:14] <seb_kuzminsky> mhaberler: i bet we can make this bug easier to reproduce by adding a 100 ms sleep in mdi_execute_hook() when setting the interp state to idle
[16:07:56] <seb_kuzminsky> isn't lazy serial number updating the same a no queueing?
[16:08:08] <seb_kuzminsky> ah well, i'm out for a while, bye!
[16:29:18] -!- danielfalck [danielfalck!~danielfal@static-50-53-1-104.bvtn.or.frontiernet.net] has joined #linuxcnc-devel
[16:29:56] -!- Tom_itx has quit [Ping timeout: 252 seconds]
[16:51:31] -!- mikegg has quit [Ping timeout: 244 seconds]
[17:03:56] -!- [2]DaveB [[2]DaveB!~MVcalypso@c-24-4-122-138.hsd1.ca.comcast.net] has joined #linuxcnc-devel
[17:03:56] -!- [1]DaveB has quit [Read error: Connection reset by peer]
[17:05:59] -!- [1]DaveB [[1]DaveB!~MVcalypso@c-24-4-122-138.hsd1.ca.comcast.net] has joined #linuxcnc-devel
[17:05:59] -!- [2]DaveB has quit [Read error: Connection reset by peer]
[17:32:13] -!- psha has quit [Quit: leaving]
[17:36:29] -!- stsydow has quit [Remote host closed the connection]
[17:40:05] -!- sumpfralle has quit [Ping timeout: 255 seconds]
[17:40:46] -!- Youdaman has quit []
[17:41:23] -!- sumpfralle1 has quit [Ping timeout: 248 seconds]
[17:47:10] -!- holgi has quit [Read error: Connection reset by peer]
[17:54:19] -!- holgi has quit [Client Quit]
[18:24:55] -!- Loetmichel has quit [Ping timeout: 256 seconds]
[18:25:53] -!- Tom_itx has quit [Ping timeout: 255 seconds]
[18:33:19] -!- Wildhoney has quit [Ping timeout: 260 seconds]
[18:34:05] -!- zlog has quit [Remote host closed the connection]
[18:41:47] -!- motioncontrol has quit [Quit: Sto andando via]
[18:53:24] -!- norbert has quit [Quit: Verlassend]
[19:03:42] -!- danielfalck has quit [Ping timeout: 264 seconds]
[19:05:03] -!- mhaberler has quit [Quit: mhaberler]
[19:20:25] -!- cpresser_ has quit [Quit: Lost terminal]
[19:48:10] -!- r00t4rd3d has quit [Read error: Connection reset by peer]
[19:56:54] <micges> realtime ethernet under linuxcnc:
http://www.youtube.com/watch?v=n6DdWQ25Ur8
[20:02:20] <cradek> cool! did you make a realtime driver for a specific ethernet card?
[20:02:45] <micges> yes 7i08
[20:02:50] <micges> mesa 7i80
[20:03:28] <micges> I mean I used rtnet which has rt driver for my realtek 8139
[20:03:49] <cradek> aha, that's what I was trying to ask
[20:04:02] <micges> it has drivers for few other boards
[20:04:12] <micges> few gigabit boards
[20:04:57] <cradek> this sounds like a nice setup
[20:05:24] <cradek> does it work well? I noticed the gui was very unresponsive in your video. was it just an underpowered motherboard?
[20:06:58] -!- stsy has quit [Quit: Leaving]
[20:09:16] <micges> rtnet misconfiguration
[20:09:43] <micges> some of board irqs are polled
[20:09:59] <micges> working on solution
[20:10:24] <micges> but latency is stable and acceptable
[20:11:18] <cradek> awesome
[20:11:57] <cradek> ethernet is mechanically and electrically better than either parport or fat ribbon cables
[20:12:15] <cradek> a very useful improvement
[20:12:38] <micges> I agree
[20:13:40] <skunkworks> the isolation is awesome.
[20:15:01] <skunkworks> linuxcnc
[20:15:07] -!- markenranosa has quit [Quit: markenranosa]
[20:15:17] <skunkworks> micges: great work!
[20:15:24] <micges> thanks
[20:16:26] -!- theorbtwo has quit [Read error: Connection reset by peer]
[20:17:30] -!- halo_cast has quit [Ping timeout: 264 seconds]
[20:27:46] Cylly is now known as Loetmichel
[20:36:34] -!- vladimirek has quit [Remote host closed the connection]
[20:38:08] -!- mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[20:53:07] -!- rob_h [rob_h!~rob_h@5e04027e.bb.sky.com] has joined #linuxcnc-devel
[21:11:30] -!- zzolo has quit [Quit: zzolo]
[21:13:12] -!- dgarr [dgarr!~dgarrett@75-171-116-61.phnx.qwest.net] has joined #linuxcnc-devel
[21:15:00] <dgarr> bug fix (2.5) for consideration:
http://www.panix.com/~dgarrett/stuff/0001-gremlin.py-define-change_tool-in-class-StatCanon.patch
[21:32:20] -!- bedah has quit [Quit: Ex-Chat]
[21:37:39] <mhaberler> seb_kuzminsky: around?
[21:39:18] <mhaberler> I made a few experiments with the mdi-queue-bugfix branch by varying MDI queue sizes ([TASK]MDI_QUEUED_COMMANDS=n)
[21:40:04] <mhaberler> results for 0 (no MDI q), 1 (exactly 1 cmd) and 100000 (=infinite q size wrt test) are:
[21:40:15] <mhaberler> qs=0: 126 fails
[21:40:24] <mhaberler> qs=1: 126 fails
[21:40:32] <mhaberler> qs=100000: 7 fails
[21:41:29] <mhaberler> the other thing that puzzles me is that even with qs=100000 the actual queue depth never exceeds 5:
http://static.mah.priv.at/public/queuesizes.tiff
[21:42:35] <mhaberler> I would have expected it to either remain 1 (wait_done) or grow rather large as the linuxcncrsh gets ahead of task
[21:43:28] <mhaberler> this leaves me puzzled as for the relation of MDI queueing and this bug; not yet sure what to make of it
[21:43:36] -!- DJ9DJ has quit [Quit: bye]
[21:45:20] -!- peroht has quit [Remote host closed the connection]
[21:59:40] -!- danielfalck [danielfalck!~danielfal@static-50-53-1-104.bvtn.or.frontiernet.net] has joined #linuxcnc-devel
[22:03:31] -!- odogono has quit [Quit: odogono]
[22:06:02] -!- pcw_home has quit [Ping timeout: 255 seconds]
[22:14:07] -!- rob__H [rob__H!~rob_h@5e0473f7.bb.sky.com] has joined #linuxcnc-devel
[22:17:01] -!- rob_h has quit [Ping timeout: 244 seconds]
[22:18:24] -!- plushy has quit [Ping timeout: 256 seconds]
[22:19:20] -!- sumpfralle2 has quit [Read error: Connection reset by peer]
[22:20:02] -!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc-devel
[22:27:32] -!- Blorb has quit [Ping timeout: 245 seconds]
[22:29:05] -!- zlog has quit [Ping timeout: 252 seconds]
[22:29:23] -!- Tom_itx has quit [Ping timeout: 248 seconds]
[22:42:44] -!- V0idExp1 has quit [Quit: Leaving.]
[22:49:14] -!- ink has quit [Read error: Operation timed out]
[22:49:55] -!- Wildhoney has quit [Ping timeout: 260 seconds]
[23:01:43] -!- dgarr has quit [Quit: Leaving.]
[23:06:43] -!- emacsen has quit [Ping timeout: 248 seconds]
[23:08:57] -!- micges has quit [Quit: Leaving]
[23:19:37] -!- Icekiller has quit [Changing host]
[23:25:56] -!- JesusAlos has quit [Quit: ChatZilla 0.9.90 [Firefox 18.0.2/20130201065344]]
[23:36:14] -!- ravenlock has quit [Ping timeout: 252 seconds]
[23:38:34] -!- sumpfralle has quit [Ping timeout: 256 seconds]
[23:48:29] -!- sumpfralle has quit [Ping timeout: 256 seconds]
[23:48:56] -!- micges [micges!~toudi@acwc172.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[23:48:57] -!- sumpfralle1 has quit [Read error: Connection reset by peer]