Slow network only when X is running

kafka0

kafka0

After re-installing my desktop PC with FreeBSD, I noticed that my network is awfully slow, but only when X is running.

In the console, I get my usual speed of approx 1.2MiB/s (download). This is the speed it used to run at, both with FreeBSD 11 and 12 before I re-installed.
If I start X and, for example, clone FreeBSD's GitHub repository, I can't get past 30 KiB/s. To be more precise, I had normal speed for about 5 minutes, and then I was stuck at that speed.
If I exit X, I get my normal speed back. Starting X again, my network gets super slow again... and so on.

I don't have much installed, and to be sure, I re-installed again and used packages instead of ports (in case I was doing something wrong): xorg, nvidia-driver, nvidia-xconfig, nvidia-settings, windowmaker, emacs, git. nvidia-driver would not install (complaining about an unrecognised ELF format for Linux compatibility), so I installed the port and disabled Linux compatibility.
My network interface uses the em driver.

I must say I am a bit mystified by the whole thing... I must be missing something really obvious, but I can't see what... Any thoughts?
 
How to you measure the speed? Show us some data.

Do you know whether other workload is running on the network? Here's my hypothesis: when X is running, other processes start hogging network resources, and your (unspecified) measurement tool has to share the bandwidth with other processes. You can use the standard tools (tcpdump, netstat, ...) to measure network usage.
 
Thanks for the reply. I haven't been using any network analysis tool so far, I just used downloaders of various kinds, as I was installing my system: git and texlive, for example. Both told me that my speed was abysmal.

I also did an exercise: with X running on the desktop, I used my laptop to do the same (i.e. clone a big repo from git). Using the same network, I got approximately the same speed (slow). Pinging also reveals that I lose a huge number of packets (26%). Now, my network is a bit complicated: there is a main access point that I do not control and that has a short WiFi range. I then have my own access point to extend this network, and attached to that, I have my own router (PC Engines APU2, with FreeBSD). Connecting to my router or the extender gives the same result: slow, even with the laptop, and packet loss. Connecting to the first access point results in the normal speed. When I quit X on the desktop, I get my normal speed back everywhere, and no packet loss.

I suppose that when X is running, something must be clogging the network up to the extender. I am not sure how I can capture that, though. I can of course make a dump with tcpdump, but I am not sure I would be able to decipher it myself. Would you have a pointer to a guide I could use?

Edit:
I would add that netstat doesn't show anything particular when I do:
netstat -nap tcp
I only see the connections I know about (listening on :22, sendmail listening on :25 and the ongoing connection to GitHub on :443, when I run that). Not sure how I should run netstat to get more info. I ran tcpdump as well (tcpdump -n -vv), and, with X running, unless I am cloning from GitHub for example, the tool reports no packet at all.
I also ran
sockstat -4
And as expected, got the same result as with netstat: no surprise in the list.
Then
netstat -w 5 -d
while cloning or pinging doesn't show any error or drop, but the ping session this time saw 62% of packet loss.

To be noted: my laptop was playing a video on Youtube at the time, and got stuck. The very moment I closed X on the desktop, the video and all the rest downloaded instantly.
 
Well... I still don't understand what really going on, but I stopped dbus (required by Firefox) and tested again: everything is back to normal.
Not sure what's happening here... how can I grab the traffic or trace the activity around X and dbus?
 
The most plausible answer is that your desktop is using an enormous amount of bandwidth. To debug that, you just need to learn how to use tcpdump. It's not very hard: if your ethernet interface is called "emX", then "tcpdump -i emX" will get you started. The lines will fly by very fast, so hit control C after a second or two, then read the lines. Each is pretty clear: Traffic from node.port > node.port (you need to learn common port numbers like 80 for http and 443 for https, and so on, those are in /etc/services), and the length of the packet at the end. You should set your shell window to be very wide (120-150 characters?), so each packet fits on a single line; makes reading easier. This should give you a flavor of what is happening on your network. There must be some tcpdump tutorials out on the network. There are also GUI-based wrappers around tcpdump, such as wireshark. A friend of mine helped implement one of those, and used it heavily. But for basic network debugging, tcpdump is hard to beat, and it's available most everywhere.

There is another possibility: That your desktop is doing something that breaks one of your (bizarre) network components upstream. That will be much harder to debug.
 
Just saw the message about dbus: Again, tcpdump is your friend: Look at it when quiet. Then start up dbus again, and see what traffic shows up.
 
Thanks for the replies!

I actually have some knowledge of tcpdump and I have a decent, non-netadmin understanding of networks, but, like I said above, running tcpdump -n -vv for example, shows absolutely no traffic whatsoever when only X is running, with or without dbus. No luck either with UDP. So I guess I need to learn some more about tcpdump to capture the lower layers.

By the way, I just tested again... and I must be tired, because now even without bus, X brings the network to a crawl.
Must be too tired to think straight, will get back to this tomorrow.
 
