I am running 14 spectrometers on a RPi3 using Cloudhub and have tried both vhui64.exe and vhui32.exe on two different win7 PCs. On both, the CPU for the vhui task is around 14 %. It doesn't matter if it is running as a service or not. For reference, doing the same tasks with Coolgear USBG-4NET devices and the Windows USB Server.exe shows a CPU usage of 0%. A program that is doing extensive processing and graphing of the data from the spectrometers is showing a CPU usage of 2%. I am not sure what is going on to cause such high CPU usage, but if you are doing some polling I suggest throwing in the equivalent of a .Net Thread.Sleep(1) in the loop.
.
There is no polling in virtualhere is all fully optimized and async, no busy waits etc and written in gcc 6.3.0 c++ with -03 optimization.
That sounds about right regarding cpu usage with 14 devices. From previous profiling a most cpu time is in compressing/decompressing the usb signal. You can turn that off if you want but then you have lower network throughput as more data is being sent over the network.
To turn it off, exit the the client, edit the c:\users\username\appdata\roaming\vhui.ini file and create a transport section and add CompressionLimit and put a large value. The default is 384 bytes. So if the packet is > 384 bytes it is compressed. So make it a large number instead.
In the server there is a similar setting. Stop the server (ssh to the cloudhub and type /etc/init.d/vhusbd stop)
then edit the /root/config.ini and add the line
then save the config.ini and start the server again like this /etc/init.d/vhusbd start
now there will be no compression used. However the network throughput will suffer but give it a try anyway if you really need lower cpu
It didn't work...
I did what you recommended on both Client and Server. (On RPi CloudHub server I edited the file in Windows using Paragon ExtFS and verified it was actually written). I still have the same high CPU, although it might be a little less. I suspect the server is still compressing, because that is where most of the data is coming from. Compression is great for using USB devices over low bandwidth connections but isn't necessary for wired LAN where I am only using a tiny fraction of the capacity. The high CPU load will create a problem if there are many devices. VirtualHere would be far more useful to me and probably others if it was easy to turn off compression and shift the load from CPU to the network when appropriate. If it is actually possible to reduce the CPU usage I suggest a user option on Cloudhub and the Client. I also noticed that when the Client is running as a service, more than one Client Viewer can be opened. It would be better if there could only be a single instance, otherwise an uninformed operator could end up with dozens of VirtualHere clients lurking in the taskbar. Also, when running as a service, changes made on a Client Viewer don't update the ini file. (For example checking and unchecking "Auto-Find hubs" updates the ini file when not running as a service, but doesn't when it is.)
.
Yeah i disagree, from experience its better to leave compression always on. if its too slow i recommend a faster client computer...its always better to trade cpu for network throughput, and in exceptional cases, the ini can just be changed as explained above. I think you might have tried to edit the server config.ini while the server was running. thats why it didnt pickup the change. There is a watchdog in the cloudhub to restart the vhusbd daemon if it stops so you need to call /etc/init.d/vhusbd disable first then /etc/init.d/vhusbd stop then edit theconfig.ini file then /etc/init.d/vhusbd enable then /etc/init.d/vhusbd start
The multiple viewer thing is a bug, that i can fix in an upcoming build.
Regarding the ini file, actually when running as a service it saves it in
C:\WINDOWS\system32\config\systemprofile\AppData\Roaming\vhui.inidirectory. When you turn off auto-find, it really is off but you would see the the existing servers you have already connected to until you either reboot or stop/start the service. It works the same way as the normal client, that is if the auto-find is originally on and then you turn it off, it wont drop the connections to the existing servers. Until you restart the client. I think this the logical way to do it. Although with the service it is a bit confusing because the service is alway running. This is why there is the flag
-bto install service with auto-find off by default to sort out this issue..
On the RPi Cloudhub server I actually removed power, put the SD card in my laptop and edited the config.ini file, then restored power to the server with the changed SD card. I am absolutely sure that config.ini has CompressionLimit=500000 in it. Have you checked lately that this will actually turn off compression? Since you always run compression there may have been some program changes since the last time you tested it.
Let me put some numbers to the situation I am in... Every spectrometer I add uses about 1.5% of CPU, but adds less than 0.1 % to network usage. I have only those devices on a Gigabit LAN. At 1.5% CPU each I will run out of CPU on the 66th device, if no other programs were running, which of course there are. I want to use the least CPU possible for VirtualHere because there are other processor intensive programs running. I have plenty of bandwidth but limited CPU. When I was testing the Coolgear USBG-4NET, the network usage was about the same at 0.1% per device, but the Coolgear USB Server.exe uses almost no CPU, so probably isn't using compression. But the Coolgear has a lot of latency compared to VirtualHere. Overall it has the same data throughput, just with a delay, so even without compression I don't think it is going to use up much more bandwidth. I am testing this on modern computers, I would need to spend a lot of money to get an appreciably faster CPU.
I am using 2 different kinds of spectrometers. The Aseq uses the windows HID driver so uses 64 byte packets. The Avantes spectrometers use their own driver so I don't know other details. Until 2 days ago I only tested this with Aseq devices on Win7 64 bit. When I moved it to a Win7 32 bit computer with both Aseq and Avantes spectrometers, initially only the 7 Avantes spectrometers that were plugged into a WAVLINK WL-UH3074 hub were detected by Virtualhere. But before long I was prompted to install some drivers. After the new drivers loaded I could not get the WAVLINK hub to work. But if an Avantes spectrometer was plugged directly into the RPi or the other hub (with 9 Aseq devices) they would be seen. Sometimes the Aseq devices would work and sometimes not. After a few hours of troubleshooting... Many reboots, plug and unplug devices, etc. I took the RPi and WAVLINK hub to the Win7 64 bit computer and suddenly the WAVLINK started working and Aseq devices plugged into it worked just fine.
After returning the RPi and WAVLINK to the Win7 32bit computer the WAVLINK also worked there, however weird things were still going on. I eventually figured out that if I only had 5 of the Avantes devices plugged in (with 9 Aseq) everything worked fine. But if I plugged in more than 5 Avantes devices the Aseq devices would suddenly have communications problems, some would work, some not. I checked the RPi server CPU with 5 Avantes and 9 Aseq devices running and it was only at 8%. There is no problem when more than 5 Avantes devices are plugged into the PC directly or going through the CoolGear device.
I don't know how to troubleshoot further what is happening with more than 5 Avantes devices, but I assume I can live with it by just getting more RPi servers. (In progress) There will be many RPi servers at full scale anyway, so not a big deal. However, the high CPU usage will put me in a bind when I try to scale this system. If I can't get the CPU usage down I will need a different solution for the systems with a large number of devices. Any help or comments you have would be appreciated.
.
I know what is happening, you are trying to use too many devices on an UNpowered hub. You must use a separately powered hub.
.
Both hubs are powered. The RPi by itself can only power 2 spectrometers with the power supply I am using on it.
.
Are you sure? doesnt look like it to me http://www.anyware.com.au/wl-uh3074.html
.
What I actually have is a Wavlink Model WS-H3074 which is a 7 port USB 3.0 hub with a 4-amp power
supply. (The WS-H3074 is a WL-UH3074 packaged with a power supply.)
Also using a Sabrent Model HB-U14P 13 port USB 2.0 hub with a 2.5-amp power supply.
.
13port with 2.5 amp is far too low. It should be at least 6 amps (500ma per port on usb 2), and i think 900ma per port for usb 3 at an absolute minimum..
Check out the bolded sentence at the bottom of the page https://www.sabrent.com/product/HB-U14P/13-port-usb-2-0-hub-power-adapt…
.
The Aseq devices use 0.15 amps each. 9 X 0.15 = 1.35 amps which is well within the 2.5 amp Sabrent power supply capabilities. The Avantes devices use 0.4 amps each. 7 X 0.4 = 2.8 amps each which is less than the 4 amp limit of the Wavlink power supply. Even if I plug the Avantes spectrometers into an extra Wavlink hub I have the same problem. I am not overloading the power supplies of the hubs. In any case... I regret bringing up this issue which can be solved by adding more RPi. My primary concern is the high CPU usage of the client which will set a hard limit on the number of devices I can add. Is there any hope in reducing the CPU usage?
I think you need a better
I think you need a better client computer, what spec is the one you are currently using?
I am testing this on a i5
I am testing this on a i5-4570 3.2Ghz and i5-5300 2.3 Ghz. In any case I want to minimize the client cpu usage so that the hardware requirements are minimized. I don't want to require CPU upgrades everywhere I install this equipment. I have comparatively unlimited bandwidth compared to CPU. If need be I can easily add a gigabit LAN to any PC, but upgrading a CPU is considerably more expensive and involved. I am at the beginning of a large project which could affect many existing PCs and use 100's of new RPi servers at locations around the globe. (RPi servers and associated PC within 100 meters of each other on a wired LAN)
From what I understand the client cpu usage is mostly coming from compression/decompression. I tried to shut it off with the instructions you sent earlier with CompressionLimit=500000 to no avail. I don't know how I could have screwed it up. The question in my mind is, did the compression get shut off and it is still using a lot of cpu or is the compression still on? How can I know?
.
There is no way to tell if its using or not using the CompressionLimit.
But if you have put that value in and the server starts and runs then you can assume that the CompressionLimit is in operation.
From your earlier comments I
From your earlier comments I understand you put a lot of work into optimizing bandwidth usage. You may also want to consider a mode that optimizes cpu usage. This is sure to be an issue for others as well. I am still thinking that somehow the compression must not be shutting off, it is the only thing I can think of that would account for the cpu usage I am seeing if there are no loops and busy waits. In another program I am doing considerable manipulation and logging of the same data and the cpu usage is much lower.
.
Ok ill think about adding that at some later point.
1% cpu per device seems ok to me, the computer has to do some work to transmit the usb signal so it will never be 0%...