Finally I found this thread! This issue is driving me NUTS since yesterday. Im facing the same issue, doesnt seem to matter if streaming is going on or not. Check this log, its a PING from my CentOS server running PMS, every 5-20 pings, it lags and latency goes up to 700-3000ms.
BTW, 192.168.0.254 is my cable modem. I stopped all the services and theres no internet traffic what-so-ever:
[root@microserver ~]# ping 192.168.0.254
PING 192.168.0.254 (192.168.0.254) 56(84) bytes of data.
64 bytes from 192.168.0.254: icmp_seq=1 ttl=64 time=2.19 ms
64 bytes from 192.168.0.254: icmp_seq=2 ttl=64 time=0.500 ms 64 bytes from 192.168.0.254: icmp_seq=3 ttl=64 time=706 ms
64 bytes from 192.168.0.254: icmp_seq=4 ttl=64 time=0.535 ms
64 bytes from 192.168.0.254: icmp_seq=5 ttl=64 time=0.536 ms
64 bytes from 192.168.0.254: icmp_seq=6 ttl=64 time=0.580 ms
64 bytes from 192.168.0.254: icmp_seq=7 ttl=64 time=0.534 ms
64 bytes from 192.168.0.254: icmp_seq=8 ttl=64 time=0.802 ms
64 bytes from 192.168.0.254: icmp_seq=9 ttl=64 time=0.485 ms
64 bytes from 192.168.0.254: icmp_seq=10 ttl=64 time=0.538 ms
64 bytes from 192.168.0.254: icmp_seq=11 ttl=64 time=0.531 ms
64 bytes from 192.168.0.254: icmp_seq=12 ttl=64 time=0.516 ms 64 bytes from 192.168.0.254: icmp_seq=13 ttl=64 time=707 ms
64 bytes from 192.168.0.254: icmp_seq=14 ttl=64 time=0.508 ms
64 bytes from 192.168.0.254: icmp_seq=15 ttl=64 time=0.554 ms
64 bytes from 192.168.0.254: icmp_seq=16 ttl=64 time=0.535 ms
64 bytes from 192.168.0.254: icmp_seq=17 ttl=64 time=0.541 ms
64 bytes from 192.168.0.254: icmp_seq=18 ttl=64 time=0.566 ms
64 bytes from 192.168.0.254: icmp_seq=19 ttl=64 time=0.541 ms
64 bytes from 192.168.0.254: icmp_seq=20 ttl=64 time=0.543 ms
64 bytes from 192.168.0.254: icmp_seq=21 ttl=64 time=0.575 ms
64 bytes from 192.168.0.254: icmp_seq=22 ttl=64 time=0.551 ms
64 bytes from 192.168.0.254: icmp_seq=23 ttl=64 time=0.533 ms
64 bytes from 192.168.0.254: icmp_seq=24 ttl=64 time=0.586 ms
64 bytes from 192.168.0.254: icmp_seq=25 ttl=64 time=0.562 ms
64 bytes from 192.168.0.254: icmp_seq=26 ttl=64 time=0.569 ms
64 bytes from 192.168.0.254: icmp_seq=27 ttl=64 time=0.592 ms
64 bytes from 192.168.0.254: icmp_seq=28 ttl=64 time=0.557 ms
64 bytes from 192.168.0.254: icmp_seq=29 ttl=64 time=0.536 ms
64 bytes from 192.168.0.254: icmp_seq=30 ttl=64 time=0.580 ms
64 bytes from 192.168.0.254: icmp_seq=31 ttl=64 time=0.549 ms
64 bytes from 192.168.0.254: icmp_seq=32 ttl=64 time=0.543 ms
64 bytes from 192.168.0.254: icmp_seq=33 ttl=64 time=0.561 ms 64 bytes from 192.168.0.254: icmp_seq=34 ttl=64 time=106 ms
64 bytes from 192.168.0.254: icmp_seq=35 ttl=64 time=0.551 ms
64 bytes from 192.168.0.254: icmp_seq=36 ttl=64 time=0.589 ms
64 bytes from 192.168.0.254: icmp_seq=37 ttl=64 time=0.539 ms
64 bytes from 192.168.0.254: icmp_seq=38 ttl=64 time=0.546 ms
64 bytes from 192.168.0.254: icmp_seq=39 ttl=64 time=1.23 ms
64 bytes from 192.168.0.254: icmp_seq=40 ttl=64 time=0.555 ms
64 bytes from 192.168.0.254: icmp_seq=41 ttl=64 time=0.519 ms
64 bytes from 192.168.0.254: icmp_seq=42 ttl=64 time=0.489 ms 64 bytes from 192.168.0.254: icmp_seq=43 ttl=64 time=706 ms
64 bytes from 192.168.0.254: icmp_seq=44 ttl=64 time=0.749 ms
64 bytes from 192.168.0.254: icmp_seq=45 ttl=64 time=0.588 ms
^C
— 192.168.0.254 ping statistics —
45 packets transmitted, 45 received, 0% packet loss, time 44006ms
rtt min/avg/max/mdev = 0.485/50.052/707.283/176.226 ms
[root@microserver ~]#
If this problem only happened when pinging the cable modem, id be fine with it, but it immediately lags everything for that split second, horrible when playing. It all goes back to normal right after I stop PMS (1.233ms max):
EDIT: Turning off DLNA help a bit, now latency “only” spikes to 75ms on my local network, lol
64 bytes from 192.168.0.254: icmp_seq=4 ttl=64 time=0.557 ms
64 bytes from 192.168.0.254: icmp_seq=5 ttl=64 time=0.686 ms
64 bytes from 192.168.0.254: icmp_seq=6 ttl=64 time=0.559 ms 64 bytes from 192.168.0.254: icmp_seq=7 ttl=64 time=75.3 ms
64 bytes from 192.168.0.254: icmp_seq=8 ttl=64 time=0.591 ms
64 bytes from 192.168.0.254: icmp_seq=9 ttl=64 time=0.530 ms
64 bytes from 192.168.0.254: icmp_seq=10 ttl=64 time=0.526 ms
64 bytes from 192.168.0.254: icmp_seq=11 ttl=64 time=0.553 ms
64 bytes from 192.168.0.254: icmp_seq=12 ttl=64 time=0.534 ms
64 bytes from 192.168.0.254: icmp_seq=13 ttl=64 time=0.399 ms
64 bytes from 192.168.0.254: icmp_seq=14 ttl=64 time=0.569 ms
64 bytes from 192.168.0.254: icmp_seq=15 ttl=64 time=0.535 ms
64 bytes from 192.168.0.254: icmp_seq=16 ttl=64 time=0.518 ms 64 bytes from 192.168.0.254: icmp_seq=17 ttl=64 time=73.8 ms
64 bytes from 192.168.0.254: icmp_seq=18 ttl=64 time=0.550 ms
64 bytes from 192.168.0.254: icmp_seq=19 ttl=64 time=0.530 ms
64 bytes from 192.168.0.254: icmp_seq=20 ttl=64 time=0.562 ms
Spoke too soon. 1k again. I also disabled GDM, nothing helped.
64 bytes from 192.168.0.254: icmp_seq=65 ttl=64 time=0.566 ms
64 bytes from 192.168.0.254: icmp_seq=66 ttl=64 time=0.540 ms 64 bytes from 192.168.0.254: icmp_seq=67 ttl=64 time=1072 ms
64 bytes from 192.168.0.254: icmp_seq=68 ttl=64 time=72.5 ms
64 bytes from 192.168.0.254: icmp_seq=69 ttl=64 time=0.415 ms
64 bytes from 192.168.0.254: icmp_seq=70 ttl=64 time=0.515 ms
64 bytes from 192.168.0.254: icmp_seq=71 ttl=64 time=0.558 ms
64 bytes from 192.168.0.254: icmp_seq=72 ttl=64 time=0.534 ms
64 bytes from 192.168.0.254: icmp_seq=73 ttl=64 time=0.541 ms
64 bytes from 192.168.0.254: icmp_seq=74 ttl=64 time=0.575 ms
64 bytes from 192.168.0.254: icmp_seq=75 ttl=64 time=0.497 ms
64 bytes from 192.168.0.254: icmp_seq=76 ttl=64 time=0.537 ms 64 bytes from 192.168.0.254: icmp_seq=77 ttl=64 time=1070 ms
64 bytes from 192.168.0.254: icmp_seq=78 ttl=64 time=70.7 ms
64 bytes from 192.168.0.254: icmp_seq=79 ttl=64 time=0.548 ms
64 bytes from 192.168.0.254: icmp_seq=80 ttl=64 time=0.554 ms
64 bytes from 192.168.0.254: icmp_seq=81 ttl=64 time=0.512 ms
64 bytes from 192.168.0.254: icmp_seq=82 ttl=64 time=0.521 ms
64 bytes from 192.168.0.254: icmp_seq=83 ttl=64 time=0.566 ms
64 bytes from 192.168.0.254: icmp_seq=84 ttl=64 time=0.549 ms
64 bytes from 192.168.0.254: icmp_seq=85 ttl=64 time=0.539 ms
64 bytes from 192.168.0.254: icmp_seq=86 ttl=64 time=0.589 ms 64 bytes from 192.168.0.254: icmp_seq=87 ttl=64 time=1069 ms
64 bytes from 192.168.0.254: icmp_seq=88 ttl=64 time=69.4 ms
64 bytes from 192.168.0.254: icmp_seq=89 ttl=64 time=0.564 ms
I have the exact same issue. Took me multiple days and a thorough effort of trouble shooting my network to realise it was Plex causing these ping spikes. I started to take notice in Battlefield 1 multiplayer. Strangely enough I have not experienced this issue in the past with Plex Media Server running on my PC in the background. For now I have chosen to totally disable Plex on my PC. Will test later if switching of DLNA alone can do the trick.
Way back before multi-player gaming was ruined by every Tom, Dicke, and Harry who’s only mission is to ruin your enjoyment of same, I always made sure something else wasn’t using the same internet I was while gaming.
That was a LONG time ago, but it seems it’s still a valid response to that time-honored problem area. Nothing is more annoying than stepping into a room with a dozen bad guys then waking up respawning after the lag spike. Flag lost. Game in jeopardy.
I’m having the exact same issue danielponte is having. Just bumping to keep this visible to the community incase someone has figured it out. I have to keep plex server OFF unless I want to watch something. It’s ruining all of our networks gaming systems’ connections, even when absolutely nothing is streaming. It’s like the server is trying to connect or receive incremental data for some reason, and it locks up the bandwidth for fractions of a second every 10 seconds or so.
@Shakaku said:
I’m having the exact same issue danielponte is having. Just bumping to keep this visible to the community incase someone has figured it out. I have to keep plex server OFF unless I want to watch something. It’s ruining all of our networks gaming systems’ connections, even when absolutely nothing is streaming. It’s like the server is trying to connect or receive incremental data for some reason, and it locks up the bandwidth for fractions of a second every 10 seconds or so.
Do you have the Plex DLNA server enabled? A stray DLNA device on your network can cause network issues trying to talk to Plex incorrectly.
Having the excact same problem— ALL multiplayer online games rubberbands and lags when PMS is running, DNLA turned off - problem persist - only fix is shutting down PMS - i have 300 MB/100 MB connection - no problems there - but the server still mangage too f*ck the entire connection every 60-120 sec - WHAT IS CAUSING THIS ?!
It is, my friend. PMS is broadcasting a couple SSDP packets every 10 secs
to find clients. My crappy modem for some reason did not like that, I fixed
it by blocking on my firewall (check the thread) until I switched to a new
modem and the problem is gone.
Well thats funny - cause im sitting with 2 different modems from my ISP company - both have ZERO packetloss testing them through - and both works PERFECT when PMS is shut down…
Yup. They hate SSDP packets. I changed from Technicolor to Arris and the
problem is gone. Use a couple iptables rules to block out the broadcast:
-A OUTPUT -d 239.0.0.0/8 -p udp -m state --state NEW -m udp --dport 1900 -j
DROP
-A OUTPUT -d 239.0.0.0/8 -p udp -m state --state NEW -m udp --dport 32412
-j DROP
-A OUTPUT -d 239.0.0.0/8 -p udp -m state --state NEW -m udp --dport 32414
-j DROP
COMMIT
@danielponte said:
Yup. They hate SSDP packets. I changed from Technicolor to Arris and the
problem is gone. Use a couple iptables rules to block out the broadcast:
-A OUTPUT -d 239.0.0.0/8 -p udp -m state --state NEW -m udp --dport 1900 -j
DROP
-A OUTPUT -d 239.0.0.0/8 -p udp -m state --state NEW -m udp --dport 32412
-j DROP
-A OUTPUT -d 239.0.0.0/8 -p udp -m state --state NEW -m udp --dport 32414
-j DROP
COMMIT
Em 27 de mai de 2017 10:39 AM, “whoopazz”
escreveu:
Hi,
another solution can be to turn OFF the UPNP on the router. It looks like the router/modem wants to reply to SSDP packets and this causes delays. I’m testing it few hours, but it seems ok now.
Thank you guys for this thread. I was troubleshooting this problem few weeks. Just today, I realized that this problem is linked with plex.
If you have your server connected to your router through a Powerline adapter, try connecting straight to the router to see if the ping issues get resolved.
More details:
I tried turning off uPnP on my router and disabling DLNA on the server, but when I pinged the server, a simple 720p video on Plex would raise the average speed from ~10ms to ~1000ms. I used iperf and realized that the connection to my server itself is slow compared to other computers on my network: 1.2MB/s between a laptop and the server compared to ~60MB/s between two laptops over wifi. My server is behind a Netgear Powerline adapter, which is a “wired” connection, so I thought it would be faster than wifi, but it goes through your house electricity. I just tried plugging it straight to the router, and now the ping rate doesn’t drop while streaming videos. Also, the video plays fine and I am getting 9 MB/s from iperf. Still not as good as a laptop on wifi, so I probably have some work to find more bottlenecks.
@mikem212 said:
Hi,
another solution can be to turn OFF the UPNP on the router. It looks like the router/modem wants to reply to SSDP packets and this causes delays. I’m testing it few hours, but it seems ok now.
Thank you guys for this thread. I was troubleshooting this problem few weeks. Just today, I realized that this problem is linked with plex.
I can confirm this. Disabled UPNP and restarted my modem/router → problem solved.
@mikem212 said:
Hi,
another solution can be to turn OFF the UPNP on the router. It looks like the router/modem wants to reply to SSDP packets and this causes delays. I’m testing it few hours, but it seems ok now.
Thank you guys for this thread. I was troubleshooting this problem few weeks. Just today, I realized that this problem is linked with plex.
I can confirm this. Disabled UPNP and restarted my modem/router → problem solved.