Back
[00:04:49] -!- patrickarlt has quit [Remote host closed the connection]
[00:11:20] -!- thomaslindstr_m has quit [Quit: Leaving...]
[00:20:02] -!- wboykinm has quit [Ping timeout: 264 seconds]
[00:20:59] <seb_kuzminsky> zultron: since i merged seb/ubc3-deb into ubc, nearly all deb builders should pass
[00:21:24] <seb_kuzminsky> the ones that still fail are: lucid-rtai and precise-rtpreempt-{i386,amd64}
[00:21:49] <seb_kuzminsky> lucid-rtai fails because ubc links liblxrt, and the lucid rtai packages dont provide it correctly for the deb packaging
[00:22:20] <seb_kuzminsky> the precise-rtpreempt ones fail because they dont know where to apt-get the rtpreempt kernel headers (i just snarfed the debs from debian.org by hand)
[00:22:47] <seb_kuzminsky> any failures other than those three are either a regression in the branch or another mole in the buildbot :-/
[00:22:53] <seb_kuzminsky> i have not triaged these failures yet
[00:23:36] -!- rob_h has quit [Ping timeout: 252 seconds]
[00:29:00] -!- ktchk [ktchk!~eddie6929@n219078191117.netvigator.com] has joined #linuxcnc-devel
[00:30:33] <seb_kuzminsky> zultron: i just looked at
http://buildbot.linuxcnc.org/buildbot/builders/deb-lucid-sim-binary-i386/builds/1337
[00:30:52] <seb_kuzminsky> it has my deb fixes in its history, so i'd expect it to succeed
[00:31:36] <seb_kuzminsky> the failure is this:
[00:31:43] <seb_kuzminsky> install -m 0644 -o root ../share/linuxcnc/stepconf/*.glade /tmp/buildd/linuxcnc-2.6.0~pre~unified.build.candidate.3.testmerge.glo~c264b30/src/../debian/tmp/usr/share/linuxcnc/stepconf
[00:31:47] <seb_kuzminsky> install: target `/tmp/buildd/linuxcnc-2.6.0~pre~unified.build.candidate.3.testmerge.glo~c264b30/src/../debian/tmp/usr/share/linuxcnc/stepconf' is not a directory
[00:32:05] <seb_kuzminsky> looks like a problem with the merge of master into that branch maybe?
[00:33:18] <seb_kuzminsky> the commit that failed to build debs is a merge commit, one of the parents is ubc3 which successfully builds debs
[00:34:36] <seb_kuzminsky> the other parent of the merge is a branch i've never seen before, which looks like a branch of michael's, containing a merge of master into and old version of ubc3, plus a couple of new commits
[00:34:51] -!- ktchk has quit [Remote host closed the connection]
[00:35:18] <seb_kuzminsky> so i think something went wrong with either the merge of master into michael's branch, or with the merge of glo/ubc3 into michael's branch
[00:36:35] <seb_kuzminsky> i spot checked a couple of the other deb build failures, they all looked like that stepconf problem
[00:36:43] <seb_kuzminsky> imma wait for mah to fix it
[00:38:59] -!- WalterN has quit [Ping timeout: 240 seconds]
[00:42:43] -!- gonzo_nb has quit [Remote host closed the connection]
[00:59:07] -!- Nick001 has quit []
[00:59:39] -!- exco has quit [Ping timeout: 276 seconds]
[01:09:13] -!- andypugh has quit [Quit: andypugh]
[01:22:20] -!- asdfasd has quit [Ping timeout: 265 seconds]
[01:29:44] -!- CHNCguy has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
[01:33:46] -!- skorasaurus has quit [Ping timeout: 272 seconds]
[01:42:15] -!- exco has quit [Ping timeout: 272 seconds]
[01:42:29] -!- skunkworks [skunkworks!~chatzilla@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[01:42:58] -!- patricka_ has quit [Remote host closed the connection]
[01:44:38] -!- lyzidiamond has quit [Quit: lyzidiamond]
[01:50:38] -!- lyzidiamond has quit [Client Quit]
[01:54:49] <seb_kuzminsky> zultron: i forgot to mention - it's great that he did his test-merge in a throw-away integration branch, this way he can fix it before pushing it to ubc for real
[02:07:32] -!- Servos4ever has quit [Quit: ChatZilla 0.9.90.1 [SeaMonkey 2.23/20131210201646]]
[02:20:51] -!- micges has quit [Quit: Leaving]
[02:22:29] -!- dhoovie has quit [Ping timeout: 246 seconds]
[02:25:28] -!- patrickarlt has quit [Remote host closed the connection]
[02:32:38] -!- almccon has quit [Quit: Leaving.]
[02:32:48] -!- patrickarlt has quit [Remote host closed the connection]
[02:33:09] -!- micges [micges!~captain_p@abpa154.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[02:38:37] -!- patrickarlt has quit [Ping timeout: 272 seconds]
[02:38:53] -!- skorasaurus has quit [Quit: WeeChat 0.4.2]
[02:41:54] -!- reksio1 [reksio1!~captain_p@egi105.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[02:45:25] -!- micges has quit [Ping timeout: 245 seconds]
[02:52:35] -!- patrickarlt has quit [Client Quit]
[03:02:41] -!- reksio1 has quit [Quit: Leaving]
[03:07:59] -!- AR_ has quit [Ping timeout: 240 seconds]
[03:14:23] <skunkworks> cradek: the error on the control is fuse(y). dad says that there is an unpopulated 'fuse' led on the drive. (so the logic must go back to the board) No change in other led's when the control faults.
[03:16:55] -!- Tom_L [Tom_L!~Tl@unaffiliated/toml/x-013812] has joined #linuxcnc-devel
[03:22:32] <skunkworks> the other two drive that look to have newer caps - do have that led.
[03:22:51] <skunkworks> btw - the spindle drive seems to work.
[03:23:32] <skunkworks> the only thing (other than the y axis servo drive issue) is the tool changer doesn't seem to do anything. (from the front panel) but we may just be doing something wrong
[03:24:10] <skunkworks> you can
[03:24:17] <skunkworks> you can't stop it at 100rpm..
[03:24:34] <skunkworks> I didn't try any slower
[03:35:45] -!- skunkworksnook [skunkworksnook!~yaaic@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[03:36:57] -!- skunkworksnook has quit [Remote host closed the connection]
[03:38:21] <zultron> Hi seb_kuzminsky, thanks! So those three you mention are failing with ubc3, plus deb-precise-xenomai-binary-amd64, which says
[03:38:24] <zultron> tar: build/www: Cannot mkdir: No space left on device
[03:38:37] -!- mozmck has quit [Quit: Leaving.]
[03:40:16] -!- mozmck [mozmck!~moses@client-67.210.159.209.dfwtx.partnershipbroadband.com] has joined #linuxcnc-devel
[03:41:10] <zultron> On mine, I'm getting intermittent problems with linuxcncrsh-based tests. You mind taking a quick look at
http://junction.ext.zultron.com/builders/fc20-32-x-tst/builds/52 ?
[03:41:40] <zultron> bbl
[04:06:18] -!- GuShH_ has quit [Read error: Connection reset by peer]
[04:11:14] -!- wboykinm has quit [Remote host closed the connection]
[04:12:53] <zultron> Actually, n/m, I see what's going on. The gcode-output is just like expected output up until the last several lines, which are missing.
[04:13:42] <zultron> So this looks like a race condition: the gcode-output file is compared to the expected-gcode-output file before the former is completely written.
[04:14:29] -!- wboykinm has quit [Remote host closed the connection]
[04:14:56] <zultron> Looking at it on disk, it's actually complete:
[04:14:57] <zultron> $ md5sum tests/toolchanger/toolno-pocket-differ/nonrandom/*gcode-output
[04:14:57] <zultron> 44f37ceb5784108cf9ccfcdd9b1671a0 tests/toolchanger/toolno-pocket-differ/nonrandom/expected-gcode-output
[04:15:00] <zultron> 44f37ceb5784108cf9ccfcdd9b1671a0 tests/toolchanger/toolno-pocket-differ/nonrandom/gcode-output
[04:15:19] <zultron> So there's a race condition.
[04:16:16] <zultron> And apparently a known race condition, since tests/toolchanger/toolno-pocket-differ/shared-test.sh contains these lines:
[04:16:25] <zultron> # give linuxcnc a second to finish
[04:16:28] <zultron> sleep 1.0
[04:16:58] <zultron> [trailing spaces added :P ]
[04:18:21] <seb_kuzminsky> aha, that sucks :-(
[04:18:31] <seb_kuzminsky> clocks and timers in tests are bad :-(
[04:20:09] <zultron> Yeah. Worse, I'm so tired, I'm considering a commit that just raise the 'sleep' cmd argument.
[04:20:25] <zultron> Guess I'd better sleep longer myself, instead. :)
[04:20:33] <seb_kuzminsky> heh
[04:20:49] <seb_kuzminsky> i couldnt figure out a way to close the loop with linuxcncrsh
[04:20:55] <seb_kuzminsky> hence the sleep :-/
[04:21:15] <seb_kuzminsky> there's some wait commands, and i dont remember why they didnt work for me
[04:23:23] <zultron> Hmm. The 'wait' command would wait for the 'linuxcnc' process to finish.
[04:24:01] <zultron> I think that one spawns other processes, though, like linuxcncrsh or linuxcncsvr or the like?
[04:24:27] <zultron> I don't know this stuff well, but there're a few moving parts in there.
[04:35:41] -!- pcw_home has quit [Read error: Connection reset by peer]
[04:44:38] -!- lyzidiamond has quit [Quit: lyzidiamond]
[04:49:32] -!- krusty_ar has quit [Remote host closed the connection]
[04:52:08] -!- terabyte- has quit [Quit: terabyte-]
[04:54:13] -!- _1SheYode has quit []
[05:06:30] -!- Tom_L has quit []
[05:20:25] -!- uw has quit [Ping timeout: 245 seconds]
[05:20:51] -!- Jeebiss has quit [Ping timeout: 272 seconds]
[05:25:33] -!- zumba_addict has quit [Ping timeout: 252 seconds]
[05:25:33] zumba_addict_ is now known as zumba_addict
[05:34:58] -!- uw has quit [Client Quit]
[05:49:44] <memleak> cannot home while shared home directory is closed?
[05:50:11] -!- PetefromTn has quit [Remote host closed the connection]
[05:51:26] -!- davc has quit [Read error: Connection reset by peer]
[05:51:51] -!- terabyte- has quit [Quit: terabyte-]
[05:54:03] -!- pjm_ has quit [Read error: Connection reset by peer]
[06:01:48] -!- Fox_Muldr has quit [Ping timeout: 252 seconds]
[06:02:52] <KGB-linuxcnc> 03John Morris 05zultron/ubc3-dev 50582a1 06linuxcnc 10tests/bitops.0/test.sh tests/bitops.0/test.sh: change include dir to /include from /src/rtapi * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=50582a1
[06:02:52] <KGB-linuxcnc> 03Michael Haberler 05zultron/ubc3-dev ba5ad00 06linuxcnc 10src/rtapi/rtapi_msgd.c msgd: use synchronous signal delivery with signalfd() * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ba5ad00
[06:02:52] <KGB-linuxcnc> 03Michael Haberler 05zultron/ubc3-dev bffa1d9 06linuxcnc 10src/rtapi/rtapi_msgd.c rtapi/msgd: explicitly shut down rtapi_app if exiting * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bffa1d9
[06:02:55] <KGB-linuxcnc> 03John Morris 05zultron/ubc3-dev c52a41f 06linuxcnc 10tests/toolchanger/toolno-pocket-differ/shared-test.sh toolchanger test: make race condition less likely by increasing sleep * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c52a41f
[06:12:47] -!- dhoovie has quit [Ping timeout: 246 seconds]
[06:22:15] -!- Thetawaves has quit [Remote host closed the connection]
[06:40:39] -!- kwallace [kwallace!~kwallace@smb-238.sonnet.com] has joined #linuxcnc-devel
[06:41:40] -!- kwallace2 has quit [Ping timeout: 245 seconds]
[06:54:43] -!- The_Ball has quit [Ping timeout: 245 seconds]
[07:01:55] -!- kwallace [kwallace!~kwallace@smb-238.sonnet.com] has parted #linuxcnc-devel
[07:09:22] <linuxcnc-build> build #38 of deb-precise-xenomai-binary-amd64 is complete: Failure [4failed apt-get-update shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-xenomai-binary-amd64/builds/38 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Michael Haberler <git@mah.priv.at>, John Morris <john@zultron.com>
[07:12:25] <linuxcnc-build> build #38 of deb-precise-rtpreempt-binary-x86 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-rtpreempt-binary-x86/builds/38 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Michael Haberler <git@mah.priv.at>, John Morris <john@zultron.com>
[07:12:38] -!- KimK has quit [Ping timeout: 245 seconds]
[07:12:45] <linuxcnc-build> build #38 of deb-precise-rtpreempt-binary-amd64 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-rtpreempt-binary-amd64/builds/38 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Michael Haberler <git@mah.priv.at>, John Morris <john@zultron.com>
[07:15:35] -!- KimK [KimK!~Kim__@ip24-255-223-153.ks.ks.cox.net] has joined #linuxcnc-devel
[07:20:26] <zultron> Hmm, this time around, same test fails, this time on fc19-32-rtpreempt (last was fc20-32-xenomai).
[07:21:19] <zultron> And this time, there *were* lines missing from the 'gcode-output' file, despite a 5 second sleep; maybe I made a mistake last time.
[07:36:53] -!- archivist_herron has quit [Read error: Operation timed out]
[07:44:39] <seb_kuzminsky> i meant a wait command inside linuxcncrsh
[07:46:33] <seb_kuzminsky> it supposedly accepts 'set wait done', but i dont think i ever got that to work
[08:05:13] <linuxcnc-build> build #1339 of deb-lucid-rt-binary-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-lucid-rt-binary-i386/builds/1339 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Michael Haberler <git@mah.priv.at>, John Morris <john@zultron.com>
[08:06:29] -!- jnaour has quit [Ping timeout: 269 seconds]
[08:08:09] -!- b_b has quit [Changing host]
[08:31:04] -!- GJdan has quit [Quit: WeeChat 0.4.2]
[09:06:29] -!- MrSunshine has quit [Quit: Leaving]
[09:08:06] <memleak> sweeet latency test running for a few hours now with CPU benchmarks running and staying at 40us
[09:08:17] <memleak> preempt_rt now
[09:31:20] -!- dnalerom_ [dnalerom_!~dnaleromj@98.124.126.110] has joined #linuxcnc-devel
[09:32:15] -!- dnalerom_ has quit [Client Quit]
[09:32:37] -!- dnalerom_ [dnalerom_!~dnaleromj@98.124.126.110] has joined #linuxcnc-devel
[09:34:19] -!- rob_h [rob_h!~robh@90.203.219.139] has joined #linuxcnc-devel
[09:36:59] -!- dnalerom_ has quit [Client Quit]
[09:37:53] -!- dnalerom_ [dnalerom_!~dnaleromj@98.124.126.110] has joined #linuxcnc-devel
[09:41:20] -!- dnalerom_ has quit [Client Quit]
[09:41:35] -!- psha[work] [psha[work]!~psha@psha.org.ru] has joined #linuxcnc-devel
[09:41:55] -!- dnalerom_ [dnalerom_!~dnaleromj@98.124.126.110] has joined #linuxcnc-devel
[09:43:15] -!- erictheise has quit [Quit: erictheise]
[10:00:50] -!- archivist_herron has quit [Ping timeout: 264 seconds]
[10:03:44] -!- Thetawaves has quit [Quit: This computer has gone to sleep]
[10:05:55] -!- dnalerom_ has quit [Quit: Dang. Where did dnaleromj's computer go?]
[10:08:05] -!- theorbtwo has quit [Ping timeout: 248 seconds]
[10:11:59] -!- syyl-- has quit [Ping timeout: 240 seconds]
[10:15:33] -!- maximilian_h [maximilian_h!~bonsai@p549DD965.dip0.t-ipconnect.de] has joined #linuxcnc-devel
[10:26:47] -!- b_b has quit [Changing host]
[10:31:05] -!- sumpfralle has quit [Ping timeout: 252 seconds]
[10:34:19] -!- kludge` has quit [Ping timeout: 260 seconds]
[11:28:16] -!- skunkworks has quit [Remote host closed the connection]
[11:43:16] sirdancealot is now known as eoctopus
[11:48:05] -!- fomox_ has quit [Ping timeout: 272 seconds]
[11:55:33] -!- skunkworks [skunkworks!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[12:15:13] -!- maximilian_h1 [maximilian_h1!~bonsai@p549DE108.dip0.t-ipconnect.de] has joined #linuxcnc-devel
[12:16:19] -!- maximilian_h has quit [Ping timeout: 252 seconds]
[12:37:03] -!- fomox_ has quit [Read error: Connection reset by peer]
[12:53:52] -!- zumba_addict has quit [Quit: zumba_addict]
[13:04:13] -!- maximilian_h1 has quit [Quit: Leaving.]
[13:09:47] -!- sumpfralle has quit [Ping timeout: 272 seconds]
[13:11:03] -!- fomox__ has quit [Ping timeout: 272 seconds]
[13:25:21] -!- md-2 has quit [Remote host closed the connection]
[13:29:59] -!- md-2 has quit [Ping timeout: 240 seconds]
[13:32:29] -!- krusty_ar has quit [Ping timeout: 240 seconds]
[13:42:26] -!- PetefromTn [PetefromTn!~quassel@75-136-192-114.dhcp.kgpt.tn.charter.com] has joined #linuxcnc-devel
[13:56:29] -!- wboykinm has quit [Remote host closed the connection]
[13:59:39] -!- wboykinm has quit [Read error: No route to host]
[14:04:43] -!- wboykinm has quit [Ping timeout: 245 seconds]
[14:10:19] -!- Valen has quit [Quit: Leaving.]
[14:12:22] <skunkworks> PCW,
http://imagebin.org/289943
[14:12:33] <skunkworks> that is on the old atom
[14:13:45] <skunkworks> seems to peak at 200k writes - 500k reads
[14:20:21] -!- sulky has quit [Read error: Operation timed out]
[14:22:29] -!- likewhoa has quit [Ping timeout: 248 seconds]
[14:22:38] -!- bietieka1 has quit [Ping timeout: 252 seconds]
[14:23:42] -!- uwe_mobile__ has quit [Ping timeout: 276 seconds]
[14:37:19] <skunkworks> I switched over to a asus/amd motherboard. It locks up with the delays remarked out. Really crappy read times also.
[14:40:12] -!- PetefromTn has quit [Read error: Connection reset by peer]
[14:42:43] -!- StepanKuzmin has quit [Ping timeout: 245 seconds]
[14:46:16] -!- PetefromTn [PetefromTn!~quassel@75-136-192-114.dhcp.kgpt.tn.charter.com] has joined #linuxcnc-devel
[14:53:25] -!- chillly has quit [Remote host closed the connection]
[14:56:39] -!- zzolo has quit [Quit: zzolo]
[14:59:49] -!- zzolo has quit [Client Quit]
[15:16:12] <skunkworks> that hardware doesn't play nice.
[15:16:28] -!- micges [micges!~captain_p@egi105.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[15:16:30] <skunkworks> the servo thread is taking over 1ms
[15:17:20] <skunkworks> latency runs good though... Put in a pro 100 card and still get long servo thread times
[15:20:09] -!- patrickarlt has quit [Remote host closed the connection]
[15:23:34] <micges> skunkworks: those times are in cycles, what cpu Hz is this?
[15:25:00] -!- patrickarlt has quit [Ping timeout: 245 seconds]
[15:28:12] <linuxcnc-build> build #39 of deb-precise-xenomai-binary-amd64 is complete: Failure [4failed apt-get-update shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-xenomai-binary-amd64/builds/39 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Michael Haberler <git@mah.priv.at>, John Morris <john@zultron.com>
[15:32:21] <skunkworks> oh - really?
[15:32:41] <skunkworks> I was wondering why I wasn't getting realtime errors when linuxcnc was running...
[15:33:36] -!- Swapper_ has quit [Client Quit]
[15:33:38] <micges> yeah me too so I checked
[15:35:03] <micges> so if you have 2GHz then 1M cycles is about 50% so not so bad
[15:35:11] <micges> but could be better :)
[15:36:07] -!- zumba_addict has quit [Quit: zumba_addict]
[15:37:24] <skunkworks> no - the on this system (different intel base) the read time is taking 1.2 ms (if it is in ms?)
[15:38:39] <skunkworks> micges, are you saying this is not ns?
http://imagebin.org/289943
[15:38:58] <skunkworks> (511us)
[15:42:13] <micges> yes I'm sure those are cpu clocks
[15:43:37] <skunkworks> huh
[15:45:42] <skunkworks> so a 2.4 ghz machiene with at read time averaging about 1200000?
[15:47:09] <micges> 500us
[15:47:29] <skunkworks> huh
[15:48:17] <skunkworks> I think i have had this problem before... :)
[15:48:40] <micges> hold on
[15:50:10] <skunkworks> well - it has to be something odd - as linuxcnc is not throwing a reatime delay error.. And if it was in ns - it is way over 1ms..
[15:53:42] <skunkworks> but the writes are taking 18000 whatevers
[15:59:01] -!- Komzzzpa has quit [Read error: Operation timed out]
[15:59:18] -!- patrickarlt has quit [Remote host closed the connection]
[16:01:32] <micges> if my calcs are ok your read function took 50us not 500us
[16:02:22] <micges> and write took 1us
[16:05:48] <skunkworks> wow
[16:06:41] <micges> I will double check it, seems that we all missed that those are cycles not ns
[16:07:09] eoctopus is now known as sirdancealot
[16:07:41] -!- Loetmichel has quit [Ping timeout: 252 seconds]
[16:08:36] <skunkworks> so 511800 on a 1.8ghz?
[16:12:22] -!- kwallace [kwallace!~kwallace@smb-118.sonnet.com] has joined #linuxcnc-devel
[16:12:40] -!- sumpfralle has quit [Client Quit]
[16:13:31] <seb_kuzminsky> nginx includes 4-star code:
https://github.com/nginx/nginx/blob/master/src/core/ngx_cycle.h#L38
[16:13:53] -!- chillly has quit [Quit: Leaving]
[16:14:06] <micges> haha
[16:16:51] <skunkworks> I get 500us if I calculated right?
[16:17:21] <cradek> that it's void**** is extra funny
[16:18:01] <skunkworks> cradek - up for 15 minutes so far - dad found 2 open resistors..
[16:18:10] <skunkworks> on the drives
[16:18:13] <skunkworks> *drive
[16:20:07] <cradek> skunkworks: yay!
[16:24:35] -!- dhoovie has quit [Ping timeout: 246 seconds]
[16:27:15] <micges> skunkworks: correct again, on 1GHz cpu 500k cycle would be 500ns, so on 1,8 GHz cpu it will be about 300us
[16:27:48] <micges> and 18000 on 1,8GHz would be about 10us
[16:28:24] <micges> (I'm sick and seems that drugs removed my basic math skills,,,)
[16:28:33] <micges> time to rest, bbl
[16:29:03] -!- micges has quit [Quit: Leaving]
[16:33:30] <skunkworks> heh
[16:39:41] -!- mozmck has quit [Read error: Connection reset by peer]
[16:41:08] -!- mozmck [mozmck!~moses@client-67.210.159.209.dfwtx.partnershipbroadband.com] has joined #linuxcnc-devel
[16:44:40] -!- psha[work] has quit [Quit: Lost terminal]
[16:47:38] -!- exco has quit [Ping timeout: 264 seconds]
[16:52:21] -!- ju-emb has quit [Ping timeout: 272 seconds]
[16:57:29] <cradek> have any of you tried the wheezy live cd?
[16:58:23] <cradek> I'd prefer for us to be able to use wheezy instead of precise for our next cd, but we really should not give up the live feature
[17:03:11] <seb_kuzminsky> i've used the wheezy netinst usb image to install, but not as a live system
[17:03:15] <seb_kuzminsky> and i havent tried to customize it
[17:04:54] <cradek> I'm about to install the rtai kernel (from our precise/base repo) on wheezy and see what happens
[17:07:30] -!- thomaslindstr_m has quit [Remote host closed the connection]
[17:08:36] <cradek> well if the install ever finishes
[17:08:44] <seb_kuzminsky> a person named Birchy reported in private email to me that our rtai kernel deb installs and runs fine on wheezy, and gives good latency
[17:08:51] <cradek> the ubuntu install-from-live is sure fast
[17:09:03] <cradek> that's good to hear
[17:09:18] <seb_kuzminsky> i guess we should put the rtai debs in the new wheezy dist in our repo too, if it works
[17:09:31] <cradek> I'll let you know my results today
[17:09:35] <seb_kuzminsky> cool
[17:09:46] <cradek> well, on one piece of hardware, anyway
[17:12:30] -!- thomaslindstr_m has quit [Ping timeout: 245 seconds]
[17:16:52] -!- akex has quit [Remote host closed the connection]
[17:18:46] <skunkworks> ok - so to double check - the time, max, max-time is in clock cycles?
[17:19:53] <cradek> huh, my new install doesn't boot
[17:20:02] <skunkworks> yeck
[17:20:30] <cradek> in grub I can see it installed 3.2.0-something-pae, but all I get is a blinking cursor when it boots that
[17:21:43] <skunkworks> PCW, what did you end up with for pid on your config?
[17:23:23] -!- dhoovie has quit [Ping timeout: 246 seconds]
[17:25:15] <cradek> aha, turning ACPI on in the bios fixed it (it was hanging at PnP probe)
[17:28:04] -!- pcw_home [pcw_home!~chatzilla@c-50-174-121-10.hsd1.ca.comcast.net] has joined #linuxcnc-devel
[17:29:10] -!- mackerski has quit [Read error: Operation timed out]
[17:37:20] -!- b_b has quit [Changing host]
[17:40:51] <skunkworks> pcw_home, Hey.. Did you know that time and timemax was clock cycles? I didn't
[17:41:15] <skunkworks> it just happend to be on my atom board it was 'close' to actual ns...
[17:45:56] <skunkworks> pcw_home, this didn't make sense..
http://imagebin.org/289976
[17:46:08] <cradek> the rtai kernel from precise/base boots, but the linuxcnc debs from buildbot/precise/master-rt will not install
[17:46:52] <skunkworks> 1272924 was way more than a 1ms base period but I was not getting any realtime errors.
[17:49:12] <skunkworks> but if I did my math right - that is 530us on a 2.8ghz machine
[17:49:47] <skunkworks> cradek, you need to give us more information if we are going to help you... ;)
[17:50:24] <seb_kuzminsky> lol @ skunkworks
[17:50:26] <cradek> well they weren't meant to, I just thought I might get lucky
[17:50:54] <cradek> incompatible boost-python version and libc6 version
[17:50:59] <seb_kuzminsky> cradek: like thsi?
https://www.youtube.com/watch?v=5NV6Rdv1a3I
[17:51:31] <skunkworks> heh - those french!
[17:54:56] -!- Jymmm has quit [Remote host closed the connection]
[17:54:59] -!- dway has quit [Quit: NOOOOOOooooooooo……]
[17:55:33] <pcw_home> I dont know that so that things quite a bit better
[17:55:35] <pcw_home> I also think there maybe two read cycles that can be combined
[17:55:36] <pcw_home> (if this is the case the read times can be almost halved)
[17:55:54] -!- ju-emb [ju-emb!~jgnoss@190.222.141.243] has joined #linuxcnc-devel
[17:57:03] -!- Jeebiss has quit [Ping timeout: 272 seconds]
[17:58:37] <pcw_home> ( and those numbers match the ping numbers if the CPU clock speed is factored in)
[17:59:02] <skunkworks> I think I ran into that problem before - ns vs clock cycles.. (I had assumed it was ns...) I can not find a reference to it in the docs.
[17:59:53] <skunkworks> the write times are really low then :)
[18:00:01] <pcw_home> seems like a public parameter like read time should be in ns
[18:00:22] <pcw_home> (just one FP scale op)
[18:02:01] -!- ju-emb has quit [Quit: ju-emb]
[18:03:38] -!- dnaleromj [dnaleromj!~dnaleromj@64.20.30.66] has joined #linuxcnc-devel
[18:04:25] Cylly is now known as Loetmichel
[18:04:47] <skunkworks> could you do it in hal? or can't you hook parameters to say a scale componant
[18:06:48] <pcw_home> I always thought you could not 'net' parameters but I could be wrong
[18:07:02] <skunkworks> that is my feeling
[18:07:42] <skunkworks> pcw_home, what did you end up with for pidff settings?
[18:08:03] -!- syyl- has quit [Ping timeout: 245 seconds]
[18:08:14] <pcw_home> FF1=1.000 FF2=0 P=50
[18:08:18] -!- md-2 has quit [Quit: Leaving...]
[18:08:42] <pcw_home> (pix maxerror = .0003 or something)
[18:08:53] <skunkworks> ok. those give me following errors at anything above 50ipm
[18:08:56] <pcw_home> s/pix/pid/
[18:10:53] <pcw_home> you may have to adjust FF1 a tiny amount
[18:10:54] <pcw_home> you also need to set pid.X.error-previous-target true
[18:14:28] <skunkworks> error-previous target is set t true. I will play with ff1
[18:15:11] <pcw_home> you may need to look at a plot so see what going on
[18:15:45] <skunkworks> sure - what do you usually look at?
[18:17:04] <pcw_home> ferror when jogging
[18:17:10] <skunkworks> are you saying pid max error is .0003 or following error?
[18:17:44] <skunkworks> pid max erorr is 0
[18:18:42] <skunkworks> never mind - it is set to .0005
[18:20:53] -!- krusty_ar has quit [Ping timeout: 248 seconds]
[18:27:26] <pcw_home> Until the DPLL is used for read sampling you will need to set the ferror to maxvel * max jitter
[18:29:27] -!- micges [micges!~captain_p@egi105.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[18:31:12] <pcw_home> Hmm thats interesting max jog speed is set to 60 IPM but i can jog at full speed (1200 IPM) with the axis buttons
[18:33:29] <seb_kuzminsky> the cycles-vs-ns confusion in thread and function runtime reporting has bitten me too occasionally
[18:34:15] <seb_kuzminsky> after 78919de4a1c5ef9e495dc25ae27f43ff1e54b7e0, should we switch it to report ns instead?
[18:34:21] <skunkworks> pcw_home, you have the feed rate override set to 3000%
[18:34:35] <skunkworks> or whatever your config is set to.
[18:35:32] <pcw_home> ahh didn't now that affects jogging as well
[18:36:32] <skunkworks> So - I get an error of .012
http://imagebin.org/289981
[18:36:43] <skunkworks> jogging x to 1200 ipm
[18:37:18] <skunkworks> with p=50 ff1=1
[18:37:38] <skunkworks> god - linuxcnc is cool
[18:37:49] <pcw_home> looks like your FF1 needs adjustment (servo thread period off)
[18:38:05] <skunkworks> so - like 1.0001 and see?
[18:38:28] <pcw_home> if you plot the velocity also its easier to see
[18:38:47] <micges> seb_kuzminsky: yes I think we should try to have all possible in ns
[18:38:52] <pcw_home> calibrate make this easy
[18:41:03] -!- skorasaurus has quit [Ping timeout: 260 seconds]
[18:43:03] <pcw_home> skunkworks: just like tuning a velocity mode servo
[18:43:05] <pcw_home> (though FF1 of 1.000 worked for me , you may have a significant time base error in your servo thread)
[18:43:53] -!- mle has quit [Ping timeout: 245 seconds]
[18:48:21] <pcw_home> stepgen at 1200 IPM:
[18:48:22] <pcw_home> http://imagebin.ca/v/1AdtzsuVn5Il
[18:49:09] -!- krusty_ar_ has quit [Ping timeout: 248 seconds]
[18:53:38] <pcw_home> Note that the jitter causes apparent ferrors proportional to the jitter times the velocity
[18:53:39] <pcw_home> Actual errors will be much smaller due to the fact that the control system is
[18:53:41] <pcw_home> almost a perfect velocity mode servo so 99.99% of control is FF1
[18:53:42] -!- dnaleromj has quit [Read error: Connection reset by peer]
[18:54:21] <pcw_home> (and corrections via the P term are limited by the max error term)
[18:58:38] <skunkworks> this is what I get just strait p and ff1
http://imagebin.org/289986
[18:59:12] <skunkworks> (50 and1_
[18:59:56] <skunkworks> doesn't that look funky?
[19:01:01] <pcw_home> look like you need more FF1
[19:01:16] <pcw_home> (or less actually)
[19:02:15] <pcw_home> thats does show the correcction slew rate limiting nicely
[19:03:02] <pcw_home> (and linear to exponential when you get below the PID maxerror limit)
[19:04:29] <cradek> looks like you're accelerating about twice as fast as the stepgen can
[19:05:10] <pcw_home> Pretty sure he just needs to reduce FF1 a bit (timebase difference)
[19:05:31] <skunkworks> if I decrease the ff1 to .999 the first spike gets larger the second spike gets smaller
[19:06:25] <skunkworks> that error is about .003"
[19:06:35] <pcw_home> Is ff2 0?
[19:06:41] <skunkworks> yes
[19:06:57] <pcw_home> very strange
[19:07:25] <pcw_home> you saw my plot, FF1=1 FF2=0 P=50
[19:09:05] <skunkworks> this is with .999 ff1
http://imagebin.org/289989
[19:09:50] <skunkworks> I also checked hal to make sure ff2 was 0
[19:14:34] <skunkworks> cradek, I increased the stepgen acc headroom to 500 from 360 - no real change - the axis is set to 300in/sec/sec
[19:15:11] <pcw_home> try freeby.mesanet.com/7i76e.zip
[19:15:12] <pcw_home> (you will have to change the card name/ip address/mac address)
[19:15:28] <pcw_home> thats what i have thats working
[19:16:02] <pcw_home> (with unchanged ubc3-7i80)
[19:16:24] <skunkworks> is that the right url?
[19:16:54] <pcw_home> Im suspicious of removing the rtapi delay since its has such profound effects
[19:17:23] <skunkworks> pcw_home, I had to put the delays back in - they locked up a computer I was testing
[19:17:48] <skunkworks> got it
[19:18:08] <pcw_home> thats the problem i had as well
[19:18:48] -!- MarkusBec has quit [Ping timeout: 276 seconds]
[19:20:00] -!- krusty_ar has quit [Ping timeout: 245 seconds]
[19:23:13] <pcw_home> on the previous ubc-7i80 version (that you had the watchdog issues with)
[19:23:15] <pcw_home> I had to add FF2 = servo period I think this was because he ended up using the
[19:23:16] <pcw_home> previous cycles read data. Look like you have a related problem (or a ini/hal file difference)
[19:23:24] -!- gambakufu has quit [Ping timeout: 252 seconds]
[19:26:07] <skunkworks> well - I get the same trace
[19:26:38] <skunkworks> spikes to about .003ish"
[19:27:34] <pcw_home> sounds like late data
[19:27:42] <pcw_home> 1 cycle late
[19:27:59] <skunkworks> so the driver might still be reading late?
[19:28:25] <pcw_home> sure looks like it
[19:28:52] <skunkworks> let me put this back on the atom.. for grins.. I thought that worked better.
[19:31:17] -!- krusty_ar has quit [Ping timeout: 248 seconds]
[19:31:52] <pcw_home> you can probably partially fix it with FF2 but the fact that theres a difference
[19:31:54] <pcw_home> (with identical ini/hal files) indicates a problem
[19:36:46] -!- syyl has quit [Read error: Connection reset by peer]
[19:37:42] <pcw_home> I added a tiny bit of FF2 on mine (.00012) I think this corrects for the
[19:37:44] <pcw_home> fact that the updated velocity is always a bit late so you might try that
[19:38:10] <pcw_home> (maybe yours is slower)
[19:39:36] -!- patrickarlt has quit [Remote host closed the connection]
[19:40:00] -!- krusty_ar has quit [Ping timeout: 245 seconds]
[19:40:06] <pcw_home> it may just be that you need a bit of FF2
[19:41:48] <pcw_home> so maybe nothing really wrong
[19:44:04] -!- mozmck has quit [Read error: Connection reset by peer]
[19:46:29] -!- mozmck [mozmck!~moses@client-67.210.159.209.dfwtx.partnershipbroadband.com] has joined #linuxcnc-devel
[19:51:30] <skunkworks> pcw_home,
http://imagebin.org/289991
[19:51:46] <skunkworks> same computer
[19:53:14] <micges> pcw_home: probably delay should be left in but decreased to let say 2us
[19:53:15] <pcw_home> ahh network must be a bit slower than mine
[19:53:52] <pcw_home> I think i tried 1 usec but it locked up
[19:54:12] <micges> oh
[19:55:10] <pcw_home> There seems to be trouble with logging, skunkworks: did you find a fix
[19:55:15] <pcw_home> ?
[19:55:31] <pcw_home> I only see the watchdog I/O in the log
[19:55:43] -!- thomaslindstr_m has quit [Remote host closed the connection]
[19:55:58] <skunkworks> pcw_home,
http://imagebin.org/289991
[19:55:58] <micges> do you have latest source from git?
[19:56:07] <skunkworks> same computer
[19:56:22] <skunkworks> just added ff2 to .00025
[19:56:33] <pcw_home> so its ok just needs a bit of FF2
[19:56:48] <pcw_home> Yes from this morning
[19:57:02] <pcw_home> (git pull from this morning)
[19:57:14] <skunkworks> I am running from yesterday morning - Should I update?
[19:57:38] <pcw_home> I just have trouble with the log
[19:58:18] <micges> skunkworks: no
[19:58:26] <skunkworks> ok
[19:58:39] <micges> pcw_home: you have debug=1 in loadrt line?
[19:59:08] <skunkworks> oh - pcw_home what trouble are you having with log?
[19:59:40] <pcw_home> Yes debug=1, logging works but I think its dropped data
[20:00:32] -!- MarkusBec [MarkusBec!znc@80.69.39.131] has joined #linuxcnc-devel
[20:06:00] <cradek> http://timeguy.com/cradek-files/emc/wheezy-rtai.png
[20:06:18] <cradek> I built and installed a master deb, and it all works
[20:08:36] <pcw_home> despite mhaberlers reservations about preemt_rt/kernel networking,
[20:08:38] <pcw_home> it actually seems usable. I have not seen any big delays at all despite a
[20:08:39] <pcw_home> month of uptime
[20:09:37] <pcw_home> Thats great latency! (and here we are figuring out how to live with 300 usec latencies)
[20:11:06] <cradek> well it's rtai...
[20:11:13] <skunkworks> and it isn
[20:11:28] * cradek hands skunkworks a '
[20:11:35] <skunkworks> and it isn't 300us latencies.. It is network read/write times I think
[20:11:54] <skunkworks> cradek, that is very nice!
[20:12:06] -!- krusty_ar has quit [Read error: Connection reset by peer]
[20:12:20] <skunkworks> the latency test seems to stay under 100us
[20:12:59] <skunkworks> cradek, what hardware?
[20:13:21] <pcw_home> Well i have peaks of 500 usec or so from a a baseline 200 usec network read time
[20:13:23] <pcw_home> Preemt_rt thread latencies are about 80 usec worst case on this machine
[20:13:47] <cradek> skunkworks: a weird slightly old server-class motherboard
[20:13:55] <cradek> skunkworks: model name: Pentium(R) Dual-Core CPU E6600 @ 3.06GHz
[20:14:03] <skunkworks> nice
[20:14:05] <cradek> it reports this, but it's nonsense if you look up what an E6600 is
[20:14:13] <cradek> so I don't really know what it is
[20:14:37] <cradek> it has two e1000s, and serial and parallel ports on the motherboard, so that makes me happy
[20:14:53] <skunkworks> nice
[20:15:36] <skunkworks> so how hard to make a livecd?
[20:16:03] <cradek> I don't know
[20:16:39] <cradek> probably similar to but not quite as weird as ubuntu (that's the summary of all my experiences with debian wheezy)
[20:18:08] <skunkworks> heh
[20:19:51] -!- skorasaurus has quit [Ping timeout: 252 seconds]
[20:20:05] <skunkworks> how long is weezy life?
[20:25:13] -!- PetefromTn has quit [Remote host closed the connection]
[20:34:59] <cradek> I can't seem to find that information
[20:35:11] <cradek> I think it's as long as the ubuntu LTS (and was more recently released)
[20:38:01] <cradek> > The security team tries to support a stable distribution for about one year after the next stable distribution has been released, except when another stable distribution is released within this year.
[20:38:41] <skunkworks> pcw_home, with the ff2 set to .00025 it has been running through the splash screen
[20:40:26] <cradek> skunkworks: so probably until early to mid 2016
[20:40:44] <skunkworks> wow - nice
[20:41:11] <cradek> so only 3-3.5 years, when ubuntu supposedly guaranteed 5, except that was always a lie
[20:41:57] -!- mle has quit [Ping timeout: 252 seconds]
[20:42:00] <cradek> really 5 is too long. new hardware always stops things working in that much time.
[20:43:03] <skunkworks> cradek, is the hardware you are testing near you - or is it off in some distant location?
[20:43:21] <skunkworks> (can you actually touch it)
[20:43:28] <cradek> it's behind me
[20:43:31] <skunkworks> ok
[20:43:52] <cradek> it's up to 7k now that the screen has powered off and on
[20:44:09] <pcw_home> skunkworks: yeah I suspect it is useable as-is on some hardware and with jitter tolerant tuning
[20:44:10] <pcw_home> (a 1 KHz velocity mode servo should be OK as well)
[20:44:54] <skunkworks> pcw_home, if the readtimes can be cut in half - then 2khz servo threads should maybe be possible
[20:47:34] <pcw_home> 2KHz works on this machine (until I I watch a flash video)
[20:47:50] <skunkworks> that was pretty cool - adding just a bit of ff2 I could see the spikes slowly get smaller
[20:48:28] <skunkworks> on the k&t it seemed like I was just flailing around ;)
[20:49:07] <skunkworks> pcw_home, does it throw a real time delay?
[20:50:11] <pcw_home> Yes, or sserial gets a "hey I haven't finished the last transaction" error
[20:51:08] <skunkworks> well - the few systems I have had this on - no realtime delayse
[20:51:17] <skunkworks> delays
[20:51:54] <pcw_home> a real machine is much more complex than the stepgen (since its an ideal velocity mode device, no delays or inertia)
[20:51:56] <pcw_home> so tuning is more involved
[20:52:17] <skunkworks> right
[20:52:33] -!- andypugh [andypugh!~andy2@cpc14-basl11-2-0-cust436.20-1.cable.virginm.net] has joined #linuxcnc-devel
[20:52:36] <skunkworks> it is all in the digital world..
[20:52:46] <skunkworks> andypugh, My 7i80 works!
[20:53:15] <andypugh> I thought it always did?
[20:53:37] <skunkworks> andypugh, my 7i80 now works with linuxcnc!
[20:53:47] <andypugh> I thought it always did?
[20:54:15] <skunkworks> no - there was an issue with the 7i80 and the watchdog with rt_preempt
[20:54:54] <skunkworks> I had it working with rtnet - but that was even more of a pain
[20:54:54] <pcw_home> micges fixed the bug
[20:55:23] <pcw_home> thats the thing with preemt_rt, simple but slow
[20:55:38] <skunkworks> pcw_home, how much is involved with getting it down to 1 read?
[20:55:58] -!- dnaleromj [dnaleromj!~dnaleromj@64.20.30.66] has joined #linuxcnc-devel
[20:56:02] -!- patrickarlt has quit [Read error: Connection reset by peer]
[20:56:19] <pcw_home> Not sure
[20:56:23] <pcw_home> bbl
[20:58:12] <micges> skunkworks: I'll add eeror checking today and I'll test some more on 7i76e with stepgen and encoder, then I'll check what can we do to down to one read per cycle
[20:58:40] <skunkworks> micges, awesome.
[21:09:48] <skunkworks> bbl
[21:09:52] -!- skunkworks has quit [Quit: Leaving]
[21:11:48] -!- asdfasd has quit [Ping timeout: 245 seconds]
[21:17:03] -!- mhaberler [mhaberler!~mhaberler@h081217197121.dyn.cm.kabsi.at] has joined #linuxcnc-devel
[21:20:00] -!- skorasaurus has quit [Ping timeout: 245 seconds]
[21:20:07] <micges> mhaberler: hi
[21:20:15] <mhaberler> hi micges
[21:20:55] <mhaberler> only found this mmap'd packet ring stuff today, looks promising - read _without_ a syscall seems possible
[21:21:39] -!- terabyte- has quit [Read error: Connection reset by peer]
[21:22:44] <micges> we will see how much 'faster' we need after I'll get down to 1 eth read per cycle
[21:22:53] <micges> now it's 2 reads
[21:23:42] <micges> I'm getting to it now
[21:25:13] <micges> this 'worst case udp' doc is very interesting
[21:26:12] <PCW> for 1K servo thread its seems usable now (with jitter tolerant configs) DPLL will help here also
[21:26:33] <mhaberler> I played a bit with ftrace and it's pretty easy to see where time gets lost; it's more a filtering exercise
[21:27:06] <mhaberler> that might be easier with a standalone minimal program instead of all of RTAPI, rtapi_app ff
[21:27:24] <PCW> yeah going through the whole network stack is quite a maze
[21:28:11] <mhaberler> putting rtapi_app under ftrace will create 130dB+ noise
[21:28:39] <mhaberler> well maybe not if just 1 thread running
[21:29:23] <mhaberler> I'm wary the servo cycle time window is getting a bit cramped with these time lags
[21:30:58] <PCW> 1KHz seem fine as is and when we get to one read there's plenty of headroom
[21:31:06] -!- asdfasd1 has quit [Read error: Connection reset by peer]
[21:31:51] -!- lyzidiamond has quit [Quit: lyzidiamond]
[21:32:02] <PCW> but something faster would be needed for torque loops and higher performance machines
[21:34:48] -!- t0x1c has quit [Ping timeout: 245 seconds]
[21:35:07] <PCW> and theres still the possibility of going to a 2 packet system (only one read one write per cycle versus current 3 packet system)
[21:36:31] <mhaberler> why two reads? does the 7i80 send 2 frames?
[21:37:14] -!- zzolo has quit [Quit: zzolo]
[21:38:36] <micges> wd is checked in separate packet atm
[21:39:11] <mhaberler> ah
[21:39:33] <mhaberler> any chance to piggyback wd on every turnaround?
[21:39:40] <PCW> because wd was always a separate function
[21:40:18] <mhaberler> is that a spontanous packet by the 7i80 or is that a reply to a request?
[21:40:53] -!- asdfasd has quit [Ping timeout: 248 seconds]
[21:41:02] <PCW> the 7I80 is a pure slave, no spontaneous packets
[21:41:25] <PCW> (well except for bootp)
[21:41:28] <mhaberler> ah; it's been a while since I read the proto spec
[21:41:31] <mhaberler> sure ;)
[21:41:57] <mhaberler> I hope we can drag Nicholas McGuire into advising on this, he really knows the pitfalls well
[21:42:50] <mhaberler> does the wd checking thread to be in the servo cycle? I think that could be farmed out
[21:43:17] <PCW> we normally only have a servo thread
[21:44:17] <mhaberler> sure. The response should be pretty instantaneous, but technically there's no reason this couldnt be in a plain non-rt thread even
[21:44:53] <mhaberler> I'm not suggesting its a good idea; it might just not be needed to add to the servo cycle time budget
[21:45:41] <PCW> the wd stuff just needs to get included in the one packet en-queuing
[21:45:43] <PCW> (hopefully without impacting the hal file separate WD function syntax)
[21:45:44] <mhaberler> normal and wd replies use the same udp port I assume?
[21:46:06] <mhaberler> anyway to direct the wd reply to a different port?
[21:46:26] <mhaberler> then the wd read could be handled by another thread than servo
[21:46:39] <PCW> Yes they just need to get merged (since the per packet overhead is large but the per data item overhead is small)
[21:46:57] <mhaberler> so you do that on the firmware side?
[21:48:05] <PCW> no, the driver juts needs to merge the watchdog I/O with the rest
[21:48:11] <PCW> just
[21:48:36] <mhaberler> the driver.. hm2_eth.c I assume?
[21:48:45] <PCW> yes
[21:48:47] <mhaberler> not down the stack, right
[21:48:48] <mhaberler> ah
[21:49:17] <mhaberler> it's interesting to see the EtherCAT round trip times; that's almost an order faster
[21:49:25] <PCW> its just a historical accident tha the WD had its own function
[21:49:29] <mhaberler> aja
[21:50:05] -!- patrickarlt has quit [Read error: Connection reset by peer]
[21:50:09] <PCW> well if you write a driver for specific hardware, low latency is easy
[21:51:36] <micges> hmm
[21:51:54] <micges> I've merged wd into tram packet
[21:52:07] <micges> now I have 200k cycles read time
[21:52:08] <mhaberler> well if testing the mmap/ring method still shows this high times that would certainly point to the driver; but an ftrace should give pretty exact time lags from syscall to packet enqueue and from packet in to read complete
[21:52:38] <micges> on 2.8GHz
[21:52:48] <PCW> Im pretty sure it not the driver but kernel getting in the way
[21:53:07] <mhaberler> I'm away from hardware but the packet-tx-ring.c etc codes compiled and seemed to at least start (vbox)
[21:53:21] <PCW> (in the cases that work) Some drivers are hopeless
[21:54:00] <micges> that's ~70us
[21:54:06] <PCW> micges thats great!
[21:54:11] <mhaberler> right, the net stack does all sorts of non-deterministic stuff; Nicholas says the showstopper is everyting which needs memory allocation, and there's a lot of that going on (skbufs etc)
[21:54:20] <mhaberler> ha
[21:55:12] <micges> 40k cycles write time
[21:55:18] <mhaberler> well if we can shave off some of that by raw sockets etc it might even mean higher servo rates are possible
[21:55:28] <micges> that's 15us
[21:56:05] <mhaberler> very good already!
[21:56:09] <PCW> it may be the the current large delay spikes are memory allocation related
[21:56:15] <mhaberler> yes
[21:56:27] <PCW> but still OK at 1 KHz
[21:56:28] <mhaberler> that was his point - looks great most of the time, then - dang
[21:57:02] <PCW> well Ive beat on this pretty hard for a month or so and have no had any OOps
[21:57:36] <PCW> but obviously could be better
[21:57:41] <mhaberler> like 'unexpected rt delay' you mean?
[21:58:10] <PCW> yes (or sserial not complete errors)
[21:58:51] <mhaberler> still.. downstream more complex kins might stress the servo budget again; maybe one should test with a non-trivkins setup
[21:59:46] <mhaberler> actually it occors to me ftrace could well be used to instrument motion (at least kthreads)
[22:01:06] -!- skorasaurus has quit [Ping timeout: 265 seconds]
[22:01:08] <micges> there is some room in driver to speed it up
[22:01:26] <micges> but it should be as fast as possible
[22:01:27] <mhaberler> the nice part about ftrace is - very low overhead if not used
[22:01:42] <mhaberler> anyway, thats a different theme
[22:02:24] <seb_kuzminsky> jepler: are you around?
[22:03:15] <micges> finally times are more sane now, I'll push changes later into ubc3-7i80
[22:05:37] <PCW> Great!
[22:07:19] <PCW> I think there's still a name bug in 7i76e pin names (two dots together)
[22:08:19] <micges> with sserial - yes there is
[22:08:50] -!- wboykinm has quit [Remote host closed the connection]
[22:09:03] <PCW> ahh that right its s sserial bug with longer than 4 char names
[22:10:12] <mhaberler> I just read up on this ring/mmap code. It seems even the tx side does not push down the frame through skbufs in the sendto(); what it does is actually notify the kernerl of a ringbuffer address containing a valid packet, meaning skbufs are not involved, this seems to go directly to the driver thereafter
[22:10:26] -!- mle has quit [Ping timeout: 264 seconds]
[22:11:38] <mhaberler> it does actually send packets on vbox, so this might be a viable route
[22:11:45] -!- afiber__ has quit [Quit: Konversation terminated!]
[22:12:57] -!- FinboySlick has quit [Quit: Leaving.]
[22:15:15] -!- wboykinm has quit [Ping timeout: 260 seconds]
[22:18:11] -!- Deejay has quit [Quit: bye]
[22:18:21] <micges> will it work under xenomai userland relatime?
[22:19:22] <micges> current driver sockets approach won't work becouse of domain switch (relatime->not realtime)
[22:20:14] <micges> though I must check latest driver and see how it's improved
[22:21:41] -!- cwmma has quit [Quit: cwmma]
[22:24:12] <mhaberler> xenomai: I need to ask on the list
[22:24:53] <micges> thanks
[22:25:21] <mhaberler> I _think_ the sendto() will cause a domain switch; but since it's just a notify maybe we can talk them into something rt compati
[22:25:32] <mhaberler> them into doing something rt compatible
[22:28:12] <mhaberler> when I'm back I'll do some tests on real hardware, see if that brings an improvement; if it's worth it, we can take it to the xeno list; but I'll ask anyway if somebody tried
[22:28:40] <mhaberler> in theory rx path should work, since no system call is involved after setup, just manipulation in shm
[22:28:48] <mhaberler> tx path is the dubious one
[22:29:10] <andypugh> puzzled..
[22:29:35] <andypugh> man setenv / getenv works. But trying to use them gives "command not found"
[22:29:59] <andypugh> (Idoo)
[22:30:00] <mhaberler> wrong shell?
[22:30:05] <andypugh> (Udoo)
[22:30:16] <andypugh> Possibly...
[22:30:40] <mhaberler> setenv isnt a bash command; csh methinks
[22:30:49] <mhaberler> export FOO=fooval
[22:31:14] <mhaberler> getting anywhere with the udoo xenomai kernel?
[22:31:56] <andypugh> Yeah, just trying to figure out isolcpus and u-Boot
[22:32:08] <mhaberler> ha
[22:32:30] <andypugh> Paul Corner rudely suggested I should learn how
[22:32:34] <mhaberler> do these guys have any plans to upstream their board support?
[22:32:36] <mhaberler> haha
[22:32:50] <andypugh> There was a word there that I could have left out, I suppose.
[22:32:57] <mhaberler> got the wrong badge, hm
[22:34:14] <andypugh> printenv works.
[22:38:47] -!- skunkworks [skunkworks!~chatzilla@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[22:41:30] -!- chillly has quit [Quit: Leaving]
[22:44:08] <KGB-linuxcnc> 03Dave 05unified-build-candidate-3 b45ce81 06linuxcnc 10(12 files in 4 dirs) Supply (c) & license notices for K9 config files. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b45ce81
[22:51:50] -!- andypugh has quit [Ping timeout: 264 seconds]
[22:52:03] -!- andypugh [andypugh!~andy2@cpc14-basl11-2-0-cust436.20-1.cable.virginm.net] has joined #linuxcnc-devel
[22:53:42] <mhaberler> PCW: see
http://queue.acm.org/detail.cfm?id=2103536, search for TX_RING. this compares raw sockets with PACKET_TX/RX_RING to netmap. Now netmap is still way ahead, but the packet rate of the former is still pretty decent ;)
[22:54:46] -!- skorasaurus has quit [Quit: WeeChat 0.4.2]
[22:54:48] <mhaberler> netmap skips skbufs, but thats obviously the only real difference
[22:56:29] -!- WalterN has quit [Ping timeout: 240 seconds]
[22:57:10] <mhaberler> looks like acceptable compromise between generic hardware+driver reuse at 1.8mio packets/s
[22:57:40] <mhaberler> also turns out this feature is used by wireshark, so it's going to stay around
[22:58:02] <mhaberler> (or rather likely)
[23:12:28] <KGB-linuxcnc> 03Michael Geszkiewicz 05ubc3-7i80 77425c3 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c 10src/hal/drivers/mesa-hostmot2/hostmot2.c 10src/hal/drivers/mesa-hostmot2/hostmot2.h 10src/hal/drivers/mesa-hostmot2/watchdog.c hm2: read watchdog with same packet like rest of data from board * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=77425c3
[23:12:28] <KGB-linuxcnc> 03Michael Geszkiewicz 05ubc3-7i80 c3ff92b 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c hm2_eth: enable debug logging in enqueue_write function * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c3ff92b
[23:12:55] <micges> PCW: ^^
[23:13:01] <micges> skunkworks: ^^
[23:15:27] <micges> current timings on 2,8GHz: 95us read, and two 15us writes per thread cycle
[23:17:57] -!- dnaleromj has quit [Quit: Dang. Where did dnaleromj's computer go?]
[23:18:54] -!- zumba_addict has quit [Quit: zumba_addict]
[23:25:18] <skunkworks> wow
[23:25:28] <micges> both times are 10% better without logging
[23:25:29] <skunkworks> I will test it tomorrow
[23:31:07] -!- lyzidiamond has quit [Quit: lyzidiamond]
[23:34:16] <skunkworks> micges: the functions work the same? Don't need to change anything in the configs?
[23:35:21] <micges> no config changes
[23:37:32] <skunkworks> neat
[23:45:37] <seb_kuzminsky> micges: i like your watchdog-via-tram change
[23:49:19] <micges> thanks
[23:49:26] <PCW> mhaberler, I looked at netmap a while ago and it looks good
[23:49:59] <mhaberler> right, same trick just a tad faster, which I dont think is relevant here
[23:50:10] <mhaberler> at the cost of custom drivers
[23:52:23] <PCW> Thanks for that commit micges , I'll have to try it out later today when I get a chance
[23:53:59] -!- xandrix has quit [Ping timeout: 246 seconds]
[23:54:00] <PCW> the hm2_spi stuff should probably mimic the hm2_eth since the adress overhead can be reduced the same way
[23:54:57] <linuxcnc-build> build #39 of deb-precise-rtpreempt-binary-x86 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-rtpreempt-binary-x86/builds/39 blamelist: Dave <dave@CalypsoVentures.com>
[23:55:08] <linuxcnc-build> build #39 of deb-precise-rtpreempt-binary-amd64 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-rtpreempt-binary-amd64/builds/39 blamelist: Dave <dave@CalypsoVentures.com>
[23:55:48] <PCW> mhaberler:Ill take a look at the PACKET_TX/RX_RING, generic drivers would be much better
[23:58:46] -!- micges1 [micges1!~toudi@egi105.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[23:59:15] micges1 is now known as micges-dev
