Client mouse jerky

[[deleted]]

The mouse is regularly jerky and "low frame rate" when using my mac book pro as my client.

The trackpad on the client is smooth. 

It's the only problem outside of the "needing to hit F12" problem that makes synergy 2 not yet ready for prime time here.

I'm on beta 3 of synergy and public beta 3 of high sierra, but I had the same mouse delay/jerkiness problems on Sierra too. High Sierra comes out in a bit more than a month. You guys might not be explicitly supporting it yet, but thought I'd drop a note since lots of users will be on high sierra by the time Synergy 2 is launched.

Also, new in beta 3 seems to be synergy using 3.6-7.8% of a cpu.

Happy to provide video or system info.

 

[Nick Bolton]

Hmm, could you try running a ping between your computers? I want to see if there are any ping spikes.

[[deleted]]

Looks like there's definitely ping delays, both on my 5ghz and normal network. I guess I'll look into my wifi being sketchy! Is this a pretty typical problem for your customers?

 

4 bytes from 192.168.1.102: icmp_seq=45 ttl=64 time=5.643 ms
64 bytes from 192.168.1.102: icmp_seq=46 ttl=64 time=1.828 ms
64 bytes from 192.168.1.102: icmp_seq=47 ttl=64 time=1.653 ms
64 bytes from 192.168.1.102: icmp_seq=48 ttl=64 time=4.343 ms
64 bytes from 192.168.1.102: icmp_seq=49 ttl=64 time=2.506 ms
64 bytes from 192.168.1.102: icmp_seq=50 ttl=64 time=4.232 ms
64 bytes from 192.168.1.102: icmp_seq=51 ttl=64 time=2.587 ms
64 bytes from 192.168.1.102: icmp_seq=52 ttl=64 time=45.972 ms
64 bytes from 192.168.1.102: icmp_seq=53 ttl=64 time=9.866 ms
64 bytes from 192.168.1.102: icmp_seq=54 ttl=64 time=121.064 ms
64 bytes from 192.168.1.102: icmp_seq=55 ttl=64 time=230.707 ms
64 bytes from 192.168.1.102: icmp_seq=56 ttl=64 time=1.790 ms
Request timeout for icmp_seq 57
64 bytes from 192.168.1.102: icmp_seq=58 ttl=64 time=53.638 ms
64 bytes from 192.168.1.102: icmp_seq=59 ttl=64 time=106.358 ms
64 bytes from 192.168.1.102: icmp_seq=60 ttl=64 time=236.659 ms
64 bytes from 192.168.1.102: icmp_seq=61 ttl=64 time=37.172 ms

 

[Nick Bolton]

Does this keep happening even when you close Synergy? If not, keep closing apps until it stops happening.

Why does it happen? Because there's an app running that's querying your wifi adapter. When the wifi adapter is queried (e.g. to check signal strength, available networks, etc) this can cause the wifi device to be interrupted (causes the ping spikes).

[[deleted]]

Yes, this still happens with synergy closed.

Pinging my router from both server/client looks great and only deviates a bit sometimes under heavy network traffic:

 

64 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=1.774 ms
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=1.415 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=2.041 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=1.894 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=2.165 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=2.122 ms
64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=2.616 ms
64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=2.087 ms
64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=2.081 ms
64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=2.641 ms

 

[[deleted]]

I've rebooted and closed apps and removed startup items. Nothing I do really gets the ping to another machine under 5ms reliably and there's always jumps to 200ms+. 

[Nick Bolton]

Hmm, that's gotta be super annoying. Is using Ethernet an option? I know it's not very seamless, but wifi can be like that sometimes.

[Paul Suarez]

2 hours ago, Nick Bolton said:

Does this keep happening even when you close Synergy? If not, keep closing apps until it stops happening.

Why does it happen? Because there's an app running that's querying your wifi adapter. When the wifi adapter is queried (e.g. to check signal strength, available networks, etc) this can cause the wifi device to be interrupted (causes the ping spikes).

Hey @Sudara. Let me also add something about it. I'd say it could be normal to networks where their DNS server is also the router. That's because every time your machine tries to load hostnames, sites or anything that requires it to translate from human-readable to machine-readable IP addresses. 

Also, most Wi-Fi networks created by routers are just blasting the WiFi signal around it. It resembles an " Ethernet Hub" or a "Network Hub" in a wired network. Although, there's a newer technology used nowadays. It's called "beamforming." Instead of blasting the data packets intended for your device, it directly sends it to it. This one resembles a "Network Switch" for the wired network.

If having it wired is not really an option for you. You can either install a WiFi channel scanner on your smartphone and set your WiFi network to a channel which less collides with other WiFi networks you can detect or set QOS on your router.

[[deleted]]

Hi guys!

I do have a nice beamforming router and I've been looking into my setup. All seems well, but the ping times look pretty hairy.

Interesting fact #1:

Ping times from both computers on WIFI regularly < 1-3ms to reach the router. There are no bumps or large variances.

Interesting fact #2

Ping times from both computers to router or each other are < 0-2ms when both computers are plugged into ethernet.

Interesting fact #3

Ping times when running 10 pings a second on WIFI are < 2-3ms to reach the computer. There are no bumps.

I got the idea to run 10 pings a second from https://superuser.com/questions/1142798/experiencing-high-latency-on-wifi-every-other-second-with-macos-sierra#comment1642578_1142798

So either the ping times are a red herring — or there is a delay in the external interface of the osx wifi card responding due to power savings, or...

 

$ sudo ping -i 0.1 192.168.1.101
PING juno.local (192.168.1.101): 56 data bytes
64 bytes from 192.168.1.101: icmp_seq=1 ttl=64 time=1.928 ms
64 bytes from 192.168.1.101: icmp_seq=2 ttl=64 time=2.409 ms
64 bytes from 192.168.1.101: icmp_seq=3 ttl=64 time=2.644 ms
64 bytes from 192.168.1.101: icmp_seq=4 ttl=64 time=2.429 ms
64 bytes from 192.168.1.101: icmp_seq=5 ttl=64 time=2.725 ms
64 bytes from 192.168.1.101: icmp_seq=6 ttl=64 time=2.441 ms
64 bytes from 192.168.1.101: icmp_seq=7 ttl=64 time=2.429 ms
64 bytes from 192.168.1.101: icmp_seq=8 ttl=64 time=2.399 ms
64 bytes from 192.168.1.101: icmp_seq=9 ttl=64 time=2.413 ms
64 bytes from 192.168.1.101: icmp_seq=10 ttl=64 time=2.096 ms
64 bytes from 192.168.1.101: icmp_seq=11 ttl=64 time=2.323 ms
64 bytes from 192.168.1.101: icmp_seq=12 ttl=64 time=2.352 ms
64 bytes from 192.168.1.101: icmp_seq=13 ttl=64 time=2.513 ms

 

[Nick Bolton]

Are you able to use ethernet for testing? It'll be interesting to see if the issue still exists when using ethernet.