Check you system with systat -vmstat. When X is running you might be getting an interrupt storm for some reason (look for interrupts with 3 or more digits in their number). That in turn could cause all sorts of slowdowns. Also keep an eye on your CPU stats, something might be hogging it (which could also cause slowdowns on other applications/services).
 
Thank you for suggesting that, there definitely is a big difference... but maybe in the way opposite to what we expected.
When I run X and I download something, I see around 20 interrupts for my network card (and the net is super slow).
When I do not run X and I download the same thing, I see 860+ interrupts for the network card, and the net is normal. CPU is also higher here (but the total load itself remains super low, like 1%).
I see no interrupt under X for the network card when I'm not downloading anything.

Not sure where this can be coming from... devd? Quite confused, as I never had any issue before with this machine, even with 12.
 
Could it be that starting X (and the whole desktop environment thing that goes with it) reconfigures your network? I know that desktop environments contain intelligent network configurators (since they are designed towards mobile environments, like laptops being used in coffee shops).

Suggestion for debugging: Turn of X. Take the output of all network status commands you can think of (ifconfig -a, netstat, ...), and save it in a file. Then start X, run the same commands, save it in a second file. Diff the files. Some differences are natural (statistics, time of day); see whether your network configuration has significantly changed.

Sorry, I don't have better suggestions ...
 
For diagnosing that kind of problems, try installing the trafshow package (port net/trafshow). It's a small CLI tool that is a bit similar to top(1), but displays network traffic instead of processes. It accepts the same filter expressions as tcpdump(1). For example:
trafshow -i re0 not port 53
That displays all traffic on your re0 interface, except for DNS (port 53).

By the way, in the “old times” (last century), I would have suspected that your network card and graphics card share the same interrupt. Interrupt sharing was known for causing such kinds of performance problems. However, in the days of PCIe that shouldn't be a problem anymore.

EDIT: Sorry, I should have read the newer replies, too … So trafshow won't help in this case, because there is no traffic.
 
I do not use a desktop environment, only X and very simple window managers (dwm, windowmaker, StumpWM...).
I basically did all you suggest here yesterday, but the issue in the end doesn't seem to have anything to do with network traffic, but rather a software/hardware issue. The first true difference I've seen so far between X and the console is the number of interrupts. See above: I have loads in the console, and almost none under X. I ran the same thing on a laptop with FreeBSD 12 (same version of Xorg, etc.) and I have loads in the console, and also loads under X, where my net is normal.

I have now removed all packages and am trying to carefully configure and compile the ports, to try understand what's going on.
I also just sacrificed a chicken, as documented in the FreeBSD Handbook for the Truly Desperate.
 
olli@ said:
For diagnosing that kind of problems, try installing the trafshow package (port net/trafshow). It's a small CLI tool that is a bit similar to top(1), but displays network traffic instead of processes. It accepts the same filter expressions as tcpdump(1). For example:
trafshow -i re0 not port 53
That displays all traffic on your re0 interface, except for DNS (port 53).
Click to expand...

Hmm, didn't know about this tool. Even though it's starting to look like it's not a network traffic issue, I will still give it a spin, to see how it works. Thanks for the suggestion.

olli@ said:
By the way, in the “old times” (last century), I would have suspected that your network card and graphics card share the same interrupt. Interrupt sharing was known for causing such kinds of performance problems. However, in the days of PCIe that shouldn't be a problem anymore.

EDIT: Sorry, I should have read the newer replies, too … So trafshow won't help in this case, because there is no traffic.
Click to expand...

Ah, well, are you suggesting I move my card to the PCI slot at the bottom? Ah, the memories... Well, this is not the bit of the 90s I am missing, to be honest!
 
kafka0 said:
I also just sacrificed a chicken, as documented in the FreeBSD Handbook for the Truly Desperate.
Click to expand...
Did you walk counter-clockwise around it? At midnight, on a graveyard, while playing the flute? It's supposed to work better that way!

And thanks to Olli for suggesting trafshow: I just installed it at home, and it is very cool. Small, simple, easy to use, and gives useful information.
 
Ok, so here's the epilogue: what seems to be happening here is that the PC is slowly dying. Without touching anything, various things started to break: I can't boot from perfectly fine USB memsticks, my pok3r keyboard's FN keys don't work at boot time, and now I get a kernel panic on mounting the ZFS root during startup... As this PC is not on a UPS any more and had to go through a few power cuts, I suspect the motherboard might just have had enough of this earthly life after four years of good service.

Thanks to all who tried to help me here!
 
You might want to check hardware stuff like memory and cards seated correctly in their slots. Also, remove dust.
Wouldn't be the first "defective" motherboard that magically resurrects without dust on top/in the slots.
It might save you buying a new one :)

Edit: also, the blood of the chicken contains iron so make sure it didn't splash anywhere :D
 
When you open the machine up and re-seat the memory, you might also want to remove the small round battery from the motherboard, and give it 30 minutes or so to completely discharge before reinstalling it. That should completely reset your BIOS firmware to factory defaults. I was about to give up on my old Dell computer, which is over 12 years old, when I tried doing that as a last resort, and it fixed everything.
 
You must log in or register to reply here.
Back
Top