Back
[13:44:19] <cradek_> cradek_ is now known as cradek
[14:16:37] <skunkworks> join ubuntu
[14:16:50] <skunkworks> oops :)
[14:18:51] <SWPadnos> +/ +# ;)
[14:21:48] <skunkworks> actually this web irc client lets me do /join ubuntu
[14:21:59] <skunkworks> just forgot the /
[20:00:04] <jepler> I finally got around to checking that 'eager' patch in, after I tested it a bit more and made these graphs of the relative speed:
http://emergent.unpy.net/files/sandbox/enqueue-old.png http://emergent.unpy.net/files/sandbox/enqueue.png
[20:00:52] <jepler> (note that the scales are not the same: it's 100/div on the old and 200/div on the new, so it's even more of an improvement than it looks)
[20:02:03] <SWPadnos> that's queue depth?
[20:05:03] <jepler> yes
[20:08:50] <skunkworks> that is one hell of an improvement (all though I am not sure what I am looking at) - am I looking at how fast it gets up to speed - are these short line segments?
[20:10:12] <skunkworks> meaning - is the program that the speed is showing made up of short line segements
[20:10:16] <cradek> it queues all 1000 moves of a program in 1 second?
[20:14:38] <jepler> cradek: yes
[20:14:57] <jepler> skunkworks: this is not about the speed the machine is moving, but whether the information about the moves in the program is available in the realtime part
[20:14:58] <cradek> wow that's great
[20:17:31] <skunkworks> Neat - can you give a simple explaination of how this was done? (what made such a drastic improvement?)
[20:17:49] <skunkworks> "simple"
[20:18:11] <jepler> skunkworks: the userspace 'task' program does a little work and then sleeps for [TASK]CYCLE_TIME
[20:18:31] <jepler> skunkworks: with my change, it just skips the sleep when it's actually doing the work of transferring segments into the realtime layer
[20:18:40] <skunkworks> nice
[20:18:56] <jepler> (but you have to be careful not to remove too many sleeps, because then it never does and hurts the performance of other userspace stuff)
[20:21:56] <skunkworks> How do you decide how often to skip the sleep?
[20:22:32] <jepler> "when[ever] it's actually doing the work of transferring segments"
[20:24:09] <jepler> each time through the loop, it does one of many actions
[20:24:30] <jepler> then sleeps
[20:24:45] <jepler> my change has some of those actions set a flag that skip the sleep on the next time through
[20:27:19] <skunkworks> sounds elegant.
[20:28:28] <jepler> the graphs speak for themselves
[20:29:09] <cradek> for dwells, pauses, and probing that speed is very important
[20:34:00] <jepler> while jmkasunich had suggested changing the 'tcq' so that it can be written directly from userspace (instead of transferring one item per servo period) it looks like this approach is entirely adequate at least so long as the planner disposes of at most one item per trajectory period
[20:35:05] <cradek> and that is certainly true today
