[Rock-dev] Rock Performances on Gumstix

[Chris Mueller]

On 01.08.2012 20:46, Alexander Duda wrote:
>
> 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.
>
>> 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.
I have tested this now on one of our camera payload items and it simple 
returns a black/grey window with "no signal".

I have experimented with the configuration from the usb camera and 
reduced it to a 160x120 resolution. The performance via top was very low 
afterwards (oscillate between 20 and 30 percent in cpu, 40 percent 
memory consumption), but i get the same problems.

I guess the network latency is therefore the reason for this issue, 
especially if need more than 30 calls for the camera interface.

Is it possible to increase the timeouts manually per script?

Chris