Aces High Bulletin Board
Help and Support Forums => Technical Support => Topic started by: Bruv119 on March 31, 2011, 04:38:02 PM
-
The DA seems to be really bad this last week with damage taking 3-5 seconds to register.
The MA is fine for me and several squaddies are saying the same thing. Can some other people check it and maybe it requires booting?
-
I've always had a pretty decent connection and I changed ISP's recently. It is 3 times as fast as the old one on paper and appears to be just great at downloads/browsing/uploading etc. However I know that isn't everything and packet loss will cause most of your troubles. Skuzzy what can you make of these two pics?
DA ;
(http://i27.photobucket.com/albums/c181/Bruv119/trace2.png)
MA :
(http://i27.photobucket.com/albums/c181/Bruv119/trace.png)
-
+1
-
You need to contact your ISP Bruv. Packet loss starts right at your Internet connection. It will cause all manner of problems with the game connection.
-
it does appear to get really bad over the last 3 hops.
-
it does appear to get really bad over the last 3 hops.
The last 3 hops are irrelevant. Once packet loss starts, all data after that is questionable. The problem starts at your first hop. That needs to be fixed, before anything else is meaningful.
-
DA is still super laggy, whereas the MA is fine..
Net status etc is completely flat, but still experiencing 3-5 second lag before damage registers.
-
I've been testing it more routinely (like a paranoid Bish :noid tinfoil hat at the ready) and even on some days when the packet loss on my ISP network is negligible the last 3 hops are still where most of the errors come from.
Friday nights on the last two weeks have been pretty much unplayable and I can put that down to heavy usage.
I just find it really bizarre that MA hit damage is fine no matter when. The DA seems to vary with lag at all times some days 3-5 seconds and others 1-2. :headscratch:
Micky lets see some of your trace routes.
-
(http://img576.imageshack.us/img576/793/25482397.png)
(http://img535.imageshack.us/img535/2540/54073425.png)
I did go into the DA late last night and it seemed ok, i will try again later today.
-
What we're looking at here is the packet loss, more so than the latency. The PL% column tells you how many pieces of data either don't make it, or are damaged. Every time this happens another piece has to be sent to replace it. As that number gets closer to 100%, it means that piece of data has to be repeated over and over again until it is successfully transmitted, and this is what truly killed your connection because everything else stops until that piece finally makes it through.
Bruv, if you notice, you have 95% packet loss at one point. Mick's is ideal, with none:
Mick:
(http://i52.tinypic.com/bgvakl.jpg)
Bruv:
(http://i51.tinypic.com/2wn7iwo.jpg)
-
so how come Micky is having the same issue? with no Packet Loss.
I was hoping he would be with a different ISP. His route out to America goes through Manchester whereas mine goes through London. I've had days where my packet loss has been zero until it gets stateside. Micky appears to have none but I don't know how many samples he took.
The MA has no perceived/visible lag. The DA does but only with damage registering and that varies from day to day.
-
Does it matter what sort of "packets" you’re testing here? If the game uses UDP packets and you’re testing something else won’t it invalidate the results?
I don't think PingPlotter Freeware lets you choose, but PingPlotter Standard does, and I get very different results.
(http://www.swift72.co.uk/forum_pics/Packet-type.jpg)
Using the default packet type I get this:
click for a larger version (http://www.swift72.co.uk/forum_pics/Default_pingplot.jpg)
(http://www.swift72.co.uk/forum_pics/Default_pingplot-small.jpg) (http://www.swift72.co.uk/forum_pics/Default_pingplot.jpg)
But using UDP I get this:
click for a larger version (http://www.swift72.co.uk/forum_pics/UDP_pingplot.jpg)
(http://www.swift72.co.uk/forum_pics/UDP_pingplot_small.jpg) (http://www.swift72.co.uk/forum_pics/UDP_pingplot.jpg)
Note: I don't have a problem connecting in game; connection is usually around 150-160. On average I "Disco" once or twice a month, always after loosing the "UDP" connection.
-
so how come Micky is having the same issue? with no Packet Loss.
I was hoping he would be with a different ISP. His route out to America goes through Manchester whereas mine goes through London. I've had days where my packet loss has been zero until it gets stateside. Micky appears to have none but I don't know how many samples he took.
The MA has no perceived/visible lag. The DA does but only with damage registering and that varies from day to day.
Mick's connection looks awesome! Especially considering he's in the UK!
To be honest, I didn't see his mention of the same symptoms when I posted that, but still sometimes a connection only acts up 'once in awhile' and it may simply be that it wasn't acting up when he ran his tests.
-
Does it matter what sort of "packets" you’re testing here? If the game uses UDP packets and you’re testing something else won’t it invalidate the results?
I don't think PingPlotter Freeware lets you choose, but PingPlotter Standard does, and I get very different results.
Note: I don't have a problem connecting in game; connection is usually around 150-160. On average I "Disco" once or twice a month, always after loosing the "UDP" connection.
I think that may have something to do with your TCP packets being monitored by your ISP or even your Government. This is pure speculation on my part, but I do know that some countries filter and restrict internet access - perhaps something similar is going on over there. Also, if the server doesn't ECHO ping requests, it might show up as packet loss when it really isn't. Perhaps your ISP doesn't forward pings on TCP but it does with UDP.
-
Wait until the wedding is over. It will most likely settle down then.
-
Sorry to keep bumping this, but its incredibly annoying!
One weird thing that i have noticed is that late at night, my time, the lag seems non existent, but every other time, it's unbearable!
I'm at a loss with what to do about it.
-
Wait until the wedding is over then it will most likely settle back down.
-
I thought you were joking lol
-
Are you kidding, it's THE biggest thing going on in the world right now and every woman in the world needs instant updates !! I'm willing to bet it settles down after it's over.
-
BUMP, would using the secondary route help things? Is it possible to force it?
Yesterday we were doing 5V5's in the DA and 3 of us were laggy/discoing/having delayed hit registers...
-
This is gibberish to me, but someone might be able to tell me what's going on?
(http://imageshack.us/m/862/3690/tracertk.png)
-
Looks like the gateway between tinet and AT&T is taking a beating. 1/4 to 1/3 second latencies is pretty high. Normally, when a gateway gets that crowded, packet loss is also a problem.
-
hmmm thanks skuzzy,
i guess there's nothing i can do about it?
-
I am curious. Has it always been that bad, or is this the first time you have started looking at it?
I know the wedding, you folks recently had, spiked Internet traffic by about 1000% for a long time before the wedding. It still may not have dropped back to what it was.
-
Well ~2 months ago it was perfect, then all of a sudden, the lag started happening for me and a couple of other players aswell.
It is only since then that i have tried pingplot etc, so i cant compare these results to anything else.
What is also interesting is that the MA is fine, along with the other arenas.
-
The traces to any other arena is going to be the same as the servers do not impact the route the data takes, unless there is some type of bad route injection happening somewhere on the Internet.
-
I emailed a technician at tinet and here are his replies:
From looking at your traceroutes and our own traceroutes the issue seems to be towards the destination and not on the 2 hops that you are passing over in Tinet. I just doublechecked and am not really seeing any issues reaching the 206.16.60.39. Keep in mind that you are going from England(Manchester?) all the way to Texas, so an rtt of about 200-220ms is going to be normal. I believe that our peer might be having some internal issues on their own network(possibly a maintenance on their equipment etc). Please monitor this and let me know the time-frames that you are seeing the issue. Again I just checked our graphs and peer facing interface at nyc20 and I am not seeing any congestion/packetloss outgoing from Tinet to our peer, nor
incoming.
Yes I agree, both traces are identical. I assume then that the issue is on the destination. Judging by the difference in the destination IP addresses(206.16.60.39 and 206.16.60.41) it would seem that the 2 servers are likely virtually hosted on the same server blade or in the same physical location. You should write to the webmaster/host of the servers and request them to investigate.
-
I would think a TTL over 200ms is a bit high coming from England to New York. I'll have to run some calculations to see what speed that equates to.
With the routes being through the Southern part of the U.S., where over 300 tornadoes have recently devastated that are of the country, the tele comms are probably not at their best, at the moment.
-
192.205.37.37
this IP address appears to be the cause of today's issues.
after some more comparisons with nuke's French route to HTC that has no lag at all right now :
Tracing route to 206.16.60.39 over a maximum of 30 hops
1 1 ms <1 ms <1 ms 192.168.0.254
2 deleted
3 20 ms 20 ms 34 ms 78.254.2.254
4 25 ms 27 ms 21 ms fla93-1-v902.intf.nra.proxad.net [78.254.255.106]
5 20 ms 21 ms 26 ms p19-6k-2-po10.intf.nra.proxad.net [78.254.255.110]
6 * 24 ms 21 ms th2-crs16-1-be1010.intf.routers.proxad.net [212.27.50.13]
7 22 ms 28 ms 27 ms te1-2.332.ccr01.par04.atlas.cogentco.com [149.6.164.217]
8 30 ms 21 ms 27 ms te0-1-0-4.ccr21.par01.atlas.cogentco.com [130.117.2.21]
9 35 ms 40 ms 31 ms te3-7.ccr01.lon01.atlas.cogentco.com [130.117.2.162]
10 130 ms 128 ms 123 ms te0-3-0-4.ccr22.bos01.atlas.cogentco.com [154.54.5.122]
11 129 ms 128 ms 130 ms te0-0-0-2.ccr22.ord01.atlas.cogentco.com [154.54.45.241]
12 137 ms 142 ms 140 ms te0-4-0-5.ccr22.mci01.atlas.cogentco.com [154.54.45.149]
13 151 ms 146 ms 157 ms te4-7.ccr02.dfw01.atlas.cogentco.com [154.54.25.209]
14 150 ms 148 ms 150 ms te3-3.ccr02.dfw03.atlas.cogentco.com [154.54.6.98]
15 149 ms 147 ms 151 ms 192.205.36.181
16 153 ms 151 ms 165 ms cr1.dlstx.ip.att.net [12.122.139.110]
17 153 ms 149 ms 151 ms gar23.dlstx.ip.att.net [12.122.139.153]
18 158 ms 159 ms 159 ms 12-122-254-154.attens.net [12.122.254.154]
19 151 ms 147 ms 151 ms 63.241.193.18
20 149 ms 148 ms 150 ms 206.16.60.39
Mine:
2 36 ms 13 ms 56 ms cosh-core-1a-ae1-997.network.virginmedia.net [80.3.161.69]
3 42 ms 57 ms 68 ms winn-bb-1a-ae2-0.network.virginmedia.net [212.43.163.209]
4 45 ms 30 ms 30 ms glfd-bb-1b-so-100-0.network.virginmedia.net [213.105.172.130]
5 14 ms 15 ms 17 ms ae1.lon25.ip4.tinet.net [77.67.65.161]
6 112 ms 131 ms 112 ms xe-2-3-0.nyc20.ip4.tinet.net [89.149.187.109]
7 375 ms 640 ms 313 ms 192.205.37.37
8 360 ms 349 ms 374 ms cr2.n54ny.ip.att.net [12.122.86.10]
9 360 ms 378 ms 392 ms cr2.wswdc.ip.att.net [12.122.3.38]
10 362 ms 349 ms 347 ms cr1.attga.ip.att.net [12.122.1.173]
11 379 ms 344 ms 371 ms cr2.dlstx.ip.att.net [12.122.28.174]
12 346 ms 379 ms 384 ms gar23.dlstx.ip.att.net [12.122.138.161]
13 465 ms 356 ms 354 ms 12-122-254-154.attens.net [12.122.254.154]
14 350 ms 343 ms 331 ms mdf001c7613r0003-gig-12-1.dal1.attens.net [63.241.193.22]
15 330 ms 338 ms 337 ms 206.16.60.39
Amsoil's from the UK but with BT a different ISP.
1 39 ms 99 ms 99 ms BThomehub.home [192.168.1.254]
2 24 ms 25 ms 23 ms 217.32.140.64
3 24 ms 27 ms 27 ms 217.32.140.30
4 24 ms 25 ms 25 ms 213.120.161.10
5 24 ms 25 ms 27 ms 217.32.26.18
6 24 ms 25 ms 25 ms 217.32.26.178
7 24 ms 25 ms 25 ms acc1-10GigE-0-7-0-4.bm.21cn-ipp.bt.net [109.159.248.70]
8 38 ms 32 ms 31 ms core2-te-0-4-0-4.ilford.ukcore.bt.net [109.159.248.6]
9 29 ms 53 ms 33 ms transit1-xe-11-1-0.ilford.ukcore.bt.net [194.72.20.146]
10 208 ms 321 ms 139 ms t2c1-ge13-0-0.uk-ilf.eu.bt.net [166.49.168.85]
11 107 ms 62 ms 30 ms POS4-0-2.ar6.LON3.gblx.net [64.212.225.13]
12 * 270 ms 142 ms 192.205.34.141
13 145 ms 148 ms 147 ms cr2.dlstx.ip.att.net [12.122.80.102]
14 141 ms 141 ms 141 ms gar23.dlstx.ip.att.net [12.122.138.161]
15 780 ms 485 ms 201 ms 12-122-254-154.attens.net [12.122.254.154] <----- eek
16 145 ms 145 ms 147 ms mdf001c7613r0004-gig-10-1.dal1.attens.net [63.241.193.18]
17 144 ms 145 ms 143 ms 206.16.60.39
-
Bruv, you had some packet loss at hop #6, in that first trace.
-
the first one is nuke's from france he has some sort of proxy thing going on. He is reporting no issues.
is there anyway we can find out where and what those 192 addresses are?
-
In this case, it is a gateway router between the U.S. and England. As to who has responsibility for it, that is another matter. With international gateways, there are usually some sharing of the responsibilities for it.
I would not be surprised if it was simply overloaded. The traffic spike to England has been significant, from about a month before the royal wedding, through today.
-
from my trace one would assume that the NYC hop is the transatlantic router because that is where the jump in MS is.
The hop from NYC to this 192 address looks to be within the states. The same block of IP with a slight variation from one ISP to the next. Both mine and Micky's with Virgin Media add another 200ms to the transatlantic hop whereas Ams and Nuke both seem to go through ok.
Maybe it is something to do with the peering as this Tinet chap states but this has been occuring for the last 3 weeks on and off, before and after the wedding and the tornadoes.
-
The time frame you specify matches the spike in Internet traffic, along with the bad weather which has disrupted many telecommunications systems all over the Southern and Northeastern U.S.
It could be a coincidence. Once the traffic spike drops back to reasonable levels, it will be easier to determine what is going on.
-
After seeing the clipboard pinging 200+ yesterday I was interested in the thread. Normally my UK connection shows around 150 - 170 on your clipboard.
I have just had a look at what is the worse I have seen as below.
(http://homepage.ntlworld.com/geoff.goodwin/206.16.60.41.gif)
Somehow I think flying with lag is really going to be terrible! So not even going to bother this evening.
-
The thing that is bothering me about all these traces is the latency gets worse immedaitely after the tinet.net hop in New York.
If you look at the New Youk hop #7, which is tinet.net, then the next one is that 192 IP (hope #8). After that is the next hop at AT&T (hop #9), and the data has yet to leave New York, but the latency between the three hops in New York more than doubles.
This is either an extreme lad condition, which is quite possible, or something is wrong between those three hops.
Blagard, I think you are right. The normal latency should be around 120 to 150 ms, at our servers. Not sure why the tech person at tinet.net thinks 300 is normal. It should not be.
-
all Virgin traffic is getting routed through 192.250.37.37, which is adding 200ms,
both nuke and ams go through a similar IP block but aren't reporting complete disconnects.
when I get home from work today I'm hoping that this has cleared up.
The issues from yesterday I believe to be un-related to the initial query about DA lag in regards to the damage being taken and received.
If the connection was at fault we would see the planes warp, this is not the case it is purely a 3-5 second lag in taking damage whether it be shooting or receiving damage. Again it does not happen in the MA or SEA. :uhoh
-
I cannot duplicate the issue in the DA. It seems only the ones who are having some type of routing issue are having the problem.
If it was an arena issue, everyone (without fail) would be effected in the same manner.
-
I was in the DA with Bruv and noticed he had this weird lag thing going on. He wasn't ever warping, but I would receive his bullet damage after he had already passed my plane. So, I did a ping plot to see what it looked like for me, and I get this.
(http://death.innomi.com/uploads/traceroute.png)
I take it that's a bad thing? Any ideas?
-
Looks like your router or your ISP might be blocking ICMP ECHO messages.
-
Looks like your router or your ISP might be blocking ICMP ECHO messages.
I see in my router setup something that says "Respond to ping on internet port" is this the same thing?
-
Sounds right. The "ping" utility uses the ICMP ECHO message.
-
I just enabled it, still getting a lot of packet loss, but at least it's not 100% on the second hop.
(http://death.innomi.com/uploads/pingplot3.png)
-
Might want to reboot/power cycle that router.
-
Might want to reboot/power cycle that router.
I tried that after I ping plotted that first image you seen. I also cycled the modem. That's what's weird, in Aces High, my net stat looks fine, no one has complained of me warping etc.,
-
Maybe the router is giving the ICMP ECHO message a very low priority or tossing out any overlapping requests to help reduce the impact of a DoS attack using that message.
-
Maybe the router is giving the ICMP ECHO message a very low priority or tossing out any overlapping requests to help reduce the impact of a DoS attack using that message.
Looks like you were right skuzzy. I disabled the DoS attack protection thing, and voila!.
(http://death.innomi.com/uploads/pingplot4.png)
I guess my question at this point would be, is there any security reason on why I should keep it enabled? I'm fairly computer savvy, router is properly setup with a secure password, wireless is completely turned off etc.,
-
Disabling the "ICMP ECHO" response is a good thing. It will not stop a flood of those requests, but it will stop an answer from being generated, which will double the overhead of the router and cause it to succumb to a DoS attack faster.
-
Disabling the "ICMP ECHO" response is a good thing. It will not stop a flood of those requests, but it will stop an answer from being generated, which will double the overhead of the router and cause it to succumb to a DoS attack faster.
This is a screen shot of my router config screen, and I think it's similar to what you are referring to. Does this look correct to you?
(http://death.innomi.com/uploads/router.jpg)
-
Personally, I would not allow the router to respond to a ping. Just turn it on when you need to.
-
Thank you Skuzzy, wasn't sure if that was what was causing my weird ping plotter results or not. :salute
-
Ok We've found something interesting.
The lag only occurs at 5pm-12am GMT weekdays and 10am-12am GMT weekends, which leads me to believe that it is traffic management at peak times on the ISP's end. However that still doesn't address the fact that only the DA is affected.
weird.. :headscratch: