Disclaimer: This is meant to be a thread about how latency affects end-game raiding in general. We have currently only done research into a limited scope, shield block while tanking a boss mob. This was the most important to us because the main tank is a single point of failure whereas healing and dps are spread over more players/connections. I believe this is worthy of a separate thread, but if the moderators feel differently, please feel free to move it into the tanking theorycraft thread.

Background:
A couple of RL friends and I all raid together. One of us is the main tank for the guild, Prayes, and we also make up the two main healers, myself and Gian, and two top dpsers, Antlers and Eppendorf. Anyhow, we use the mod Recap to tell us a lot of information about raid performance during encounters and we noticed a crushing percentage on the Prince fight of much higher than was predicted by the one roll system giving our tank's gear (he pushes crushes off the table when shield block is up). So we decided to do some testing.

Testing:
As a side note, we found testing on Anachronus to be useless. We do not believe he behaves like a boss mob. Specifically, he didn't crush the tank at all even without shield block ever up and did not resist Antlers (a destro fire lock). So we headed to Onyxia.

Onyxia yielded better data. We had the MT keep a combat log and looked at only phase one. We used one round where the tank never used SB to calibrate the percentages and then at the end of two rounds of testing with shield block we had enough data for the statistics to yield fairly meaningful results. It was surprising what we found.

Results:
During the fight we identified that the roll system in place appeared to be a one roll system to a high degree of certainty, but this is nothing new. Gian wrote a parser to pick out the times Prayes was crushed and what buffs he had on during that time. He was never crushed when shield block was up. Out of the 11 times our tank was crushed, 2 of them were due to user error (ie Prayes had used his rage on something else and failed to activate shield block). The other 9 were due to Prayes's latency. The combat log allowed us to see when he could not initiate a move due to latency (an error message is reported in the log ... several times). He would do a move on the global cooldown and then immediately spam shield block. His latency was rather high at the time (~200 ms). So instead of activating shield block it simply returned an error message for not 200ms but 400 ms! So even if the tank were to react immediately to shield block coming off cooldown there is almost a half second window where he can be crushed. This is rather significant when tank death nowadays is usually due to spike damage (or healer incompetence {not me or Gian}) and not healers going oom (at least it seems this way in our guild).

Theory:
Our theory is that Blizzard has implemented a system in which the client is forced to check if it is "ok" to allow a move when a global cooldown is in place. Specifically, when not under the global cooldown, shield block is synchronized instantaneously, but when there is a global cooldown in effect it has a 2*latency lag before even sending the command to shield block.

Solutions (lol):
Needless to say we have banned him from using iTunes, AIM, or Vent on his desktop while tanking and he now uses a laptop to run peripheral programs while only running WoW on his desktop. We are also looking into writing macros that reprioritize the order in which his moves are activated so that shield block has priority over moves on the GCD and thus reduce the time without shield block up.

Further Implications:
We believe that all players generally experience this type of issue. This is important to any type of player that uses spells and abilities both on and off the GCD. Especially when those spells have timing issues associated with them.

Latency plays a bigger roll in the game than I originally thought. I think the current coding in the game relies too much on low latency. There are examples of problems from other classes (e.g. Arcane Missiles) that I remember Blizzard saying they cannot replicate due to their low latency-testing environment.

I'm sure Gian would be more than willing to give his parser to anyone who would like to do their own testing. I think he will be posting in this thread a little more on the technical side of the testing procedures, but I wanted to get this to the community ASAP.

I hope you've found this to be at least a little insightful and I look forward to discussing this with the EJ community.

This has ever been a problem for raiding casters, particularly those playing on US servers from overseas. My old raiding guild had many folks that played regularly with latency of 500ms or more.

I was a mage at the time, so I'm only really familiar with that aspect of it, but our raid leader's (also a mage) damage jumped about 20% when he installed FastCast for the first time. He regularly played with a 350ms lag and was, at the time, a frost mage with untalented frostbolt (3 sec cast), so the 20% damage increase corresponded exactly to the (2*latency) lag that your tank experienced.

I can't find the post right now, but a blue post that the reason not all 5 arcane missiles fire is because of a mapping process back and forth from client to server that is related to any latency that is not near 0 and the reason Blizzard cannot reproduce it is because it is costly to introduce latency into their testing process. Sorry I can't back this up with a link, but it was awhile ago and I didn't bookmark it.

As a student at a major research institution I understand both the costs and benefits of introducing latency into computer system, so I can't really blame them too much since being able to replicate latency in controlled amounts is somewhat cost prohibitive.

