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