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
VNC-List@realvnc.com
To remove yourself from the list visit:
http://www.realvnc.com/mailman/listinfo/vnc-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
VNC-List@realvnc.com
To remove yourself from the list visit:
http://www.realvnc.com/mailman/listinfo/vnc-list