[Rock-dev] Rock Performances on Gumstix

[Alexander Duda]

Am 01.08.2012 um 18:56 schrieb Chris Mueller:

> Hi,
> 
> i've currently a very specific szenario using the Vizkit TaskInspector, 
> where you could help me very much by sharing some of your performance 
> experiences.
> 
> I have currently a minimal rock autoproj setup on one of our gumstix 
> system that starts by default
> an deployment via roby at startup. The deployment contains a 
> camera_usb::Task using jpeg compression
> that captures images from a microsoft usb camera attached to the gumstix 
> system.
> 
> On that system 'orops' outputs that the task is running.
> 
> I would like to open the current image frame from this task via 
> TaskInspector through a wireless connection. It's possible to catch
> the TaskContext in rock-display, that is not unreachable. Unfortanetely, 
> the TaskInspector has horrible problems to open the task contents
> (property, input- and output ports) and receiving samples from the 
> ports. It has horrible lag of several minutes only to open the status 
> for the task,
> its properties or its ports through the gui.

The current ruby implementation uses directly the remote task for all operations like each_port, each_property etc which are heavily used by the TaskInspector. If the network connection is bad you cannot use the TaskInspector so far. I am currently working on a ruby binding for a TaskContextProxy which will solve the freezing problem.

> And i always receive 
> warnings continously of:
> 
> Vizkit[WARN]: ReaderWriterProxy for port payloaditem_3_cam_emi.state: 
> ignoring method read because port is not reachable.
> Vizkit[WARN]: ReaderWriterProxy for portPerformance issues / 
> TaskInspector / Port not reachable payloaditem_3_cam_emi.frame: ignoring 
> method read because port is not reachable.
> Vizkit[WARN]: ReaderWriterProxy for port Performance issues / 
> TaskInspector / Port not reachablepayloaditem_3_cam_emi.frame_raw: 
> ignoring method read because port is not reachable.

You are running into a connection timeout which is set to around 2 sec for rock-display. 

> 
> 'top' outputs for the gumstix the following performance values:
>  4976 root      cpu 60.4 mem 10.9  18:59.56 payload_cameras (varies 
> between 45.0 and 65.0)
>  4925 root      cpu 24.6 mem 23.7  10:47.76 ruby1.9.1
>  4982 root      cpu 7.0 mem 14.6   2:40.66 TELEMETRYPROVIDER
> Other processes varies between 0.0 and 1.0 for cpu and memory.
> 
> For another hint: an open bash via ssh to that system seems to work 
> flawlessly without any interrupts / lags.
> 
> 'ping' executed during these steps outputs the following stats for the 
> wireless connection (DFKI-LAB):
> avg 22.093 ms
> dev 11.393 ms
> min 9.22.093 ms
> max 66.864 ms
> 
> Could it be the system is completely overstrained handling the camera 
> process and is too slow for remote connections?
> Network latency seems to be okay on the first naive view. 
There are a number of calls to read the hole interface therefore 22ms can be quite hight. 
I guess you need more than 30 calls to get the hole camera interface.

> 
> Unfortanetely, i can not test rock-display on that system itself, 
> because we didn't install vizkit there for reducing compilation time.

start the camera and write a small script which is just connecting to the remote task and displaying the camera frame. This is the best you will get with your current setup.

camera = Orocos::TaskContext.get "camera"
Vizkit.display camera.frame

If you need more help, let me know.

Alex
> 
> Chris
> _______________________________________________
> Rock-dev mailing list
> Rock-dev at dfki.de
> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev