good bye FFXIV, thanks to the lag, you lost another customer.

[Raist]

They just upgraded their speed again, not sure how fast it is now exactly but all my other services load very quickly.

Not trying to single out Zephyr specifically, just this part of the comment brings to mind a common misconception about how data moves through the internet. "Speed" on a network is rarely every used appropriately. Unless you are changing the medium (like switching entirely to a fiber-optic network), your speed actually remains the same regardless of what "speed" you purchase from your provider--whether that is the light-weight 2Mb plan or the ultimate 100Mb plan. Physically, your signal's speed is still constrained to the same rate because of the slowest medium in place (many networks still have copper segments in play, so you will likely not get true fiber all the way from your demarcation point all the way to demarcation at the endpoint).

Early on, standard copper was providing a cap of just over 100Mb/second per wire used--but there was a limit on the distance you could use it reliably at that speed. We more or less got faster "speeds" by increasing the number of wires/channels used and bundling them to run on different channels and such in a fashion to make it appear faster, but bit for bit we were still bound to that 100Mb/sec physical limitation. The difference was that we were splitting larger groups of bits across multiple lines/channels either at once in parallel or right behind each other in serial. That principal didn't really change that much until the introduction of alternative mediums like Fiber and such (fiber caps vary based on material and such...but you are talking the gigabit level with fiber, not megabits).

