[ros-users] Arm Core Performance

Daniel Stonier d.stonier at gmail.com
Fri Aug 6 07:08:04 UTC 2010


Ok, applied cedric's patches and the rpc outgoing request is down from an
average of about 98ms to 56ms, also the returning response is down to an
average of 3ms. Which is starting to seem reasonable.

About 40-45ms of that outgoing time is spent in the xmlrpcclient->execute
call in master::execute (when contacting the master to initialise an rpc
link). I didn't bury down any further into the xmlrpc library.

With cedric's patches too, the msg latency dropped to about 6ms, which is
getting close to the raw tcp/ip socket times I tested. So its starting to
seem reasonable.

Nice analysis on the timers cedric! And thank you everyone for the input and
pointers. Now we've just one alignment trap issue to worry about.

Regards,
Daniel Stonier.

On 6 August 2010 08:13, Daniel Stonier <d.stonier at gmail.com> wrote:

>
>
> On 5 August 2010 15:35, Cedric Pradalier <cedric.pradalier at mavt.ethz.ch>wrote:
>
>>  Hello Daniel,
>>
>> Could this be linked with the high-frequency loops I mentioned in my posts
>> last week?
>> Or, could the latency be affected (positively or negatively) by the
>> changes I was proposing?
>>
>> Cheers
>>
>>
> That one's on my todo list for this morning already!
>
>
>>
>> On 08/05/10 08:27, Daniel Stonier wrote:
>>
>>
>>
>> On 14 July 2010 15:51, Daniel Stonier <d.stonier at gmail.com> wrote:
>>
>>>  On 14 July 2010 03:52, Josh Faust <jfaust at willowgarage.com> wrote:
>>> >> == NUM_PTS 1000 ==
>>> >>
>>> >> board               avg_ser     avg_deser
>>> >> intel i5             0.000011    0.000025
>>> >> arm1176jzf-s   0.001328    0.003354
>>> >
>>> > Ok, so serialization is definitely much slower, but with the latency
>>> test
>>> > you're using it shouldn't affect anything.  Good to know though.
>>> >
>>> >>
>>> >> == Latency Results ==
>>> >>
>>> >>                          IPC        NoTCP      Bypass
>>> >> intel i5           :   0.4ms     0.10ms     0.05ms
>>> >> arm1176jzf-s :   25.0ms   4.50ms     3.50ms
>>> >>
>>> >> ====== Raw Socket Tests ======
>>> >>
>>> >> Tests the latencies of sending a single char from server to client,
>>> >> written using simple posix socket code.
>>> >>
>>> >> intel i5           : 0.1ms
>>> >> arm1176jzf-s : 1.4ms
>>> >
>>> > Do you have any way of profiling exactly what's taking time, either
>>> with
>>> > gprof, google perf tools, or something else?
>>> > Josh
>>>
>>>  Since the slowdowns were across the board I started doubting the
>>> platform underneath the ros - ran some test programs I have back on
>>> our very simple non-ros platform and noticed a significant difference.
>>> So I'll rebuild the platform, check some of the flags used on the old
>>> build and make sure I match them on the new one and see how that goes.
>>> Will try gprof in parallel too I think, but its going to be a couple
>>> of days recompiling. Will let you know how it goes and thanks for the
>>> advice.
>>>
>>>
>>  Got waylaid by another project for a while - sorry to drag out old
>> cobwebs!
>>
>> Optimised everything else, made sure I'm using the correct flags for the
>> platform and the tcp/ip msg latencies have dropped from 25ms -> 9-10ms,
>> which is starting to perhaps seem reasonable. The rpc latencies are still
>> horrendous though - ~100ms for one process to get in contact with another
>> (and about 5ms for the return trip). I managed to get gprof working on it
>> and compared it to the same processes running on the intel i5, but its
>> showing up nothing of considerable note. Just some boost spinlocks
>> contributing an extra 10% worth of cpu time (which probably dont show up on
>> the i5 simply because they trigger on and off so fast). But certainly
>> nothing obvious.
>>
>> So, I'm guessing that the process (or roscore) is idling/hanging
>> somewhere. I'm going to have to manually hack some of the ros code and pull
>> some timings to figure out just where I think (don't know of a better way).
>>
>> The results are at http://snorriheim.dnsdojo.com/tmp/rpc_latency if
>> interested.
>>
>>
>> _______________________________________________
>> ros-users mailing list
>> ros-users at code.ros.orghttps://code.ros.org/mailman/listinfo/ros-users
>>
>>
>>
>> --
>> Dr. Cedric Pradalierhttp://www.asl.ethz.ch/people/cedricp
>>
>>
>> _______________________________________________
>> ros-users mailing list
>> ros-users at code.ros.org
>> https://code.ros.org/mailman/listinfo/ros-users
>>
>>
>
>
> --
> Phone : +82-10-5400-3296 (010-5400-3296)
> Home: http://snorriheim.dnsdojo.com/
> Yujin Robot: http://www.yujinrobot.com/
> Embedded Control Libraries: http://snorriheim.dnsdojo.com/redmine/wiki/ecl
>



-- 
Phone : +82-10-5400-3296 (010-5400-3296)
Home: http://snorriheim.dnsdojo.com/
Yujin Robot: http://www.yujinrobot.com/
Embedded Control Libraries: http://snorriheim.dnsdojo.com/redmine/wiki/ecl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20100806/37b79449/attachment-0003.html>


More information about the ros-users mailing list