After 3 hours trying to figure out what was causing lag spikes on my LAN, I figured it out: PLEX. The minute I stop the service (I run it on CentOS 7) everything goes back to normal.
Here is what happens:
64 bytes from 192.168.0.254: icmp_seq=44 ttl=64 time=1.14 ms
64 bytes from 192.168.0.254: icmp_seq=45 ttl=64 time=0.521 ms
64 bytes from 192.168.0.254: icmp_seq=46 ttl=64 time=0.484 ms 64 bytes from 192.168.0.254: icmp_seq=47 ttl=64 time=1352 ms 64 bytes from 192.168.0.254: icmp_seq=48 ttl=64 time=352 ms
64 bytes from 192.168.0.254: icmp_seq=49 ttl=64 time=0.487 ms
64 bytes from 192.168.0.254: icmp_seq=50 ttl=64 time=0.518 ms
64 bytes from 192.168.0.254: icmp_seq=51 ttl=64 time=0.479 ms
That IP (192.168.0.254) is my gateway, a cable modem from my cable company. At first, I thought it could be a bad cable, nic, iptables, whatever. But as soon as I stop PMS, everything goes back to normal and its not a coincidence. I tested it over and over. I tried disabling all the network services from Plex (GDM, DLNA), nothing helped. Clean install, nada.
This is a Linux dedicated home server (Plex, Internet gateway, etc.) running CentOS 7 with 8GB ram, dual-core cpu and dual gigabit LAN.
*** SOMETHING STARTS TO HAPPEN, LAG STARTS - THATS PLEX DOING IT *****
Frame 30 - ICMP request (ping again)
***** A LOT MORE STUFF GOING ON ***
Frame 37 - ICMP request (another one, still didnt get response from last one on frame 30)
*** MORE STUFF ****
Frame 43 - ICMP reply (requested on Frame 30 - that took a while! 1985ms to be precise)
Frame 44 - ICMP reply (requested on Frame 37 - a little less, but still a LOT - 985ms)
*** LAG CYCLE FINISHES ***
Two hosts appear on that capture:
50.116.49.5 - Frames 20 and 21 (li394-5.members.linode.com)
115.210.155.157 - Everything else
Isnt that DLNA? I have mine disabled! The process “Plex DLNA Server” isnt even running… weird.
Well, please shouldnt be advertising anything on my 192.168.0.0/24 network, thats my WAN interface. It should only be advertising stuff on my 192.168.1.0/24 network, which is my LAN interface.
Is there a way to set the interface plex should advertise/listen to?
What about it? That’s your Plex Pass. Every so often it goes out to linode.com and verifies your Plex Pass features are active.
I don’t see where the issue is Plex. I think this needs to be diagnoses and, particularly, stress tested, Here’s why:
1 .If an ICMP packet takes that long to be replied to?? that’s either computer issue or network issue
2. If those 186 bytes Plex has used are bringing down your ability to play online, you have a network hardware (wiring?) issue.
3. You have packet retransmissions. Look at #41, and #47. This again points to something electrically wrong.
I think you’re running on the hairy edge of failure with something. Nudge it just a little and the sky falls.
Sounds familiar? GDM and DLNA discovery. I turned off GDM and the two first packets are gone, but the lag still occurs. Turned off DLNA, but Plex still insists in sending that UDP 1900 packet, and thats where it hangs.
I guess some cable modems dont like getting poked by that, I dont know, but thats the reason some people turn off DLNA and the problem is gone (on some older versions), but, at least on 1.5.5, Plex still sends that packet on UDP 1900 even if DLNA is disabled.
How can I bind Plex to announce itself only on my LAN? Thats happening because its sending those packets on a interface it should not, my WAN!
You’re telling me a HTTP M-search (SSDP) is bringing you down? That’s the broadcast ping and the HTTP query to find out which Plex clients are on your network. I’m running two servers, 3 players, two desktops and 3 tablets, all responding to them without ill effect.
I’m running 5x the traffic you do in response to those.
I see what you’re pointing out and you have too much gap between packets ( > 0.1 seconds) for your network to be jammed up by Plex.
If you look at this photo, you can see where Gigabit is capable of 100,000 packets per second (of full payload), while you are showing tens of packets per second in the 100 byte range. Gigabit, at 128 bytes/packet will carry 1,000,000 packets per second. This is how it was designed and why it’s not uncommon to see file transfers of > 100MB / sec when reading over gigabit.
Well, believe me or not, there are 6 other threads full of people with the same issue. That SSDP packet must be malformed or something. Or its a bug in some cable modems chipset. Well, blocking that packet fixed the issue, hopefully this thread will save a few hours for someone with the issue if they search before asking, lol.
A cable modem which throttles PPS makes the most sense. I hadn’t thought of that until now (Thanks for that), but I can see where some cable providers wouldn’t want you spamming their over-subscribed coax. lol
a) select which interface(s) PMS works on
b) does not need to broadcast route discovery packets to find its way out to the internet because it will use what the OS knows (what you told it)
That said, You only would need to check the box for the adapter to use.
In your case: eno2 would be enabled, en01 would be disabled (unchecked).
