On 5 August 2010 15:35, Cedric Pradalier <cedric.pradalier@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@gmail.com> wrote:
On 14 July 2010 03:52, Josh Faust <jfaust@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


-- 
Dr. Cedric Pradalier
http://www.asl.ethz.ch/people/cedricp

_______________________________________________
ros-users mailing list
ros-users@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