github-starred/barrier

Fork 0

mirror of https://github.com/debauchee/barrier.git synced 2026-05-15 14:16:02 -06:00

[GH-ISSUE #1755] Extreme mouse and keyboard lag on client laptop over wifi unless a speedtest is running in the background #1294

New issue

Open

opened 2026-05-05 07:42:23 -06:00 by gitea-mirror · 3 comments

gitea-mirror commented

2026-05-05 07:42:23 -06:00

Owner

Originally created by @chrisJuresh on GitHub (Aug 24, 2022).
Original GitHub issue: https://github.com/debauchee/barrier/issues/1755

What happened?

I have a server connected over ethernet (arch) which works fine with my client windows laptop, but my client arch laptop is incredibly laggy, unless a speedtest is running in the background. I'm assuming this is because if wifi is not being used it goes in some sort of sleep mode unless constantly woken up?

Version

v2.4.0

Git commit hash (if applicable)

No response

If applicable, where did you install Barrier from?

No response

What OSes are you seeing the problem on? (Check all that apply)

Linux

What OS versions are you using?

The issue is when Linux is on both.

Windows client works fine

Relevant log output

No response

Any other information

No response

Originally created by @chrisJuresh on GitHub (Aug 24, 2022). Original GitHub issue: https://github.com/debauchee/barrier/issues/1755 ### What happened? I have a server connected over ethernet (arch) which works fine with my client windows laptop, but my client arch laptop is incredibly laggy, unless a speedtest is running in the background. I'm assuming this is because if wifi is not being used it goes in some sort of sleep mode unless constantly woken up? ### Version v2.4.0 ### Git commit hash (if applicable) _No response_ ### If applicable, where did you install Barrier from? _No response_ ### What OSes are you seeing the problem on? (Check all that apply) Linux ### What OS versions are you using? The issue is when Linux is on both. Windows client works fine ### Relevant log output _No response_ ### Any other information _No response_

gitea-mirror commented

2026-05-05 07:42:26 -06:00

Author

Owner

@weelillad commented on GitHub (Aug 31, 2022):

Chiming in to share that I encounter similar issues with a Windows server and a Linux (elementaryOS) client, both using barrier 2.4.0. Some additional observations I have:

It is always fine after a client reboot, and only starts becoming noticeable if I don't reboot the client for more than a day. Restarting barrier does not fix the issue.
If I keep the mouse in constant motion, it is smooth. But the moment the mouse stops moving, even momentarily, when I next move the mouse there will be noticeable lag before the pointer starts moving.
The client laptop is immediately responsive when using the built-in keyboard and mouse, and in all other operations (e.g. using the web browser).

@weelillad commented on GitHub (Aug 31, 2022): Chiming in to share that I encounter similar issues with a Windows server and a Linux (elementaryOS) client, both using barrier 2.4.0. Some additional observations I have: 1. It is always fine after a client reboot, and only starts becoming noticeable if I don't reboot the client for more than a day. Restarting barrier does not fix the issue. 2. If I keep the mouse in constant motion, it is smooth. But the moment the mouse stops moving, even momentarily, when I next move the mouse there will be noticeable lag before the pointer starts moving. 3. The client laptop is immediately responsive when using the built-in keyboard and mouse, and in all other operations (e.g. using the web browser).

gitea-mirror commented

2026-05-05 07:42:27 -06:00

Author

Owner

@acheronfail commented on GitHub (Jan 9, 2023):

As another data point, I'm also seeing this with a Linux server and a Windows client. (both wifi)

As an easy way to demonstrate the issue, is to run a speedtest between the two machines using something like iperf3. For example:

Linux host

iperf3 -s

Windows host

iperf3 -c host.ip.address

While the speedtest is running between the machines, barrier has almost no latency whatsoever and works wonderfully.
As another point, it seems it's only the client that needs network activity? If I run the same speedtest between the client and my router then it works just as well.

So, pretty much anytime the client machine is heavily using its network there's no problem, but when there's no other activity then it's laggy...

I've tried various methods and power modes for the wifi adapter on the client, all to no avail.

@acheronfail commented on GitHub (Jan 9, 2023): As another data point, I'm also seeing this with a Linux server and a Windows client. (both wifi) As an easy way to demonstrate the issue, is to run a speedtest between the two machines using something like `iperf3`. For example: Linux host ```bash iperf3 -s ``` Windows host ```bash iperf3 -c host.ip.address ``` While the speedtest is running between the machines, barrier has almost no latency whatsoever and works wonderfully. As another point, it seems it's only the client that needs network activity? If I run the same speedtest between the client and my router then it works just as well. So, pretty much anytime the client machine is heavily using its network there's no problem, but when there's no other activity then it's laggy... I've tried various methods and power modes for the wifi adapter on the client, all to no avail.

gitea-mirror commented

2026-05-05 07:42:28 -06:00

Author

Owner

@i1u5 commented on GitHub (Jan 30, 2023):

Can reproduce, also Linux server and Windows client (Linux on WiFi and Windows on Ethernet). Starts lagging/freezing after a few hours of connection, restarting server doesn't fix it, and neither does reloading the client (or individually restarting Bonjour/Barrier services), sometimes it straight up disconnects:

[2023-01-30T22:07:55] INFO: entering screen
[2023-01-30T22:08:05] INFO: leaving screen
[2023-01-30T22:10:00] NOTE: server is dead
[2023-01-30T22:10:00] WARNING: failed to connect to server: server is not responding
[2023-01-30T22:10:01] NOTE: connecting to 'HOSTIP': HOSTIP:24800
connected to server
[2023-01-30T22:10:56] NOTE: server is dead
[2023-01-30T22:10:56] WARNING: failed to connect to server: server is not responding
[2023-01-30T22:10:57] NOTE: connecting to 'HOSTIP': HOSTIP:24800
connected to server

Linux server does not lose internet access or signal when it happens so that can be ruled out.

@i1u5 commented on GitHub (Jan 30, 2023): Can reproduce, also Linux server and Windows client (Linux on WiFi and Windows on Ethernet). Starts lagging/freezing after a few hours of connection, restarting server doesn't fix it, and neither does reloading the client (or individually restarting Bonjour/Barrier services), sometimes it straight up disconnects: [2023-01-30T22:07:55] INFO: entering screen [2023-01-30T22:08:05] INFO: leaving screen [2023-01-30T22:10:00] NOTE: server is dead [2023-01-30T22:10:00] WARNING: failed to connect to server: server is not responding [2023-01-30T22:10:01] NOTE: connecting to 'HOSTIP': HOSTIP:24800 connected to server [2023-01-30T22:10:56] NOTE: server is dead [2023-01-30T22:10:56] WARNING: failed to connect to server: server is not responding [2023-01-30T22:10:57] NOTE: connecting to 'HOSTIP': HOSTIP:24800 connected to server Linux server does not lose internet access or signal when it happens so that can be ruled out.

No labels

Rows
Columns