Back
[06:18:20] <KGB-linuxcnc> 03John Thornton 052.7 14baa55 06linuxcnc 10docs/src/remap/remap.txt Docs: more anchor and link fixing * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=14baa55
[07:06:41] <linuxcnc-build_> build #2663 of 4006.deb-lucid-rtai-i386 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4006.deb-lucid-rtai-i386/builds/2663 blamelist: John Thornton <bjt128@gmail.com>
[09:20:50] <seb_kuzminsky> that failure is a buildbot deb archive manipulation bug :-/
[11:10:00] <pcw_home> Tried 3 hm2_eth cards at 3 KHz on the h97, works fine, maybe 15 usec more servo thread time going from 2 to 3 cards
[11:10:02] <pcw_home> (which suggests that a 8 card limit might be ok except for somewhat unmanageable driver command line parameters )
[11:10:03] <pcw_home>
[11:18:41] <skunkworks> wow - how much i/o could you possibly have? almost unlimted
[11:21:44] <pcw_home> Yeah the 1G switch makes a good funnel
[11:29:20] <pcw_home> Somewhat stunning to think that the wire time of a good sized motion packet (200 bytes is pretty big) is < 2 usec on the 1G link
[11:41:26] <pcw_home> I still just have GPIO on the second and third cards so the overhead will increase somewhat when they are
[11:41:28] <pcw_home> more fully utilized, but by arranging the read-requests properly, theres a large amount of 100BT wire time
[11:41:30] <pcw_home> and 7IXX remote response time that can be overlapped so the per card overhead is reduced
[14:27:32] <jepler> hm, I have one system where clock_gettime(CLOCK_MONOTONIC) runs in ~50ns, and a greater number of systems where it runs in ~600ns.
[14:27:57] <jepler> I wonder whether it's being old (ubuntu 8.04) or server-class (xeon but a few years old) is the reason
[14:28:08] <jepler> .. for the very, very fast outlier
[14:30:04] <jepler> I'm contemplating unconditionally using clock_gettime to provide rtapi_clocks in uspace. this is how ARM has always worked since uspace was implemented, since ARM doesn't have a standard timestamp counter
[14:35:17] <pcw_home> you mean the overhead of the call is 600 ns?
[14:36:55] <jepler> right
[14:37:39] <jepler> I wrote a program which calls clock_gettime repeatedly, until the time since the first call was >1s
[14:38:13] <jepler> so for instance one run of this program printed 1624521, which is 615ns average per call
[14:38:45] <pcw_home> thats rather expensive, does make you wonder whats different on the fast system
[14:39:02] <jepler> the program:
http://paste.ubuntu.com/11988497/
[14:39:34] <jepler> I'm looking at this in part because I tried writing a program that prints the TSC rate. simple method: take tsc, sleep 1s, take tsc; print tsc difference
[14:40:08] <jepler> but on the system where I've been doing most of my work, the delta tsc varies by a factor of 2; the wall time of the run is always ~1.01s, so it's not that it's sleeping longer than expected
[14:40:33] <jepler> 545157063
[14:40:36] <jepler> 267950359
[14:40:40] <pcw_home> CPU clock speed modulation?
[14:40:55] <jepler> in 8 runs on that system, that's the highest and lowest delta-tsc that was printed
[14:41:27] <jepler> dmesg has this:
[14:41:27] <jepler> [ 4.600019] tsc: Refined TSC clocksource calibration: 3158.749 MHz
[14:41:32] <jepler> [ 14.662833] tsc: Marking TSC unstable due to TSC halts in idle
[14:42:02] <jepler> oh and I am running this pinned to a specific CPU so clockskew between CPUs does not explain it
[14:43:20] <jepler> cpu flags include constant_tsc but that's apparently a lie that linux figures out in 10s
[14:43:37] <jepler> cat /sys/devices/system/clocksource/clocksource0/current_clocksource
[14:43:37] <jepler> hpet
[14:44:10] <jepler> linuxcnc could look at this file and find out what linux is using
[14:44:21] <pcw_home> Is this your core2 Duo?
[14:44:35] <jepler> yes
[14:46:08] <pcw_home> I dont have any similar messages
[14:46:13] <jepler> http://www.gossamer-threads.com/lists/linux/kernel/1325118
[14:49:03] <jepler> something linuxcnc does actually stabalizes the tsc
[14:49:12] <jepler> 3159003118
[14:49:15] <jepler> 3159139396
[14:49:27] <jepler> now 8 runs only varies this much, way under 1%
[14:50:12] <pcw_home> linuxcnc messes with cstates?
[14:50:18] <jepler> probably requesting lowest latency via /dev/cpu_dma_latency stops it changing power states
[14:52:13] <pcw_home> interesting that Ix CPUs have invariant TSCs
[14:53:17] <pcw_home> (sort of seems like they missed the basic idea of a time stamp counter the first time around)
[14:54:39] <jepler> when rdtsc went into Pentium they didn't have power-saving states, CPU frequency scaling, multiple cores, all the stuff that makes it terrible
[14:54:55] <jepler> (well, they had smp which makes it terrible)
[14:56:10] <pcw_home> Yeah
[14:56:12] <pcw_home> I guess processor.max_cstate=1 is global
[15:15:06] <jepler> but beingin the low cpu_dma_latency mode prevents the CPU from ramping *up* too
[15:15:25] <jepler> so that's why linuxcnc is usually but not 100% always stuck at 2GHz on this machine
[15:15:29] <jepler> .. I think
[15:16:49] <pcw_home> Ahh thats not good, what about the processor.max_cstate=1 kernel config line option?
[15:28:57] <jepler> apparently you can't set cpu frequency stuff at runtime with RT kernel --
http://www.spinics.net/lists/linux-rt-users/msg12207.html
[15:29:18] <jepler> maybe just a bug but nobody seems to have figured it out at the time
[15:41:34] <jepler> interesting! booting with processor.max_cstate does make rdtsc stable *and* it drops clock_gettime to 30ns
[15:41:45] <jepler> but CPU frequency still ends up at 2GHz
[15:42:05] <pcw_home> weird
[15:42:39] <pcw_home> can you disable cstates >1 in the BIOS?
[16:41:05] <jepler> wow, what is this stuff?
http://www.adafruit.com/products/2660
[16:41:53] <jepler> tin led bismuth indium
[16:50:33] <Tom_itx> couldn't be that healthy
[16:54:18] <pcw_home> something like Woods metal but with Indium replacing the Cadmium
[16:54:45] <pcw_home> (so less toxic)
[16:56:21] <pcw_home> add some Gallium and no need to heat
[16:57:16] <pcw_home> just dont get on any aluminum
[17:09:41] <andypugh> The fact that the top-left “2.6 Live+Install Image” Link still goes to an email on Gmane seems a bit untidy to me. The “Download” link is a much better place to link to.
[17:10:56] <andypugh> Separately: This is an interesting question and I can’t help feeling that the answer ought to be easy.
http://www.linuxcnc.org/index.php/english/forum/10-advanced-configuration/29466-absolute-encoders#61078
[17:49:26] <pcw_home> Another homing mode input to motion? or just dont allow homing for absolute encoders ( drop them from the GUI)
[17:51:02] <andypugh> NO_FORCE_HOMING is close to what he needs.
[18:54:44] <KGB-linuxcnc> 03John Thornton 052.7 cae58c0 06linuxcnc 10(15 files in 4 dirs) Docs: use same naming convention for anchors and links * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=cae58c0
[18:54:44] <KGB-linuxcnc> 03John Thornton 052.7 b9d901b 06linuxcnc 10(8 files) Docs: more work on anchors * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b9d901b
[18:54:44] <KGB-linuxcnc> 03John Thornton 052.7 98287f3 06linuxcnc 10(7 files) Docs: more work on anchors * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=98287f3
[18:54:45] <KGB-linuxcnc> 03John Thornton 052.7 6252da9 06linuxcnc 10(11 files in 4 dirs) Docs: more work on anchors * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6252da9
[18:56:17] <jthornton> getting closer to finishing this
[18:56:46] <jthornton> seb_kuzminsky, I assume your waiting on a fix from Rob for 2.7.0?
[19:01:30] <Tom_itx> jt, did you add the expandable menus?
[19:48:29] <andypugh> Anyone want to at least watch the other channel? Someone has been looking at the code and doesn’t like it. I am not sure that he doesn’t have the wrong end of the stick, but with the right nudges perhaps he could b useful.
[19:50:15] <Tom_itx> it's logged in case you missed it
[20:21:35] <andypugh> <vent> So he knows more about coding than any of us, and he knows more about running a machine shop than Stuart@MPM
[20:53:49] <jepler> we need more guys like that
[20:54:03] <jepler> they'd be able to solve a mdi remapping sequence number o-word bug for breakfast
[21:01:09] <andypugh> Oooh, Should I set him on to it? :-)
[21:01:28] <cradek> couldn't hurt
[21:01:57] <andypugh> I am thinking the same. We ever get a fix or some humility.
[21:17:36] <jepler> pcw_home: is a 9x9 lookup table (9 bits in, 9 bits out) look-up table feasible in fpgas? that's just a modest block ram, right?
[21:19:08] * jepler is reading about "single-track circuit codes". With 9 sensors and one specially-encoded track, you can find an absolute angular position at a resolution of 1/504 rotations
[21:19:15] <andypugh> I thought you were a coder, but you just used the number 9!
[21:19:42] <andypugh> Ah, those things are super-clever
[21:20:42] <pcw_home> Yeah fits in one blockram on most any FPGA even Spartan2
[21:20:51] <jepler> doing the decoding in hal at 1kHz would probably even be enough, if you go .5 revolution / ms, that's 30krpm..
[21:21:01] <andypugh> Though Renishaw have a neater thing. It’s a barcode and a camera. The visible barcode says where on the circle it is, the pixel-position of the barcode gives you very many more bits of resolution.
[21:22:07] <andypugh> I once (but only once) found the name for that encoding, where given n samples of N marks you can say where you are in the sequence.
[21:23:07] <jepler> length 17 = 131070 codes per revolution, should be enough for anybody
[21:23:08] <jepler> afk
[21:23:27] <pcw_home> the XC6SLX9 has 32 2Kx9 (or 1Kx18 etc ) BlockRAMs
[21:33:59] <jepler> andypugh: I remember john k had done some back of the envelope calculations about the kind of code you are referring to
[21:34:45] <jepler> he wanted to have the code on a linear scale with enough resolution that knowing the coarse position from this code + seeing index pulse on an encoder was enough to get absolute position
[21:34:53] <jepler> -> home in just a few revolutions of the motor, anywhere on the table
[21:34:54] <andypugh> http://www.renishaw.com/en/resolute-absolute-encoder-system-with-rexa-rotary-angle-ring--10852
[21:35:00] <andypugh> No index
[21:35:26] <andypugh> I was sent one by Renishaw to write a HAL driver, but it got lost in the post :-(
[21:36:38] <jepler> the output of a LFSR has the property that you can tell where you are in the the sequence of length 2^n from just n (or maybe n+1) consecutive codes
[21:38:03] <andypugh> LFSR?
[21:38:17] <jepler> https://en.wikipedia.org/wiki/Linear_feedback_shift_register
[21:39:31] <jepler> the value from the single sensor is the 0/1 which keeps blinking and getting shifted in from the right
[21:40:19] <jepler> what I don't know about LFSRs is if there's an easy way to transform from the 4-bit register value to the angle in that circle
[21:40:37] <jepler> or if you're stuck using a LUT which would be pretty big if you want a few million positions
[21:41:12] <pcw_home> Played with a particular variant in the 70s (1024 length single xor) this makes nice music (fractal patterns)
[21:42:53] <jepler> of course I'd get stuck on the way to actually fabricating any of these things
[22:08:24] <pcw_home> the binary length single xor generates a Sierpinsky triangle (which sounds nice)
[22:10:16] <pcw_home> binary length single xor LFSR I mean
[22:12:08] <pcw_home> if the length is close to binary ( say 2^1+1 ) the pattern slowly turns into white noise like a normal LFSR PRBS gen
[22:17:09] <jepler> and then suddenly and for unknown reasons I am reading
https://en.wikipedia.org/wiki/Man_or_boy_test
[22:17:50] <jepler> .. goodnight
[23:00:42] <seb_kuzminsky> i agree with andypugh, 2.6 isn't "news" any more