Game is way too picky when it comes to a single packet loss

[Jijifli]

That's because there is server verification on a lot of things to help prevent cheating.

People 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.

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.

[Snow_Princess]

Seems 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.

yeah 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-150

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

[Claviusnex]

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.

[Jijifli]

snip

In 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.

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...

[Claviusnex]

That doesn't just mean there's nothing that needs to get fixed when it does happen.

I 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.

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".

[Snow_Princess]

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 haveless 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.

I 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.

I 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.

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".

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.

[Valkyrie_Lenneth]

This has nothing to do with the glamour log lol. This is completely seperate from that.

[msfakefur]

This has nothing to do with the glamour log lol. This is completely seperate from that.

I’m confused. I thought this thread was about connection problems?

[Valkyrie_Lenneth]

I’m confused. I thought this thread was about connection problems?

OP posted this above.

I 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.

[Snow_Princess]

I’m confused. I thought this thread was about connection problems?

It is, but someone wants to not understand.

I 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.



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.

yeah 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-150

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

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.