Back
[17:18:56] <jepler> I've started
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?ContribuedHalFiles for that purpose
[17:24:40] <SWPadnos> can someone tell me when I got disconnected (and/or the last thing you see from me)?
[17:25:11] <jmkasunich__> on this channel the last thing I see from you is at 22:25 last night
[17:25:24] <SWPadnos> ok"several RT filters ..." ?
[17:25:37] <jmkasunich__> yeah
[17:25:42] <SWPadnos> hmmm
[17:26:08] <SWPadnos> there was no indication here that I was disconnected - I said more stuff to Jon, then some to Alex this morning
[17:26:28] <SWPadnos> nothing in reply, and I was surprised that Jon appeared to have left his machine connected all night :)
[17:33:48] <jmkasunich__> strange
[17:34:07] <jmkasunich__> my many disconnects result in a "connection timed out" after about a half hour or so
[17:34:46] <SWPadnos> yeah, normally Chatzilla will see the disconnect and try reconnecting a few times (after various wait periods)
[17:56:43] <alex_joni> SWPadnos: you got client quit, not timeout
[17:57:28] <SWPadnos> hmmm
[17:57:57] <alex_joni> 05:18 -!- SWPadnos [n=Me@emc/developer/SWPadnos] has quit [Remote closed the
[17:57:57] <alex_joni> connection]
[17:58:26] <SWPadnos> I think I may have done it accidentally - at some point, I accidentally hit the "offline" button on the main Mozilla window. I guess Chatzill adidn't reconnect when I hit it again to go online
[18:12:38] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/timedeltas.png
[18:13:05] <jepler> this is interesting behavior -- the time differences recorded by timedelta tend to vary in big jumps
[18:13:39] <SWPadnos> is that in CPU clocks or nanoseconds?
[18:14:27] <jepler> rtapi_get_time() so it's nanoseconds and dependent on the rtos to provide a good estimate
[18:14:37] <jepler> so it's probably just granularity in that function
[18:14:43] <jepler> somewhere around 800ns in this case
[18:14:46] <SWPadnos> hmmm
[18:14:56] <SWPadnos> as I recall, that function took a very long time to execute
[18:15:31] <jepler> I've heard that too
[18:15:31] <jmkasunich__> yeah, get_time sucks
[18:15:41] <jepler> 3 s32 RO 9203 timedelta.0.time
[18:15:57] <SWPadnos> about 9000 of that is probably get_time
[18:15:57] <jmkasunich__> what exactly does timedelta do?
[18:16:08] <SWPadnos> tells you the time between thread runs
[18:16:09] <jepler> jmkasunich__: it's part of the hal-only latency test, scripts/latency-test
[18:16:25] <jepler> calls rtapi_get_time() and does a little bookkeeping
[18:16:29] <SWPadnos> in a hal-scope-able way
[18:18:22] <jmkasunich__> so the 25K offset is roughly the period
[18:18:37] <SWPadnos> actually, that granularity leads me to believe that the timing source is the 1.19mumble MHz clock
[18:18:37] <jmkasunich__> and the +/- ~1000 variations are latency
[18:19:07] <jmkasunich__> SWPadnos: that sounds like a good explanation
[18:19:38] <jmkasunich__> jepler: can you zoom in and determine the actual granularity (to a few percent anyway)?
[18:19:54] <SWPadnos> and/or change the rtapi_get_time to readTSC
[18:20:00] <jmkasunich__> see if it matches 1/1.19mumble
[18:21:29] <jepler> the dominant value seems to be 25143, with the value just below being 24305 and the one just above is 25891
[18:21:44] <jepler> they aren't always exactly the same -- there are some 25152 and some 25143 as the 'middle value'
[18:22:11] <jepler> [235309.833545] RTAI[sched]: Linux timer freq = 250 (Hz), CPU freq = 1193180 hz.
[18:22:12] <jepler> [235309.833795] RTAI[sched]: timer setup = 838 ns, resched latency = 2514 ns.
[18:23:12] <jmkasunich__> 1/(25143-24305) = 1.19
[18:23:12] <SWPadnos> ok, so the minor variations are due to code/cache randomness, and the major variation is due to the scheduling tick coming from the 1.193180 clock
[18:25:20] <SWPadnos> isn't there an RTAI call for converting clocks to nanoseconds and/or vise versa?
[18:25:53] <jepler> no, I think there's one for converting from ns to interrupt clock times
[18:26:19] <jepler> it would be nice to have such a function in rtapi, and maybe implement rtapi_get_time in termsof it
[18:26:20] <SWPadnos> hmm
[18:26:57] <SWPadnos> I thought there was one, but it's very time consuming. I was thinking that calling it once to get a scale factor would be a good thing
[18:27:24] <SWPadnos> actually, it would make sense to have the clock/ns scale in HAL data somewhere - it seems that it's useful in a number of places
[18:27:27] <jepler> kernel 2.6 (and maybe earlier) have cpu_khz
[18:27:50] <jmkasunich__> the last time I tried to figure out clock to seconds conversion, I gave up
[18:28:03] <jmkasunich__> finding a portable method is tough
[18:28:08] <SWPadnos> I remember that
[18:28:26] <jepler> I have something for ns to clocks in hal_parport now
[18:28:57] <jepler> but I got it wrong the first few times so I dunno if it's right now
[18:29:01] <SWPadnos> heh
[18:29:02] <jepler> and it's certainly not accurate in all the available bits
[18:29:14] <SWPadnos> hey - don't forget that I helped to get it wrong :)
[18:30:04] <jepler> you mean you helped me write the opposite conversion function, and like a chump I used that instead of the right one
[18:30:14] <SWPadnos> exactly!
[18:30:32] <jepler> that means both functions are written, then
[18:31:27] <SWPadnos> oh, then it's just a matter of choosing the correct one
[18:41:58] <jmkasunich__> jmkasunich__ is now known as jmkasunich
[19:14:43] <fenn_> fenn_ is now known as fenn
[19:48:17] <jepler> using the cycle counter (rtapi_get_clocks()) there are a lot more distinct values measured
[19:49:47] <fenn> do a fourier transform on it?
[19:50:09] <jepler> for the purposes of a latency test, rtapi_get_time() doesn't seem so bad -- it even gives the base thread something to do, instead of being nearly empty
[19:59:41] <alex_joni> hmm, I have some recollection that rtapi_get_time() freezes or doesn't work on some platforms
[20:00:07] <alex_joni> or was it some specific version of rtapi_get_time()..
[20:05:05] <jepler> I thought it was just said to be slow
[20:10:20] <alex_joni> I think there are systems where the rtai part is missing, and a kernel call was thrown in
[20:10:50] <alex_joni> which is preemptive I think
[20:25:47] <jepler> you mean that on some rtai system, rt_get_cpu_time_ns() is not realtime? or that on some rtlinux system gethrtime() isn't realtime?
[20:25:58] <jepler> that would be really really crappy
[20:27:11] <alex_joni> rtapi_get_time() used to call do_gettimeofday() a while ago
[20:27:28] <alex_joni> check rtai_rtapi.c line 560
[20:28:06] <alex_joni> I remember we tried 4-5 iterations to make it work right, but that didn't work
[20:28:27] <alex_joni> as it is now it's safe, but takes quite a while on some systems
[20:30:23] <jepler> that's fine with me, as long as it's 5-10us -- similar to the amount of CPU that would be used to actually do step generation
[20:30:45] <alex_joni> yeah, might be ok in this case
[20:30:55] <alex_joni> can you run latency-test on sim?
[20:33:15] <jepler> yes but what would the results mean?
[20:33:37] <alex_joni> maybe that it's good enough for a servo machine?
[20:34:52] <SWPadnos> sim isn't just non-RT
[20:35:08] <SWPadnos> it also doesn't have any I/O capability
[21:07:56] <jepler> rtapi_app can easily get I/O capability with a setuid bit and a call to iopl()
[21:08:58] <jepler> that's why I said earlier: "rtapi_app could be hacked in short order to use whatever delay technique is in fashion now, to do I/O, and refuse creation of more than one thread.."
[21:09:00] <SWPadnos> yep, some "RT=userspace" option is possible, but not the way sim is right now
[21:09:04] <SWPadnos> rigth
[21:09:08] <SWPadnos> ht
