Ann!b@l Posted September 19, 2013 Posted September 19, 2013 (edited) Idk if it can help but sometimes I check with "/showdrop" packets lost.. Appeared I lost some few yesterday, checked and noticed something changed in my registry, then turned those who got changed "PMTUDiscovery" off (on 0) to get my MTU setted manually instead of dynamic and TTL at 128. Now no packets lost. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters key: EnablePMTUDiscovery-->0 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters key: DefaultTTL-->128 Edited September 19, 2013 by Ann!b@l 1 Quote
S3ti Posted September 19, 2013 Author Posted September 19, 2013 Idk if it can help but sometimes I check with "/showdrop" packets lost.. Appeared I lost some few yesterday, checked and noticed something changed in my registry, then turned those who got changed "PMTUDiscovery" off (on 0) to get my MTU setted manually instead of dynamic and TTL at 128. Now no packets lost. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters key: EnablePMTUDiscovery-->0 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters key: DefaultTTL-->128 Thx, but tried that (and some other tcp/ip settings) already, doesn't make any big difference. I think it's some problem out of my reach i.e server/isp-stuff since it worked fine some time ago with the same settings and same PC. Just looking for some way to track it down. Quote
Speedy* Posted September 19, 2013 Posted September 19, 2013 (edited) Seti, your problem sounds exactly the same as i have, but its not only happening in ET, it happens in every online game or when browsing the internet. It seems that around every 30 minutes, my internet connection times out for a minute. I think its my ISP or the router's configuration, but i have never found a way to solve this problem. So i'm quite excited if anyone knows the solution Edit: seti do you use more than one router/modem or a wifi repeater? maybe they interfere with eachother? Edited September 19, 2013 by VSSpeedy Quote
S3ti Posted September 19, 2013 Author Posted September 19, 2013 (edited) Edit: seti do you use more than one router/modem or a wifi repeater? maybe they interfere with eachother? No just one router (modem integrated) with 2 or 3 W-Lan clients. I don't think the W-Lan connection causes this, the overall performance of my connection started to get worse when I was still on a wired connection and the only client. Just switched to wireless because I'm sharing now with my neighbour and the router had to be placed somewhere else. I don't have disconnects or other strange things when just browsing, only when gaming (mostly ET) and the weird timeouts on Jay2. This doesn't happen on other servers. I had the same problem as you describe when I upgraded my bandwidth about 2 years ago, it happened to be my router and never had it again with a new one. Edited September 19, 2013 by S3ti Quote
Ann!b@l Posted September 20, 2013 Posted September 20, 2013 Tested a tracking with Wireshark S3t? I use it and it's a good tool. Might give you more infos.. Quote
Administrators daredevil Posted September 20, 2013 Administrators Posted September 20, 2013 Problem on Jay2 is still present, getting full packet loss every ~10 minutes. Lasts about 5-10 minutes and then I can reconnect. Started WinMTR right after lagometer went full yellow in the upper line. Idk, something is just not right with my connection... Thanks for the report. Submitted ticket to Choopa. They replied: We are working with our peers to correct this. Mike Wolfman Systems Admin 1 Quote
S3ti Posted September 20, 2013 Author Posted September 20, 2013 (edited) Tested a tracking with Wireshark S3t? I use it and it's a good tool. Might give you more infos.. No not yet, just used it for other stuff sometimes...it's an idea will take a look. If I get that right it's not possible to detect packet loss with UDP protocol, what games generally use. All I can see in the lagometer that at some point packets (i.e. server snapshots) are lost, come too late or aren't processed whatsoever but I don't know where or why it happens or how to find out. Also WinMTR shows problems on some servers so I assume it's something network related. This is how I want it to look permanently (well, except the high ping but it's US server ) This is how it does usually look. Sometimes the little bastards appear just every one or two minutes, not really noticable without lagometer. But when these big boys appear players warp all over the screen making it really unplayable. FPS are stable most of the time and the map is smooth, but all players are teleporting. It's really weird and f***ing annoying Edited September 20, 2013 by S3ti Quote
Ann!b@l Posted September 21, 2013 Posted September 21, 2013 (edited) If I get that right it's not possible to detect packet loss with UDP protocol, what games generally use. http://www.simplecomtools.com/productcart/pc/viewPrd.asp?idproduct=6&idcategory=5 (registering not needed here to dl it: http://udp-test-tool.software.informer.com/) http://www.tamos.com/products/throughput-test/ http://www.aggsoft.com/com-port-emulator.htm ... Edited September 21, 2013 by Ann!b@l Quote
Administrators daredevil Posted September 21, 2013 Administrators Posted September 21, 2013 root@id11933 [~]# ping 178.7.6.1 PING 178.7.6.1 (178.7.6.1) 56(84) bytes of data. 64 bytes from 178.7.6.1: icmp_seq=1 ttl=53 time=110 ms 64 bytes from 178.7.6.1: icmp_seq=2 ttl=53 time=109 ms 64 bytes from 178.7.6.1: icmp_seq=3 ttl=53 time=109 ms 64 bytes from 178.7.6.1: icmp_seq=4 ttl=53 time=110 ms 64 bytes from 178.7.6.1: icmp_seq=5 ttl=53 time=110 ms 64 bytes from 178.7.6.1: icmp_seq=6 ttl=53 time=111 ms 64 bytes from 178.7.6.1: icmp_seq=7 ttl=53 time=110 ms 64 bytes from 178.7.6.1: icmp_seq=8 ttl=53 time=110 ms s3ti can you please retry again? Quote
S3ti Posted September 21, 2013 Author Posted September 21, 2013 (edited) s3ti can you please retry again? Seems to be ok now, played about 30 min without timeouts. Will keep whining if it happens again. thx |------------------------------------------------------------------------------------------| | WinMTR statistics | | Host - % | Sent | Recv | Best | Avrg | Wrst | Last | |------------------------------------------------|------|------|------|------|------|------| | easy.box - 0 | 1275 | 1275 | 1 | 2 | 45 | 2 | | dslb-092-074-152-001.pools.arcor-ip.net - 0 | 1275 | 1275 | 17 | 19 | 46 | 19 | | 92.79.246.1 - 0 | 1275 | 1275 | 18 | 23 | 88 | 20 | | 92.79.215.161 - 0 | 1275 | 1275 | 18 | 22 | 54 | 21 | | 85.205.25.118 - 0 | 1275 | 1275 | 44 | 49 | 119 | 48 | | xe-0-3-0.cr1.lhr1.uk.nlayer.net - 2 | 1245 | 1225 | 44 | 48 | 333 | 48 | | ae2-70g.cr1.lhr1.uk.nlayer.net - 1 | 1269 | 1265 | 45 | 48 | 115 | 47 | | ae0-40g.cr1.lhr2.uk.nlayer.net - 0 | 1275 | 1275 | 46 | 50 | 138 | 49 | | xe-1-2-1.cr1.nyc3.us.nlayer.net - 0 | 1275 | 1275 | 114 | 118 | 178 | 115 | | ae1-50g.ar1.nyc3.us.nlayer.net - 0 | 1275 | 1275 | 116 | 119 | 149 | 126 | | as20473.ae7.ar1.nyc3.us.nlayer.net - 0 | 1275 | 1275 | 115 | 120 | 153 | 126 | |ethernet1-2-2-c1-16-b2-1.pnj1.choopa.net - 0 | 1275 | 1275 | 115 | 117 | 149 | 117 | | jay2.clan-fa.com - 0 | 1275 | 1275 | 115 | 117 | 140 | 116 | |________________________________________________|______|______|______|______|______|______| WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider http://www.simplecomtools.com/productcart/pc/viewPrd.asp?idproduct=6&idcategory=5 (registering not needed here to dl it: http://udp-test-tool.software.informer.com/) http://www.tamos.com/products/throughput-test/ http://www.aggsoft.com/com-port-emulator.htm ... Will have a look thx. From what I've read so far, UDP protocol sends packets one way without timestamps and there are no acknowledgement packets sent back like in TCP, seems to make sense that detecting lost packets at the UDP layer isn't possible. Maybe another story with ET packets since they should have some sort of timestamps. It would be nice to find a way to see if the packets arrive at my PC and are dropped because of whatever, or if they don't arrive at all in the first place Edited September 21, 2013 by S3ti 1 Quote
Administrators daredevil Posted September 21, 2013 Administrators Posted September 21, 2013 I will keep passing on whine to Choopa team hehe Glad to see it's fixed! 1 Quote
S3ti Posted September 22, 2013 Author Posted September 22, 2013 (edited) Don't panic, Jay2 is still fine But regarding the yellow spikes, I went digging a little bit. It seems that the problem (yellow lagometer / warping players) is caused by fragmented packets produced by the server. It is definitely related to the amount of players on the server, can't see any other relation since it happens on every server. I didn't exactly count player numbers but it's pretty obvious however and it doesn't happen that extreme with an average amount up to ~20 players. Just as example, this is what I get on Jay1 with ~42 players very often (at least every 5-10 seconds): ET + showpackets 1 Additionally I had wireshark running, showing only UDP packets sent from the ET server to my client. This is fine and everything is playing smooth. The big yellow spikes happen when a few fragmented packets arrive in a row like here. The largest packet size here what arrives at my PC is 1350 bytes, everything above arrives fragmented. The smaller ones following the 1350 byte packets have the same sequence number so it's meant to be only one packet. The largest packet here has 1845 bytes (1350+494) what exceeds even the highest possible MTU settings. I don't know how ET handles this but my thoughts are (if one snapshot = one packet, else I'm writing bs ): - One snap per 50ms - 20 snaps per 1000ms - If 6 packets get fragmented, there are 26 packets to be processed in 1000ms. So 6 fragments get dropped because there is probably already a packet with a higher sequence number available (arrived during the processing of the first fragment). Packets with lower sequence numbers (the 2nd fragment) still waiting to be processed are skipped and that warps players to the new positions. Also ET's maximum packet size seems to be 1400 bytes, everything larger is fragmented. http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking Bani about ETTV, but still applicable I think: http://bani.anime.net/banimod/forums/viewtopic.php?t=6195&postdays=0&postorder=asc&start=0&sid=5c79f5f1fb5d0bee6a29af72dcd53ecd Conclusion: All packets arrive at my PC, but partially fragmented + it has to happen to everyone who gets fragmented packets from the server, I don't think the server sends only fragmented packets to me. Edited September 22, 2013 by S3ti Quote
Administrators daredevil Posted September 22, 2013 Administrators Posted September 22, 2013 What's u rate setting on jaymod? Quote
S3ti Posted September 22, 2013 Author Posted September 22, 2013 (edited) What's u rate setting on jaymod? 50000, though I don't notice any difference onwards from ~35000. Hmm I remember a while ago I whined about the same problem for Jay3 and I thought it's some specific server problem, you raised the maxrate to 90000 iirc. Didn't make a huge difference if any (50000->90000 that is). Don't you (or anyone else) get this much yellow crap or many fragmented packets? What's the maximum packet size you receive from the server when it's crowded? I find it weird that other players seem to have no problems or don't notice that. Perhaps someone who is used to jumping framerates from 5 to 80, ping 200-300 and lagometer 0 doesn't notice it but I perceive it unplayable at some point Edited September 22, 2013 by S3ti Quote
Clan Friend SunLight Posted September 29, 2013 Clan Friend Posted September 29, 2013 ET fragments anything bigger than 1300, as you can see yourself from your screenshot with /showpackets 1 I got some fragments too, I connected to recruiting server to test it, but I guess it depends on the map and how many players and entities can be visible together. client send 32 : s=12878 ack=3182client recv 836 : s=3183client send 31 : s=12879 ack=3183client recv 1308 : s=3184 fragment=0,1300client send 32 : s=12880 ack=3183client send 32 : s=12881 ack=3183client recv 373 : s=3184 fragment=1300,365client send 32 : s=12882 ack=3184client send 32 : s=12883 ack=3184client send 31 : s=12884 ack=3184client recv 1128 : s=3185client send 32 : s=12885 ack=3185client send 31 : s=12886 ack=3185client recv 1166 : s=3186client send 31 : s=12887 ack=3186client recv 1177 : s=3187client send 32 : s=12888 ack=3187 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.