KVM/IP abysmal performance prior to client version 5.7.5 when mouse is using a high polling rate

Submitted by AtmanActive on #1

Hi,

I understand that VirtualHere KVM/IP is a brand new product and I do support the idea and further development of the system. 
I don't regret my purchase at all.

That being said, I did have a rather disappointing experience with it so I wanted to double-check if I'm doing something wrong here.

 

  1. Abysmal performance: it literally takes 3 (three) seconds for the mouse pointer to catch-up my mouse sweep from one side of the screen to the other. In other words, the lag and the speed of the video transfer is so slow it is unbearable. While the server image is catching up, if I try to press, right mouse button, for example, the lag forces me to wait for the mouse pointer movement animation to finish and only then do I see the context menu painted on the screen. This means that the real-world lag is indeed a few seconds and as such makes the whole thing unusable, except, maybe, for poking around the BIOS.
    This is all happening in my room with three machines all connected to a single 2.5Gbps switch: 
    - my Workstation machine, Windows 10 Pro x64 on Intel i9-9900T, with 1Gbps network connection, this is the CONTROL machine
    - my Studio machine, Windows 10 Pro x64 in Intel i9-12900T with 2.5Gbps network connection, this is the TARGET machine (1920x1080x60)
    - my Connector machine, Linux Mint 21.3 Cinnamon x64 on Intel J4125 with 1Gbps network, this is the VIRTUALHERE machine, the 'top' command over SSH terminal shows ~20% CPU usage from vhusbdx86_64. I did install both Generic and Goldmont Plus version - no change. Changing resolution on the Client changes nothing - the screen becomes more blurry or sharper, but the lag is always the same.
  2. No way to set the window size: I can only stretch the Client display window manually, but there is no built-in way to resize the window to achieve 1:1 display (nor 1:2, 1:4 for that matter). The "Resolution..." menu does change the streaming resolution from the Capture device, but it doesn't appropriately scale the client display window. So, the only way to resize the client display window is manually, by dragging the edges with the mouse, but matching the original resolution in that way is next to impossible.
  3. The one-device-only-in-trial-mode clashes with KVM/IP since KVM/IP needs two devices to function. Therefore, KVM/IP can't be used in trial mode and, consequently, can't be tested on different hardware to establish if that plays any role in the performance or not. 

 

Please let me know if this is the expected behavior or is there something wrong on my end.

Thanks.

 

 

Submitted by Michael on Thu, 2024/08/15 - 06:51

#3

  1. That's definitely is not right. The latency should only be about the network latency. See here for an example i just made this is from my laptop over wifi to a pi5 server with an NUC target. I have seen this issue before if the USB-C cable is not properly seated in the emulator. Could you double check that. Also plug the hub into another USB port just to be sure. Ive also seen this issue if you use a cheapy amazon USB hub with a single Transaction Translator. But if you are using the VirtualHere hub this wont be an issue.
  2. The input resolution is downsampled to whatever is selected in the resolution settings (default is 1920x1080x30). The input resolution e.g 4k always stays the same.   So you are saying if e.g the input resolution is 4k it would be nice to have an option to display 1/4 size or basically some nicer fixed sizes and auto resize the video window to this size? I can investigate making that change
  3. Yes VirtualHere wont work on trial with multiple devices. The KVM/IP system doesn't demand much from the server side so it works with almost all hardware. Ie. no point testing different server hardware. Ive even tried it with a GL-AR300m16 router box which is only a 650Mhz MIPs CPU and it works ok at full resolution. Only skips a bit.

Submitted by AtmanActive on Thu, 2024/08/15 - 19:21

#4

Thanks for the prompt answer.

 

  1. I will investigate the connections and will let you know.

  2. The best approach, in my opinion would be to add one more menu right under "Resolution..." which would be, for example "Window..." and which would offer 1:1 (pixel perfect), 1:2 (reduction), 1:4 (reduction), 2:1 (magnification), and 4:1 (magnification). When selected, VirtualHere client would attempt to set the client window size to match the calculated resolution, taking into the account window borders and the title bar. 

    One huge annoyance when working with desktop-remote-screens is the fact that the title bar takes about 32 pixels, making it impossible to display 1080p remote screen on a 1080p control desktop in 1:1 pixel perfect picture unless going full screen. Since I'm using ultrawide monitor with 2560x1080 resolution, then, going fullscreen on a 1920x1080 remote is a waste of screen real-estate. Since I couldn't find a way to show a remote screen in a window without borders or the title bar, I had to resort to creating a custom resolution on the remote: 1920x1000 which I could then see on my desktop with 1:1 pixel accuracy and the window border and the title bar and the taskbar. I'm guessing, this will be impossible with VirtualHere, since the USB grabber has only well-known resolution support? In that case it would be ideal if you could display the window without any borders and without the title bar, in 1:1 pixel accuracy, centered on the client desktop. But I'm not sure this is possible either. I believe Windows doesn't allow any window to overlap the taskbar. Therefore, the usable desktop (not full screen) area is always some ~80 pixels shorter than client's resolution. Any ideas how to overcome this?

 

Thanks.

Submitted by Michael on Fri, 2024/08/16 - 19:01

#5

