Background and Solution Outline
This is a bit long, but the point is to educate via the Detailed Instructions section. If you're already educated, just read this section and possibly the conclusion ;-)
I have been using Synergy on Linux and Windows in its various forms since the 1990s, and this question pops up often. There are two common causes, and I deal here with the first only.
It's generally an OS-level issue, being the scheduler priority of the client, so the solution is simply to increase the client's priority. That will improve matters, but the overall experience will still be based on the scheduler's views on how important it is to update the screen, etc. See at the end for more on that.
Sometimes there is another reason: one or both of the server or client processes dies and gets restarted, in which case you should enable debug level logging on Synergy server and client, and take it from there. Once you're resolved that, implement the above.
Detailed Instructions
Increasing Windows client scheduler priority
Using Windows 7, I don't know the short-cuts in newer versions.
Open the Task Manager (Ctrl-Alt-Esc) and click on the Processes tab.
Right-click on synergy.exe, click "Set Priority", and choose either High or Realtime.
Repeat for synergyc.exe.
If Synergy server is too slow, its process is synergys.exe.
Increasing Linux client scheduler priority
Something similar should work on Mac. You might know how to do this in the GUI, but I use the command line. Unless you do the following as root (sudo su -
), you'll have to play around (as root) with visudo
and set up the relevant rights to use renice
.
ps -eo pid,ni,cmd |\
grep synergy |\
grep -v grep |\
cut -d" " -f2 |\
while read pid; do echo -n $pid" "; done |\
xargs renice -19
You can copy & paste the above, or put it on one line by removing all the \
and line break characters. If you want to see what will be run without actually doing it, change the last command to xargs echo renice -19
.
As stated above, this is still at the behest of the scheduler's view on the importance of lots of other processes. If you want to learn a bit, you can do the following.
Seeing Windows processes
Open the Task Manager. In the Processes tab, click on the button "Show processes from all users". Then click on the View menu, and on "Select Columns...". Make sure only the following are ticked: User Name, CPU Usage, CPU Time, Base Priority, Command Line. You can click on Description as well if you'd like.
You can drag the window as well as columns larger to ease reading. Click on a column header to sort by it. You can also right-click on an image name and, for example, go to the associated services. This is useful for such bland image names as svchost.exe. If you want a really powerful tool to play with (be careful!), try ProcessHacker.
Seeing Linux processes
Run ps -eo pid,ni,cmd | less
to see all running processes. Each line represents a process status, and the columns are: the process ID, its priority, and the command-line in question. A gotcha is that in Unix, the lower the nice value, the higher the priority.
Conclusion
The thing is that Synergy depends on a whole lot of other processes to do part of its work (such as dealing with the SSL in Pro), and each of these processes has a priority assigned to it by the OS scheduler. Thus there really is no simple solution.
Even after applying the "fix" referred to above, things are often slow after entering a client screen where you haven't been for a while, and that is due to this whole family of processes being put on the scheduler's back burner, so to speak. Most schedulers these days are adaptive, and decrease the priority of user processes which have been idle for some time. For the scheduler to see them as important again requires continued use for a while, such as moving the mouse around a lot after you enter the screen. It's a pain, but that's how OS schedulers work in non-real-time operating systems.
There are ways to tweak that, but it's very specific to each OS (even different releases), and fragile (read: breaks easily upon OS patches). Without looking at the code, I expect Nick & team would only really solve this by pushing Synergy down to kernel driver level, which would make it way more fragile, and cause a significant price jump.
Did you resolve this? The accepted answer is merely troubleshooting tips. What was the cause/solution for you? – Albert Bori – 2014-11-27T18:20:50.467
@AlbertBori wow - this was from 4 years ago. It isn't happening at this point for me, but I've got fresh OS installs, and a different desktop computer since then... I don't recall what the problem ended up being. Sorry – David Oneill – 2014-12-03T17:52:12.707
1No worries, David. This was the only post I could find that discussed the issue I was having. It turns out some form of restarting the services/computers involved usually clears up the issue. – Albert Bori – 2014-12-03T18:22:44.863
2Have you tried reversing the roles of the machines to see if it replicates the behaviour? Then you are at least ruling out a few options. – None – 2010-12-03T16:20:46.807
I have not, although that is not an option: using the mac as the client makes the keys screwy on the desktop (which is my primary machine) I will give that a try when I get a chance, though... – David Oneill – 2010-12-03T16:33:07.670