Mouse cursor polling rate causing massive lag on remote device... Possible bug? [with details]

"Christopher Woods" <[email protected]>
Newsgroups gmane.network.vnc.user,gmane.network.vnc.realvnc.general
Organization CustomMade Solutions
Message-ID <EC0083B6FB344902B0C5052DCBB4B544@mofolaptop>
Hi list,

Searched elsewhere but couldn't find any relevant discussions. I may have
stumbled upon a bug...

I've noticed that I can consistently reproduce a scenario whereby MASSIVE
lag is induced in the remote device as soon as the mouse cursor is moved
rapidly or any window is dragged / any motion involving the mouse is
involved. The fault seems to be the VNC client on the controlling machine
not adequately throttling mouse events, thereby overloading the remote
device. 100% CPU usage is observed on the remote device and the display and
actions on the device are noticeably slowed down almost to a crawl.

Both devices are connected via GigE through a Netgear ProSafe switch and
short runs of ethernet cable, and both are running XP SP3 with an identical
antivirus/malware/firewall config (Kaspersky 2009). I tried all sorts; in
the end rate limiting the mouse events in the VNC client worked as a
temporary measure, but I did not feel this was a sufficient solution.

What's causing it is an unusual but predictable culprit: my Razer DeathAdder
mouse. It's a gaming mouse, and therefore has the potential to reach
ridiculous polling rates and DPIs. By default, I use it in its 1,000Hz
polling rate mode (I FPS game in my spare time and 1,000Hz is its default
setting - because you *know* those extra few nanoseconds make all the
difference between a torso and headshot! ;) The polling rate is switchable
between 125Hz, 500Hz and 1,000Hz via the DeathAdder control panel which
loads as a system tray applet; in 500Hz mode, there is occasional lag when
extreme/violent actions, but in 125Hz mode the behaviour of the remote
device is exactly as you'd expect... It works perfectly. I can grab a
window, drag it around and violently shake it to all extremes of the display
- and the remote device updates perfectly, just as you'd expect, with the
expected higher - but not maxed out - CPU usage.

When I reverse the setup, and remote control machine A with machine B, mouse
inputs and local/remote refresh work exactly as expected, but that is not
unusual as the other machine is a laptop (so only has a trackpad polling at
the standard 100Hz). Other SMB / FTP transactions, pings etc all work at the
expected throughput rate for a gigabit ethernet connection, so there is no
issue with rate negotiation by the devices' NICs.

It's an unusual set of circumstances that are prompting this bug into
existence, but I can't be the only person out there with a quick-polling
mouse who's observed this problem. Have I uncovered a hitherto unknown bug,
or has this already been acknowledged as something for the RealVNC devs to
fix for a future release?

Cheers
Chris


_______________________________________________
VNC-List mailing list
[email protected]
To remove yourself from the list visit:
http://www.realvnc.com/mailman/listinfo/vnc-list
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.