Currently the capture works like this: On the target, the full resolution (up to 4k) is sampled (in hardware) to the resolution specified in the client (e.g 1920x1080 or 800x600 etc) and compressed into jpg, it is then transmitted over the network. The image is then scaled again up or down to fit perfectly into the window on the client (no part of the target screen ever missed so the entire target screen is always rendered, the titlebar/frame is taken into account when scaling) the image is then sent to the video card on the client for rendering, this is done many times a second.

If the title bar is hidden then it will be difficult to have an options menu. I could add a hotkey to switch to a title/untitled frame so that is can be hidden, but you will then have trouble moving that window around the screen so its also a bit of a problem. Im not sure its a good idea to do either of these things as a general use-case.

Submitted by AtmanActive on Sat, 2024/08/17 - 17:26

#6

So, there is no way to ask the grabber for a custom resolution, right?

Submitted by Michael on Sat, 2024/08/17 - 19:14

#7

No, only the resolutions shown in the virtualhere client. 

Submitted by AtmanActive on Sat, 2024/08/17 - 20:19

#8

Alright.

I'm now testing if I could go with 2880x1200 on my workstation ultrawide monitor, which would enable me to see 1920x1080 remote in a window, plus the window frame, plus the window title bar and plus windows taskbar.

Monitor's native resolution is 3840x1600, but at that resolution everything becomes so tiny, it is unreadable.

Submitted by Michael on Sat, 2024/08/17 - 20:39

#9

Is the speed ok now?

Submitted by AtmanActive on Mon, 2024/08/19 - 22:08

#10

No it is not.

I tried:

  • disconnecting/reconnecting all the cables and dongles: no change
  • plugging the hub into each and every USB port on the Connector machine: no change
  • replacing your hub with my powered hub: no change
  • connecting both dongles directly into the machine without any hubs: no change

What I did notice is that the lag seems to increase over time. Whenever I would shuffle the connections and reconnect again, for first few seconds it would look like it is finally working correctly, only to start lagging more and more each passing second.

Please advise.

 

Submitted by Michael on Tue, 2024/08/20 - 05:49

#11

In the virtualhere client use the kvm/ip devices then right click USB Servers->About->Statistics. What does that generally show?

Submitted by Michael on Tue, 2024/08/20 - 17:57

#13

Do you have e.g anydesk so i can login while you are there and take a quick look? If so email me mail [at] virtualhere.com (mail[at]virtualhere[dot]com)

Submitted by AtmanActive on Tue, 2024/08/20 - 18:01

#14

By the way, that same machine has an SPDIF/TOSlink optical audio input USB device and has been streaming PCM 24-bit/48kHz audio using Sonobus flawlessly for months now.

Submitted by Michael on Tue, 2024/08/20 - 19:21

#15

This was resolved by updating to client 5.7.4

Submitted by AtmanActive on Tue, 2024/08/20 - 19:26

#16

Actually, no, it wasn't.

I believe I know what's the problem: the mouse polling rate.

While you were connected via RustDesk, it all worked perfectly fine for you. But when I test the same thing I get that horrible lag back again. So, what is different? The mouse. I have a Logitech G604 mouse with the polling rate of 1000Hz. If I don't touch the mouse and use my keyboard exclusively, then, everything is working correctly again. So I think you need a rate-limiter in your mouse-to-emulator code.

I will look for some plain mouse and will test with that to confirm.

 

Submitted by Michael on Tue, 2024/08/20 - 19:29

#17

Very interesting, that could be possible as its trying to send all those updates to the remote machine.  Turn it down and let me know how it goes.

Submitted by AtmanActive on Tue, 2024/08/20 - 19:42

#18

Yes, confirmed, using a "plain" mouse, everything is working as expected. The lag feels like something around 100-200ms, more or less same as in your video. Perfectly usable.

So that's it. That's the problem. Sending raw mouse data to your Emulator dongle overwhelms the dongle if the mouse has a high polling rate enabled.

Looking forward for a fix.

Thanks.

 

Submitted by AtmanActive on Tue, 2024/08/20 - 20:23

#19

Here is the screen recording:

 

https://atmanactive.me.uk/temp/virtualherekvmiptest3.mp4

 

But even when I lower the polling rate down to 125Hz, there are still some issues with the Emulator. 
Most of the time it is kind of working correctly, but, in select-and-drag situations it was letting the left mouse button go even though I was keeping the button pressed. (at 01:17 in the video)

 

Submitted by Michael on Tue, 2024/08/20 - 20:54

#20

"letting the left mouse button go even.."  

I notice you are dragging and sometimes the mouse exits the window while you are dragging which releases all buttons in the kvm/ip session.

This is expected behavior, if the mouse exits the KVM/IP session window e.g while dragging outside the frame even a bit, then it will release all buttons.  This is so that a button/\key doenst get "stuck down" if you accidentally move away from the window e.g repeating a key or scrolling continuously

 

Submitted by AtmanActive on Tue, 2024/08/20 - 21:15

#21

Understood.
Thank you.

 

Submitted by AtmanActive on Wed, 2024/08/21 - 20:00

#23

Yes, working correctly now.

Kudos for the quick fix and your relentless support.

Looking forward to seeing VirtualHere KVM/IP grow to become #1 solution worldwide.

Keep up the good work!

Thank you.

 

Submitted by Michael on Wed, 2024/08/21 - 20:03

#24

Great :)