So you're saying it's a problem with the area where the datacenter is located?
So you're saying it's a problem with the area where the datacenter is located?
5 seconds video collection:
http://www.youtube.com/watch?v=Wbaqy_rUxys ¤¤ http://youtu.be/PGSnnof--LY?t=4s ¤¤ http://youtu.be/cDdhLy3ZRu4?t=4s ¤¤ http://youtu.be/X8JJ2hwH_fM?t=4m48s ¤¤ http://youtu.be/8mMzkXRERIU?t=3s ¤¤ http://youtu.be/bm_cJxwZRBE?t=2m2s ¤¤ http://youtu.be/sUjwBpOMMNQ?t=3s ¤¤ http://youtu.be/Y42H3RPuZrk?t=5s ¤¤ http://youtu.be/ES2ugI_k6Es?t=1m22s ¤¤ http://youtu.be/zFfu0i89gpI?t=7s ¤¤ http://youtu.be/xqRN--laUiM?t=56s
http://forum.square-enix.com/ffxiv/threads/80152-GAMEBREAKING-Ability-moving-objects-delay-and-unresponsiveness-%28affects-everybody%29

More or less. You can test this yourself by pinging your servers IP address. Famfrit's IP is 199.91.189.39 - http://arrstatus.com/
Open your command prompt and type (without quotations) "tracert 199.91.189.39" and hit enter. Watch for asterisks and high latency values. You will have to run this multiple times as the bandwidth ebbs and flows. You should be able to tell if the issue is on Square (asterisks are after Montreal) or on the node/ISP/backbone (before the Montreal hop).
So the location of the data server is the problem.... who placed the data servers where they did?
Also allyra is bringing up valid points, and not over reacting.
SE can't fix the internets problems which do exist, but they can optimize and that's all we are asking for.
This is what the beta should have been used for, and they should have planned their server location better.
kewl?

No. Physical location has nothing to do with it. Your route path and what nodes your traffic is flowing through is the problem. Put the data center in Middle Earth and as long as I have a stable route path or direct drop, I'm good to go.
Square bought the Montreal offices where their servers are located for NA/EU (formerly the Eidos offices). It is cheaper to maintain existing servers than buy new ones (price commercial grade servers and then triple that number for the things you need to interlace them and the logistics behind it. The number will will floor you). Square is a business. A business that is publicly traded and financials are scrutinized. You don't just drill 8-9 million dollars on servers and provider agreements for issues that are not your own for a fluctuating player base (servers that sit offline are counter to a return on investment and look bad to the board and the CFO. Modem businesses operate on a "justify being employed here" mentality. Once the player population stabilizes we may see server expansions and further fiber trenching). Again, this isn't the case as the connection issues come well before ORMUCO MONTREAL (I had dropped packets in Seattle) so for Square to be able to justify spending that much money to their majority shareholders is virtually non existent.
I'm not calling out Allyra or anyone specifically. I'm trying to provide reasoning, logic, and education (from an IT admin standpoint not a consumer) to the general forums. I'm all about pointing fingers and holding companies accountable. We just need to make sure we are pointing to the right people and getting things done from the floor up.


1.You would have to flat out r0, which is different than having a constant 1 second lag.
2. I never said latency wouldn't effect gameplay, I said it wouldn't make the game unplayable. You didn't need to kill DL in order to gain Sky access for example. The game is designed slowly enough that even if you did get that one dude who r0'd and it messed things up, it was a rare occurrence, and people were able to just move on and succeed the next time.
Again, my point is, you can't hypothesize that one could do it, but the other couldn't. What would be so special about Blizz that they would do that (and as I stated would have HAD to do that back in 2004 for it to be true, as the lag was gone by then. I know this for a fact because I was playing it), yet somehow SE could not? Blizz in 2004 would have had the same amount of money.
Don't compare Blizz's profits they had during the 10 mil+ subscriber era to SE, when what you claim would have happened way wayyyyy before that.
They don't care. Tata seems to be an easy port or something as TW isn't the only one that uses them.TATA isn't even a T1 backbone in the US. They are T3 at best. Have you asked your ISP for a re route? They may be more inclined to re route around a T3 since they normally don't pull a whole lot of weight.
If you think that not addressing customer issues preserves their name, you don't know enough of business. That is one of the major definitions of bad business.I'm not invalidating your concerns, they are obvious to see. I just don't know what people expect Square to actually do. It's lose-lose for them:
3.) They can simply not say anything. Yeah, people will be upset and cause an uproar but at the end of the day, they are able to preserve their name as a business, not be held accountable for issues not their own, and avoid law suits.
Again, they are not in regards to the actual structure of the game. If players can't play your game, regardless of whose fault it is, you do what you can to make the game playable.I'm just as irritated as you at the latency issues and that there is no visible movement, but I have experience in the field and I know that Square's hands are pretty much tied in the situation
If they really want to, they could make an offline dodge-intensive game to satisfy those people. The reality is the current internet world isn't built for that kind of content for a huge portion of players.

Money/Resources/Bandwidth/Trenching/Infrastructure/direct drops/availability/node and hub placement/space available to meet demand/. Square can ask for more. Ormuco can tell them no if they feel it's not worth the investment or doesn't meet the service level agreement or they simply cannot follow through with the request. It's more than some guy digging holes running cable. Square isn't going to buy their own node. Even if they did, you would see less latency past Montreal. That's it. You would still have the same problems as before.
Probably because they offer lower rates. I would call my ISP and keep explaining what's going on till I either got to Engineering or someone in CS that understands how the internet works (let's face it. Most CS departments have warm bodies to meet metrics. They likely know NOTHING about their own products) and ask for a prioritization re route. They can do it, it's finding the guy that will send the work order to the admin at your local hub.
The definition you're looking for is called "churn". Attrition is normal and to be expected. By losing some, they retain and gain others. Until their metrics slide to whatever value marketing/logistics have set, they aren't going to take a stance (among other reasons I have beat to death, but since we're focusing on the business model let's go with this one).
I'm going to preface my next comment with my personal view:
I AGREE. Their coding structure is pathetic. You have memory leaks so bad you have to take the servers offline to dump the cache. NO ONE DOES THIS. If you have memory leaks you have it narrowed down to two things. Hardware failure or bad coding. For them to allow this to go on as long as it has is unacceptable. Don't tell me they can't make a script to take a cluster down at a time and perform what is called a "rolling upgrade" or "rolling reset". You don't bring down the whole thing to dump cache. You take a cluster at a time and dump it's cache moving down the chain. It's a command line. Seriously. Blows my mind (I'm not going to get into not encrypting and auto closing Session ID's)
That being said, Square is a business. They sell a product. They are told by their managers who are told by their directors, who are told by the board, who is told by the shareholders to trim spending and make more money. They don't care about players, integrity, or a job well done. They care about profit. Square looks at how many people subscribe that don't have issues and people that subscribe that do have issues. Until the second outweighs the first, expect the code to remain the same.
This. 100%.
|
|
![]() |
![]() |
![]() |
|
|