I do not know why this game expects your internet to be 100% perfect, 24/7:
https://i.gyazo.com/d2fe017a1163b22a...17a6b78c3f.png
this single packet loss prevented me to mount (I had to cast it twice)
I been monitoring pings and such closely due to the blaming of my ISP, but it does not look like all problems are linked to it.
Game is way too picky when it comes to a single packet loss
Printable View
-
10-02-2017, 01:20 PMSnow_PrincessGame is way too picky when it comes to a single packet loss
-
10-02-2017, 01:28 PMValkyrie_Lenneth
That's because there is server verification on a lot of things to help prevent cheating. I prefer it over gameguard and that other crap games make you install for cheat prevention.
-
10-02-2017, 01:32 PMSnow_PrincessPeople still cheat though people teleport hack, etc... gather bot.. you can spam reports on endgame level gather bots but they do nothing. So I do not see that as an excuse to have it that way, ffxi does not do that and that game is fine, and that game has more reason to be more protective since they do not hand you stuff and takes years to get (they just ban you)Quote:
Originally Posted by Valkyrie_Lenneth
-
10-02-2017, 01:33 PMSagittarii
I've seen similar issues tonight with packet loss. My last instance was very laggy and I thought it may be my ISP. I did a tracert, then I checked pings to some IP addresses along the route to FFXIV's gear. I didn't see any issues. I'm only seeing packets drop a lot when I ping the FFXVI IP directly.
-
10-02-2017, 01:46 PMErryK
Did you do a tracert to see if the issue was actually directly from SE's servers and not your own ISP?
-
10-02-2017, 01:51 PMSnow_Princesshttp://forum.square-enix.com/ffxiv/t...nnection-issueQuote:
Originally Posted by ErryK
I been testing my butt off lately because I want to know who to blame and right now my isp is in hot water, this ping is from this vpn:
3 29 ms 15 ms 24 ms te-9-5.csr2.Chi3.Servernap.net [66.252.0.178]
4 21 ms 27 ms 14 ms ae-12.er1.Chi2.Servernap.net [66.252.0.70]
5 24 ms * 25 ms Pccw-br04-Chc01.er1.Chi2.Servernap.net [66.252.3.134]
6 48 ms 28 ms 23 ms ae-19.a01.chcgil09.us.bb.gin.ntt.net [129.250.8.137]
7 90 ms 80 ms * ae-2.r05.chcgil09.us.bb.gin.ntt.net [129.250.5.95]
8 35 ms 17 ms 23 ms ae-0.r21.chcgil09.us.bb.gin.ntt.net [129.250.2.205]
9 77 ms 72 ms * ae-5.r22.snjsca04.us.bb.gin.ntt.net [129.250.5.17]
10 75 ms 79 ms 80 ms ae-40.r02.snjsca04.us.bb.gin.ntt.net [129.250.3.121]
11 86 ms 78 ms * ae-2.r00.scrmca02.us.bb.gin.ntt.net [129.250.7.33]
12 * 79 ms 78 ms xe-0-1-0-1-1.r00.scrmca02.us.ce.gin.ntt.net [129.250.195.46]
13 * 74 ms 75 ms 204.2.229.234
14 71 ms 71 ms 73 ms 204.2.229.9
my isp wants to go to new york first with my data, this 69-78 ms from VPN is turned from a 130-150 MS due to the extra hops my isp does, this is a lot more stable then my isp , as i have yet to D/C from this vpn ( wtfast had a d/c going to lav beds) from the 2 spots I been constantly d/cing with my real isp, that was teleporting to lav beds, and at the end of the DF if CS was on, I would d/c during the ending CS.
When I saw the mount fail i looked at my cmd ping command, it was 1 line, it happened right as the cast finished,causing the mount to fail. -
10-02-2017, 02:14 PMErryKSeems more like it would be an issue of ping rather than packet loss if your ISP does more ms than the VPN connection. But it could just be the hops that your ISP uses aren't that great so you are getting packet loss. I would also guess that a higher ping would also result in a higher chance of packet loss.Quote:
Originally Posted by Snow_Princess
-
10-02-2017, 02:56 PMalimdia
This game depends too much on server checks, I can play gw2 with packet loss and barely notice it.
-
10-02-2017, 03:05 PMXiXiQ
The worst thing is latency affecting gameplay. Your overall dps and ability to dodge shouldn't be affected by something so arbitrary.
-
10-02-2017, 03:27 PMRiko_Futatabi
Still having the same dumb connection issue(delayed packets/error 90006) since the 4.06a patch. My passed month has been nothing but calling my ISP to query many things and posting on their forums. They even sent me a new router to try and see if that resolved my issue, but nope. I've also been taking a lot of networking "advice" from SE support via Email. Tried out many things, but still nope. The issues persist and eventually SE support loops you back around to these very forums, where I began.
I'm tired of it now, really tired. I've never tried to troubleshoot my network/pc settings etc. so much before. Just because of something that clearly went wrong during a patch. I was absolutely fine before that patch. But whatever, I honestly feel like I've done all I can. I'm actually burnt out on "querying" my settings and w/e else. Everything works fine, but my connection to this game. -
10-02-2017, 03:49 PMJijifliPeople still cheat. Saw someone using teleports while leveling a job. I reported it with video proof, guy's still here in SB, and can tell because he has 70's.Quote:
Originally Posted by Valkyrie_Lenneth
Also, let's say it is like that to stop it, it needs a fix. I've had this problem OP has too, and you wanna know what sucks? Imagine a summoner forced to skip an aetherflow, because if this happens at the same time you use something like that, it eats the cooldown and gives you nothing. It can do that with any cooldown (I've had Ley Lines eaten, Swiftcast eaten, my Dualcast ignored on RDM, etc.) important parts of a job's kit also shouldn't have this issue because you missed one tick in a 2 hour span. -
10-02-2017, 03:50 PMSnow_Princessyeah it is explained in the other thread, i live IN , LIVE IN, I LITERALLY live in a NTT node, Chicago. My ISP sends it to NY first then NTT sends it to Seattle, so this huge unnecessary routing leads a vpn about 1/2 my ms my isp does. (since they use the NTT node in Chicago) What happened here is not a ping issue, as you see 70 ish ping but right when i finish the mount cast, I got that packet loss so I failed to mount. This mounting happened under my VPN with about 74 MS average, not my isp 130-150Quote:
Originally Posted by ErryK
http://www.us.ntt.net/about/network-map.cfm
A single packet loss effects the game too much, now i see where the server limitation issues come from, if the servers was not double checking stuff so much (and it does nothing to curb cheating) maybe we can have a glam log?????????
Never knew the code was this bad.
my vpn before i sleep,
Packets: Sent = 11485, Received = 11452, Lost = 33 (0% loss),
Minimum = 69ms, Maximum = 427ms, Average = 73ms -
10-03-2017, 07:50 AMClaviusnex
Really need a sniffer to dig into why the packet loss. Also need to know the ISP static routes and their dynamic routing algorithm/tables. It sounds like the link to the NY node might be the ISP default route. It is possible that this is the ISP's largest pipe to the backbone provider so while the local Chicago node is closer to your location it could actually have less capacity than your current route. Not saying this is good or acceptable just reality. One possible cause of packet loss is the dynamic loss of routes. These eventually get discovered by the network and the new routing tables get propagated. Normally this occurs fast enough that the TCP communication stack will recover on a retry but sometimes it occurs slowly enough that connections start timing out. The longer the route the more opportunity for routes to change. Again this is just hypothesizing and a sniffer is what's needed to see what is really going on.
-
10-03-2017, 08:01 AMJijifliIn my case, it was my end, and I knew it was my end (Apparently I overheated my driver for it.) That doesn't just mean there's nothing that needs to get fixed when it does happen. If I get a packet loss, sure, the game obviously shouldn't take my inputs because it can't get my data, but that's the thing. It shouldn't, but it does, and incorrectly.Quote:
Originally Posted by Claviusnex
I HAD to stop leveling scholar for some time over it. If I used Aetherflow right when my loss happened, I'd be given 0 stacks, but still take the 60 second cooldown. Scholar needs that aetherflow for so many skills, and just because I missed 1 tick it extra screws me? If it just made it so I had to wait until it fixed itself, I'd be cool with it, but the system messes up cooldowns so badly... -
10-03-2017, 08:42 AMClaviusnexI didn't say that there isn't anything to fix but unless you know what the underlying events are you don't have any way to know where to look to resolve the problem. Traceroute and ping are fine for basic network diagnosis but they do not necessarily take the same routes that the application will. They also don't use the TCP stack but instead use ICMP or UDP neither of which are reliable transport so where they show packet loss a TCP based application might have recovered on a retransmission. Again the only thing that will show what networking protocols are being used and what is really going between the game server and client is a sniffer. From this you can then define the problem and whose responsibility it is to resolve.Quote:
Originally Posted by Jijifli
I was also trying to explain that physical proximity does not guarantee a faster route. A small capacity connection to a local node might have a faster ping time but actually be slower with real data than a larger pipe to a remote node. This by itself is not good or bad. Most likely is is based on ISP contract costs with the backbone provider so even if it could be improved you would have to build a business case to justify the increased costs to the SIP. Of course it could be something stupid such as "We've always done it this way". -
10-03-2017, 11:35 AMSnow_PrincessI am not asking why I have packet loss, my ISP is being cheap, the vpn fixes that because ya they prob do it what is more convenient for them, not what is better performance. This is simply showing I had a single packet loss, proven by the CMD, when I mounted and the cast failed. The only purpose of this thread is to show why they need to change the coding and stop over burning the servers unnecessary that is stopping us from having glam log because of the obsessive server confirmation checking that does not do anything positive and all negative.Quote:
Originally Posted by Claviusnex
Has nothing to do with the reasoning why a single packet loss happen, what is being discussed is how the game handles it. WoW or FFXI remain to function for a bit and when it gets streamlined again it recovers, here it just lets you lose your abilities or disconnects you from the game unnecessarily and have your character logged on too long after a D/C.Quote:
Originally Posted by Claviusnex
-
10-03-2017, 11:45 AMValkyrie_Lenneth
This has nothing to do with the glamour log lol. This is completely seperate from that.
-
10-03-2017, 12:01 PMmsfakefurI’m confused. I thought this thread was about connection problems?Quote:
Originally Posted by Valkyrie_Lenneth
-
10-03-2017, 12:23 PMValkyrie_LennethOP posted this above.Quote:
Originally Posted by msfakefur
Quote:
Originally Posted by Snow_Princess
-
10-03-2017, 12:32 PMSnow_PrincessIt is, but someone wants to not understand.Quote:
Originally Posted by msfakefur
Quote:
Originally Posted by Snow_Princess
SE blames the servers can't handle the glam log because the servers are overburdened. They are overburdened because of the bad coding, and this thread is aimed to show proof on how bad it is. The problems this game has online has to deal with the countless server side checks in why the game is too slow in general (like using benediction, it going on CD, but it really did not heal anything) It all has to do with how much the servers need to verify stuff, like showing a single packet loss to stop me from mounting. So this is to explain what SE means when they say server limitations, they are handing a lot of unnecessary traffic because of the bad coding.Quote:
Originally Posted by Snow_Princess
-
10-03-2017, 12:35 PMValkyrie_LennethExcept glam log coding, and client server verification are 2 completely different things that take 2 completely different resources, not just network. glam log is also about storage and saving char data to storage, which is separate from the network connection you have to the server.Quote:
Originally Posted by Snow_Princess
What SE is talking about in regards to char data is moving chars between servers for duty finder, which is internal network, not external, and saving char data to the storage arrays, which again, is internal network, not external, and the network cards themselves do much of the "processing" of these network requests, so its not a server programming limitation. They also likely use different network cards for internal network, storage, and external network. -
10-03-2017, 12:40 PMSnow_PrincessNot to SE, but that is likely cuz they do not know what people mean by a glam log, my guess is they see it as taking the same resource though? Regardless the point is the coding in this game needs fixing and changing. I really hope I found the proof in why it does...Quote:
Originally Posted by Valkyrie_Lenneth
One single packet loss causes an action to fail, i have never seen that from any other game I played online. -
10-03-2017, 12:42 PMValkyrie_LennethAgain, those are 2 separate things, and you did not show proof why the coding is bad, only that losing network connectivity causes gameplay interrupts.Quote:
Originally Posted by Snow_Princess
-
10-03-2017, 12:49 PMClaviusnex
Without knowing what is going on with the game's packets there is no way to determine where to start looking for the problem. You can't tell whether it is server side, client side, single packet loss, timeouts or any other number of things that could result in the unexpected closing of a connection. As I said packet loss with TCP connections should generally be recovered by a retransmission and my understanding is FF XIV is TCP based. It might not even be an issue with the game code. More than once I've had to debug problems in the Windows TCP/IP stack that appeared as errors to the application program. However it takes a sniffer to be able to diagnose what is really happening on the network for that connection and to provide enough information to do software diagnosis. Neither ping or traceroute will provide the needed data.
What are you basing this on? Pings don't prove this at all.Quote:
Originally Posted by Snow_Princess
-
10-03-2017, 01:02 PMMixae
I have good internet and a wired connection and I still notice you have to dodge things on point, even if you are technically out of it before it hits. I guess I'll try to use a ping booster and see if that helps, but im in US playing on a US server.
-
10-03-2017, 01:03 PMSnow_Princess
whatever, i suppose in your view saying nothing is better and it is better keep things the same.
I am here to suggest how to improve the game, what these forums are for, not to hear this can't be done or that.
We do not know the exact cause sure, but this game's coding is a problem, surely you saw situations of proof of that?
do a tracart, you might discover you have the same issue as me, simply bad routing.Quote:
Originally Posted by Mixae
-
10-03-2017, 01:26 PMClaviusnexI assume this is a response to me. I'm not saying nor have said there aren't problems with some of the game's design and/or code. However you keep going on with nothing more than saying fix it. I've told you what will be needed to proceed further with your problem. With the sniffer the exact network, client and server flows will be visible. This along with the time and game actions being performed can then be handed off to SE or whoever to do analysis. Until there is concrete data SE will continue to blow you off with instructions to run ping and traceroute then contact your ISP.Quote:
Originally Posted by Snow_Princess
By the way I had issues with WoW a few years back. They gave the same arguments about it being everything but them. My ISP claimed it was on my end. That changed when I gave them a sniffer of their server sending an unexpected FIN/ACK. My dropped connection issues went away. What they did to fix it I have no idea and they wouldn't say. They might have changed code, patched the OS or fixed a network/system performance problem. -
10-03-2017, 02:16 PMClaire_Pendragon
Lets try to explain what the OP is saying, in different words/examples.
(Since I have to go through the same thing as the OP)
If I pull my plug out, the game waits like 30 seconds or more, before it will say I have been disconnected.
In that period of time I can move around, and try to use abilities, but nothing happens, and i dont see players moving.
(This is how I know I get a true DC, not SE trying to DC me)
If I zone, Get moved through teleports, including raises, or someone leaves an instanced dungeon, leaving the group, I get DCed roughly 10% of the time.
But when I try to log back in, it says "You're still in the game"
That message only shows up, when your client kicks you from the game, but the servers think you're still on them.
Your client is incorrect, as you havnt lost connection, you can literally use an ability, see its effect, and see someone type messages none stop, all the way up till that black screen kick.
There was no actual disconnection, just the game THINKING there is, because of a small packet loss, at a weird time.
(This is ignoring needing the game to be more client side for certain things, like the mount, dodging AoEs, etc)
Just the idea of being kicked when "moving locations" isn't even an issue about client side, so much as its programmed to go into a panic, and kicks you over 1 lost packet.
(Technically there's more to it than that, because I can also not lose packets, and get kicked as well from zoning. I even have 2 versions of the game running on my same/single PC when my friend is over, he uses a controller, while i use a keyboard. We can both zone at the same time, but only one of us is being kicked, despite our connection being the same.)
The game is programmed to improperly handle the situation.
Other MMOs dont do this, so obviously they are doing something wrong. (Yes, I understand that the game servers are in a different location and go through different routes. Even so, the same issue happened in the prior server locations, when i was right next to them. Single packet loss, leads to a kick. Other MMos say "hey, l;ets wait 30+ seconds, and see if they come back from what we think is a DC".) -
10-05-2017, 09:13 PMClaviusnexQuote:
Originally Posted by Claire_Pendragon
You still can't say the problems are caused by one lost packet. Just because Ping shows a lost packet doesn't mean the TCP connections that are between the client and server will. Also if the TCP connection does detect a lost packet it will go into retransmission processing. This is all handled by the OS. If these don't work the connection will be closed with an error being returned to the application. Again the only way to determine if there really is a missing packet and more importantly what was the data in that packet is to run a sniffer. It shows everything going back and forth between the client and server and is what is needed to know where to start looking in the code. Look at it this way, not providing a trace is like calling your mechanic to have him fix a rattle in your dashboard without taking the car to them so they can look at it.
I did some poking around the other day with netstat. The client opens two connections to the server that remain open while the client is running. These are TCP connections so they are reliable transport. I have not looked at a trace but it seems logical to me that these connections are set up to allow full duplexing of client/server communications. It could also explain why server based information continues to be seen at the client but client actions stop working on the server while in limbo. I also noticed an occasional connection to a Google site. Since I use Google for my DNS my wild guess is these were DNS requests. This implies to me that the client can also open other connections when needed. Any one of these could be the cause of the problem. Without a sniffer there is no way to tell which. I rarely get disconnected and on the rare occasions I have I can usually attribute them to something like a DDOS attack. I might run some traces if I get bored just to see what goes back and forth between the client and server. Hopefully any text isn't in Japanese but I doubt I will be that lucky.
I understand it is not feasible to run a trace for something that occurs rarely but when someone can come close to reproducing a condition at will, as this thread implies, that is the time to do it. It is the only way to be able to perform problem determination and be taken seriously by the tech support personnel. By suggesting the sniffer I am just trying to help the affected folks progress beyond the simplistic blow off known as "Contact your ISP". And yes I hedge on the dropped packets as having close to 40 years in the business I know the last thing a tech support person or developer wants is to be told what's wrong with nothing to back it up. It tends to put them in a box and makes it harder to explain to the customer when they determine the problem is something else altogether.
Now back to painting the house.