On 10/12/2015 11:50 PM, Pekka Roivainen wrote: > On 10/12/2015 11:27 PM, [email protected] wrote: >> Date: Mon, 12 Oct 2015 13:27:36 -0700 (PDT) >> From: "Peter C. Wallace"<[email protected]> >> Subject: Re: [Emc-developers] Timing of realtime functions in uspace >> To: EMC developers<[email protected]> >> Message-ID:<[email protected]> >> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed >> >> On Mon, 12 Oct 2015, Pekka Roivainen wrote: >> >>>> Date: Mon, 12 Oct 2015 22:55:03 +0300 >>>> From: Pekka Roivainen<[email protected]> >>>> Reply-To: EMC developers<[email protected]> >>>> To:[email protected] >>>> Subject: [Emc-developers] Timing of realtime functions in uspace >>>> >>>> Hello! >>>> >>>> I'm building an ethernet based IO board to be used with LinuxCNC. I >>>> wrote a short webpage about my project onwww.pekka.eu/cnc >>>> >>>> Everything is working quite well, except for the write and read >>>> operations being too slow. I have two functions exported to HAL, read >>>> and write. The .time pin which is automatically exported to HAL for each >>>> function states that the execution time of the read and write functions >>>> are about 450000ns and 40000ns respectively. For debugging, I generated >>>> my own pins for both functions to measure the execution time of the >>>> function itself. I measure the execution time by calling >>>> rtapi_get_time() in the very beginning of the function and in the end. I >>>> calculate the difference and pass it to a HAL pin. By examining the >>>> values of these pins, I see that the execution times according to >>>> rtapi_get_time() are about 220000ns and 18000ns for read and write. So >>>> it seems that the execution time stated by HAL is a bit more than double >>>> the execution time of the function itself. The 220us execution time for >>>> the read would be something that I'd expect from my hardware, but when >>>> it's doubled it starts to be too much for running servo thread with 1kHz. >>>> >>>> Is this expected behavior? It sounds a bit strange to me, especially as >>>> the ratio between the two measurements is quite close to two. I have >>>> checked like million times that I don't have the functions added to the >>>> treads twice or something other stupid things, but I cannot seem to find >>>> anything like that. Does anyone have any hints? >>>> >>>> I have tested my software with Debian Wheezy, kernel 3.2.0-4-rt-686-pae >>>> and with LinuxCNC versions 2.7.0~pre6 and 2.7.0. >>>> >>>> Thank you for any comments. >>>> >>>> Regards, >>>> Pekka Roivainen >>>> >>>> >>>> PS. This being my first post ever to this list, I want to express my >>>> greatest gratitude to all the developers of LinuxCNC. This is a >>>> fantastic piece of software. >> Did you scale the hal times correctly? They are in CPU clocks, not ns >> >> > Thanks for this info Peter. I had no clue those times were presented as > clock cycles. By checking lscpu, my laptop seems to run at 800MHz. The 1 > nanosecond scale I was expecting would be the same as 1GHz clock > frequency so according to that the difference should be 1.25 and not 2. > But I need to continue investigating with that new bit of info. Thanks > again! > > Pekka > After investigating a bit more, I found that my laptop actually was running at 2GHz clock frequency when the thread was running but then dropped to 800MHz when idle. So that explains the 2x difference in the readings perfectly. My issue is then solved, or actually turned out to be false. I also noticed that when I forced the clock frequency to 2GHz using cpufreqd, I got (quite naturally) a bit faster thread execution time. Now I'm able to run the whole servo thread in less than 250us, which starts to be acceptable, I think.
Thank you Peter for the tip. Nice to see also that there are others doing similar things as well, hopefully there is something where we can join our efforts. Pekka ------------------------------------------------------------------------------ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
