<p>Hello,
</p>
<p>I might be trying to push it too hard here, but currently within our organization we are evaluating VirtualHere server performance w.r.t. usage in our testing systems for embedded devices. The use of Raspberry PI with VirtualHere looks very desirable and is quite affordable.
</p>
<p>Ultimately, the usecase here is to flash an embedded device with USB-connected JTAG adapter using OpenOCD. The setup we are having is as follows:
</p>
<p>* OpenOCD runs in a Docker container, which maps USB devices from the host<br />
* Docker container runs in a virtual machine, which maintains vhclient up<br />
* autossh keeps the SSH tunnel up between virtual machine (localhost:7575) and raspberry pi (pi's localhost:7575)<br />
* vhclient is manually configured to auto use everything from hub localhost:7575
</p>
<p>The ongoing issue is that doing the same firmware update operation over ssh tunnel is 4 times slower compared to doing it over Pi's external network interface.
</p>
<p>I have been using quite some time to try different combinations and factor out different possibilities. I have come to the conclusion that the root cause is communication to VirtualHere server happenning on the Pi's loopback interface.
</p>
<p>Here is the data I have collected: http://pastebin.com/wVkMBGzz
</p>
<p>I am not sure how can I run both the server and the client in Pi (guess the kernel would go crazy), but please advise me about any other actions I could take to help further this issue.
</p>
<p>Regards,<br />
Roman</p>
Its might be because your ssh
Its might be because your ssh tunnel is not honoring the TCP_NODELAY flag. I would recommend using a direct socket connection (or reverse connection) or a ssl based setup that virtualhere supports natively. The 33s for native and 41s for virtualhere is the kind of performance i would expect. Remember the pi shares the usb bus with the network..
Thanks again for a quick turn
<p>Thanks again for a quick turn-around,
</p>
<p>I have also tried to factor out the ssh tunnel itself and did the following variation (last item on the http://pastebin.com/wVkMBGzz):
</p>
<p>* SSH tunnel was done through a different host (not directly to the RPi), e.g. ssh -L 7575:pi_ip:7575 proxy
</p>
<p>So, the communication was going through the loopback interface of the virtual machine, but it landed on VirtualHere server through external interface.
</p>
<p>I will try to google for possible solutions to TCP_NODELAY flag. Currently, this issue is not a showstopper for us as we can simply patch the config.ini with a different manual hub address and continue testing the stability.
</p>
<p>The basic reason for an SSH tunnel is to provide secure communication using existing infrastructure (we already control RPi over SSH). We could add SSL certificate, but this would just add up to the maintenance burden.
</p>
<p>Regards,<br />
Roman</p>
Timing for the last trial
<p>Timing for the last trial with external SSH tunnel was:
</p>
<p>real 0m44.743s<br />
user 0m0.530s<br />
sys 0m0.410s
</p>
So does that mean using
So does that mean using virtualhere via the external ssh tunnel it is 44s vs virtualhere via direct tcp is 41s?
Yes, and with a tunnel
<p>Yes, and with a tunnel straight to RPi it takes over 2 minutes</p>
Hi Roman, Could you tell me
Hi Roman, Could you tell me how to ssh the raspberry pi with the virtual machine? I do not really know how to use tunnel, I am thinking about use my windows pc ssh a tunnel with a host server, and raspberry pi create a reverse tunnel to the host server, so that, my usb on raspberry pi could be able to found by my windows Virtual Here USB Client