Sidenote: The Blizzard search algorithm for the forums is not great and the search algorithm at BlueTracker, while better, could not find it either. :-(

You can achieve similar result to fastcast with /stopcasting macros. Can't solve GCD problems with /stopcast though.

There is similar weirdness surrounding shortening of the GCD with haste effects. It's a shame there isn't some kind of one action queue you could enable. I think it would clear up a lot of this stuff...

The theory is that the client won't let you cast a spell till the server says it's okay (which introduces the 2xlatency lag). To get around this, you can tell the client to stop the cast when it's too late to stop it from happening on the server. This let's you start your next cast much sooner.

Pre-BC, the fastcast add on would use the lag from the server's acknowledgment of the cast starting to estimate when it was okay to cancel your current spell. It would also protect your current cast from being canceled too early (there was a tunable buffer).

Some of the UI changes in BC broke fastcast. Now we have to use stuff like /stopcasting macros and supercast (does the lag estimation and shows you a "safe to cancel" zone on your cast bar).

None of this stuff works with the global cooldown though. There's no way to tell the client "lol...i was just kidding about the spell i cast 1 second ago. so...let me start casting the next one now plz."

FastCast was a mod (still around, maybe?) that worked for any caster that typically chain-cast a single spell for a long duration.

It worked by using the /stopspellcasting command to step spell casting client send, so that the client could send additional commands before waiting for the spell to actually finish casting.

We hypothesized that the typical sequence went like this:
(say cast time is 3 seconds and lag is 300ms)

time 0: Caster hits Cast
time 3: Caster hits Cast again. Client says, "I'm done now, can I cast another spell?."
time 3.3: Server gets request to cast another spell
time 3.6: Client gets OK from server, starts casting again

With FastCase, it was more like:
time 0: Cast hits Cast
time 2.7: Caster hits Cast again; FastCast sends StopCasting. Client believes casting has stopped.
time 3.0: Server receives StopCasting message and new cast request; Grants request because caster is done casting. Caster doesn't actually stop casting because he's already done -- his 3 second cast time is done. Caster starts casting again right now, because his client has already stopped casting.

Something like that, anyway.

FastCast was an old mod (functionality removed in 2.0, sadly, though it can be approximated with /stopcasting macros) to help casters with high latency cast, well, faster. It did this by using the in-game stopcasting command to tell the client to stop a cast once your cast bar had gone green. The net result of this was that your cast goes off (the bar went green, after all, signifying a complete spellcast) but you do not have to wait for server confirmation of a successful spellcast before beginning your next cast.

You can see a sort of variation of this effect if you have high latency and try to cancel a spell in the last .5 seconds or less. Your bar will go away (you could start a new cast if you so choose) but the spell will likely as not still cast, due to latency (the server calculated that your spellcast completed before it received the information that you interrupted it, and thus cast the spell - however, since you interrupted the spell client-side, you could have already started a new spell cast).

I can't imagine any of this would help your GCD issues, though you could potentially use a macro with Shield Block and xxx other ability, with a /stopcasting in between, which ensures that Shield Block always casts first (the macro will cast both spells simultaneously, but the Shield Block goes off before the GCD starts).

The issue is not creating latency, but being able to test it as a controlled variable. It's definitely doable. There are experiments that use latency to measure the speed of light and such, so it's definitely scientifically feasible, but not trivial.

This has been an issue for a stupidly long time. A one-deep spell queue would do wonders for the variations in casting speed latency and the like. I had no idea the GSC was affected in this way, actually. Fairly lame. What's further lameness is that I have to make a stopcasting macro and play beatmania with my casting bar to do my maximum damage. Not having to put up with that is definitely what I miss about being a rogue - limited by energy so you don't have any macro bullshit to get your dps up.

From a healer's point of view, I think (know) that the phenomena of not landing a heal on a target before they die, but still getting charged the mana for the spell even though they die and the heal never lands is some kind of latency related issue, as well. It seems like client-server coordination is something that could be markedly improved upon by Blizzard.

I would kill for 200ms "latency" sadly everyone playing from Australia and New Zealand plays with 400-500ms as the best ping you'll ever get most of the time. You can get 300ms in completely empty zones at odds times of the night. Latency does make a huge difference and yep the spell cast, gcd and cast bar systems are very buggy with high latency.

Australian ping pvp dagger rogues would disagree with rogues being one of the best classes for high latency

You should have seen Thaddius and Heigan with 40x 500ms players + typical Lagrock (Blackrock) peak raiding time conditions