What they are selling you as "Speed" is actually "Bandwidth". It means you are sending a larger cluster of electrons in each burst... but in reality they are all traveling at the same speed. So, as long as the amount of data being sent all fits in one burst---all that extra bandwidth isn't likely providing you any benefit aside from any impact it may have on artificial lag that may be be getting injected from the wait states on the slower line. It's a common practice for slower lines to have a sort of pause injected into the send/receive cycles to slow the line, so all you are doing is removing those odd milliseconds of wait state--otherwise, the data flows at the same speed. Your data bursts for this game are really small. Watch your S/R numbers and you'll notice you're not typically saturating the line with over 11MB of data in one pass in game, the rough limit of a 100Mbit line (there is overhead in protocols and such, and the limit is actually around 120Mb, so the cap is a bit higher but you typically still won't be reaching it for this game). So long as your bandwidth is wide enough so the necessary data bursts can get encapsulated in the same number of passes, you aren't really benefiting anything significant if your latency is the same. THAT is what our problems stem from... network latency.

Think of it as traveling on the interstate. 4 people traveling in a car at 80 MPH on the highway will get from point A to B in the same time as 4 people in a bus traveling at 80 MPH (provided they don't run into any traffic jams). Even if they are on a 4-lane highway vs. 2-lanes, it is the same speed to get there (provided both routes cover the same distance). You have the same number of people traveling the same distance together at the same speed. The differences between the two(you can have more vehicles or a larger number of people moving as one unit along the same path) do not impact the time it takes for the required 4 people to reach their destination. Your need is to move JUST 4 people at once. One may be costing you more to do so (ie the bus getting worse gas mileage than the car) without getting them there any sooner (80 miles to Columbia at 80MPH will still take 1 hour, regardless of which vehicle they are in). The benefit of the wider bandwidth plans is just so you can send either larger chunks of data at once, or to send more chunks of data from multiple devices.

So... unless you are consuming a lot of data elsewhere while playing the game that might cause your packets to get delayed from over-saturation... all that extra bandwidth isn't really increasing how fast your data gets to/from SE's server for this game. That is an issue of latency that depends more on the medium being used (all fiber versus any element using one of the slower mediums like fiber/copper/wireless), distance traveled between segments, and any delays in forwarding between hops along the way.

That is the issue at hand here... problems that are increasing our latency in route and not how fat a pipe you have to the internet.

[kidvideo]

What they are selling you as "Speed" is actually "Bandwidth".

That's very nitpicky. It might be a misconception when applied to a true measure of speed, but the reality is that this is a common understanding when talking about the internet. Boy you must be fun at parties.

[Raist]

That's very nitpicky. It might be a misconception when applied to a true measure of speed, but the reality is that this is a common understanding when talking about the internet. Boy you must be fun at parties.

Actually, no it isn't being nitpicky. In the networking world there is a very clear distinction between them. Bandwidth is capacity. Increasing capacity of a container does not equate to increasing the speed at which it can travel across the same medium. It increases the payload... but the container still travels the same distance in the same amount of time (the typical definition of speed). Throughput is not the measure of performance when it comes to small packet communications like what is used in games and things like VOIP. Latency is the metric you use, because it is about response time, not how big a package you can deliver (provided you can encapsulate a large enough chunk, which has not been an issue since we crossed about the 384k bandwidth mark).

The difference is with one you may get up to 16MB delivered in 110ms with one, but get up to 75MB delivered with the other. The time for that transfer can STILL be 110ms in both cases. The difference is you packed stuff in a bigger box that was traveling at the same speed. When the package is able to be delivered in the same number of handshakes, it takes the same amount of time to complete the process because both lines are moving the same number of packages at the same speed. So a 2K package that gets broken down into 1460 byte chunks will transfer in the same amount of time because it will be just two transferable units on both lines, both of which are in reality transferring the data at the same speed. 75MB takes longer to deliver the complete package on the narrower line because it can't send it all in one complete cycle--it has to break it up into 5 passes.... but each 16MB pass takes the same amount of time as the one 75MB pass because that is the capacity of the line and not the speed.

So, if the encapsulation is moving 2KB of data, and that can be transferred in the same number of handshakes on both lines with 80ms latency--both lines will deliver that same 2k in the same amount of time... they transfer the individual bits across the same number of channels (again, there is no issue of over-saturation here) at the same speed as determined by the combination of the medium's transfer speed, distance, and additional factors that determine the latency of the line (like delays in route). That is, in laymen's terms, what latency is--Delay. It is basically the amount of time it takes for the communication's round trip cycle to take place. It just isn't represented in the normal nomenclature many are accustomed to like MPH or KPH. It's just a flat measure of time, because when it comes to response times in this situation, that is what we need to know--how long it took to complete.

Line speed is more or less constant... it's bound to the physical characteristic of the medium (electricity vs light). Latency is the delay and is a product of distance traveled at the line speed, which can be impacted by things like noise, reflection, flat out interruptions that require retransmission. To a certain extent, Latency has a bottom that you can not reduce it past because it is a product of speed and distance. Bandwidth however is easy to manipulate--more channels, more wires, etc. increases the bandwidth. Bandwidth combines with your line speed and latency to determine overall throughput for a given period of time. So no.. Bandwidth is not speed. It may be perceived as such because you are comparing between over/under saturation of the bandwidth on different lines, but that is not speed. That is throughput, not speed.

[Edli]

To a certain extent, Latency has a bottom that you can not reduce it past because it is a product of speed and distance.

You cannot do anything about speed of light but you can reduce distance, that is how games reduce latency. When we play on private servers on counter strike for example we obviously pick the servers closer to us. I think there is a reason for that, oh yeah better latency. Having only one cluster of servers and in Canada was SE's choice. Saying SE has no fault whatsoever sounds strange to me.

[ElHeggunte]

You cannot do anything about speed of light but you can reduce distance, that is how games reduce latency. When we play on private servers on counter strike for example we obviously pick the servers closer to us. I think there is a reason for that, oh yeah better latency. Having only one cluster of servers and in Canada was SE's choice. Saying SE has no fault whatsoever sounds strange to me.

The servers being closer wouldn't guarantee these issues would go away if the problem is being caused by something between you and the server you're trying to connect to. Proximity to a server can help improve latency and reduce your chance of having a problem because you have to go through less hops to communicate with the server. However, it doesn't matter how close to the server you are if there's still a bad hop somewhere between you and it. You could be five miles away or five hundred and it would make no difference if your connection has to pass through something like a overloaded node regardless.

If distance were the only factor you would never see people living on the other side of the world being able to connect NA/EU realms just fine while other players fairly close to the servers experience problems.

So blaming SE and their server location is still scapegoating and failing to grasp the real nature of the problem.

[Edli]

The servers being closer wouldn't guarantee these issues would go away if the problem is being caused by something between you and the server you're trying to connect to.

The furthest away the servers are the higher the chance of encountering a bad hop along the way. No it wouldn't guarantee that every single issue would disappear but some would. When game developers create the infrastructure and the netcode their goal is not to make a 100% perfect scenario because that is impossible. They try to improve it on their side as much as possible.

What is happening on this thread is OP blaming SE, the others in here blame OP when in fact there are three options. It may be OP's fault, SE's fault or even both. However everyone just picks one option blindly and sticks to it with a passion. Yes there is a chance it might be SE problem, completely ignoring it is ridiculous especially when we know about this game server infrastructure.

However, this isn't counterstrike. This isn't an FPS in which the timing between clicking of the fire button by player A next to instantly hits player B.

Why does that matter? Latency is latency. All you're saying is, this game is laggy but not a big deal because is a slow game. My counter strike example was about how game developers usually reduce latency and that is done by reducing distance.

[ElHeggunte]

The furthest away the servers are the higher the chance of encountering a bad hop along the way. No it wouldn't guarantee that every single issue would disappear but some would.

I know, that's exactly what I said in the rest of the post that you didn't quote.

When game developers create the infrastructure and the netcode their goal is not to make a 100% perfect scenario because that is impossible. They try to improve it on their side as much as possible.

Of course, but that doesn't really have very much to do with where the servers are located as far as it pertains to this subject. SE could have servers evenly distributed all over the world and the OP could still be experiencing problems that aren't necessarily related to the servers. Someone somewhere is always going to have a bad hop to the server regardless of their proximity to it. So trying to specifically blame SE's server location without proof (you know, ping tests, traceroutes) is still scapegoating.

What is happening on this thread is OP blaming SE, the others in here blame OP when in fact there are three options. It may be OP's fault, SE's fault or even both. However everyone just picks one option blindly and sticks to it with a passion. Yes there is a chance it might be SE problem, completely ignoring it is ridiculous especially when we know about this game server infrastructure.

The side blindly throwing stones are the ones who keep insisting on blaming SE contrary to how the internet works and all the evidence provided. The counterargument says it's most likely (not that it necessarily is, just that it's the most likely cause) a local ISP problem or a bad hop, but that you also need to use available tools to narrow it down and communicate with the necessary parties in order to possibly get it fixed.

I don't think it's asking too much for people to do some research before playing the blame game and doing nothing to help alleviate their own situation. It's difficult to help those who don't even want to help themselves.

Why does that matter? Latency is latency. All you're saying is, this game is laggy but not a big deal because is a slow game. My counter strike example was about how game developers usually reduce latency and that is done by reducing distance.

It matters because not all games and services experience latency the same. An amount that could be crippling to one game might not even register on another. I don't pretend to speak for Fornix, but I believe that was his point.

[Fornix]

Why does that matter? Latency is latency. All you're saying is, this game is laggy but not a big deal because is a slow game. My counter strike example was about how game developers usually reduce latency and that is done by reducing distance.

It matters because the minimal latency which FF XIV has does not come with an impact on gameplay. And as such the latency is acceptable. We're talking latency rates of roughly 100 ~ 140/160 ms for most European players. A fractional delay on skill timings of approximately 5% or less. For US players this will be even better.

If players complain that lag is what killed them, there's either one of two things going on:
- There's high latency due to an issue somewhere in the routing towards the servers, out of SE's hands; or
- They just plain and simple aren't skilled in playing.

[Clavaat]

What is happening on this thread is OP blaming SE, the others in here blame OP when in fact there are three options. It may be OP's fault, SE's fault or even both. However everyone just picks one option blindly and sticks to it with a passion. Yes there is a chance it might be SE problem, completely ignoring it is ridiculous especially when we know about this game server infrastructure.

Did you seriously not read anything...and I mean anything else in this thread? Like, as of 2 pages ago?

I leave for 12 hours and it turns into this. We were making progress people, and you backtrack like this. We have proof of where the problem lies. It's the CDN's in the U.S., not SE. Some CDN's are owned by ISP's, so it would be those ISP's fault. I have had Verizon confess to me that they know this is an issue, but choose not to do anything about it. The most SE can do is contact an ISP and tell them to fix it, but at the end of the day it's the US's crap infrastructure, and the refusal to take the blame. Server location doesn't matter as long as the connection is solid. Why do you think you can connect to a Japanese server and have no lag? Because of the different path you take.

[Fornix]

You cannot do anything about speed of light but you can reduce distance, that is how games reduce latency. When we play on private servers on counter strike for example we obviously pick the servers closer to us. I think there is a reason for that, oh yeah better latency. Having only one cluster of servers and in Canada was SE's choice. Saying SE has no fault whatsoever sounds strange to me.

However, this isn't counterstrike. This isn't an FPS in which the timing between clicking of the fire button by player A next to instantly hits player B. We're rather talking about a game which has a slow pace, with a long GCD and a lenient exit timing on AoE skills. There's roughly 2 - 3 seconds or more for AoE skills to go off. They're preceeded by turning animations or other animations in most occasions. And they're heavily predictable.

Standard distance based latency in this game is not a reason to fail. Not even to be getting close calls. There's plenty of time given to avoid. And that is even with taking into account that I'm not playing from within the USA, but Europe.

If latency gets too high to make it unplayable, the problem lies elsewhere. Bringing the servers closer wouldn't have to offer any solution in that. As the ping reduction is only going to be very minimal. It comes down to roughly 1ms per 100km. So even if you bring the servers 3000km closer towards you, you're only going to see a reduction in latency of roughly 30ms. If due to a poor ISP, terrible home networking or whatever other reason out of SE's control you're current latency is e.g. 450 ms then consequently there's barely going to be an impact.