[Rock-dev] Rock Performances on Gumstix

[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. 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.

'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.

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

Chris