Warning: Intense Geekery and Theorycrafting 25/10 Man resto

[CptDan 25]

Also as stated earlier, more data will help. We need to gather logs that are free of anything making them overly complicated. I am going to do a few tests wearing no gear, wearing gear, and maybe see if I can find a haste proc trinket and try a few tests there. This will gve me the best shot at "pure" data. Then I will try to test in a raid environment and see if increased server load affects anything.

If nothing else, seeing a naked Draenei repeatedly dropping a totem might raise some eyebrows ;)

 

FOLLOW-UP:

 

Tomorrow is heroic progression although depending on time we may not actually get to the progression bosses. We only raid for like 3 hours usually and progression begins at Nazgrim, though sha isn't what I would call on farm yet so we could have a few wipes.

 

I want to try the WA more that stoove posted and maybe the edit posted above. I also would like to find a better way to track the HST ticks so that we can have raid information to go on. I'm most curious to see how lust and things like that affect it, like how many ticks would be gained by HST and HT? While I'm good at analyzing systematic information, i'm not quite as versed as you guys are in the math. I'll do my best to collect good data. We have another shaman in the group but his first language isn't English so we can use his logs as well for another perspective. I'll post up logs tomorrow evening (tues, PST) and we can go from there, let me know if there is anything in particular I should do as far as data collection goes.

Edited February 11, 2014 by CptDan

[Binkenstein 1]

One thing that always bugs me about the HST breakpoint is that it's not personal lag which causes it to not tick. It's a server-side thing, and we don't entirely understand it. On the assumption that it's the server-side lag which is the cause, your Haste might not affect that. Indeed, there was evidence presented by Binkenstein that Haste did not seem to affect the number of ticks you get.

 

Nope. Haste does affect the number of ticks you get. The problem is that HST & HTT are both fixed durations that aren't affected by haste, so rather than doing the +/- half a tick duration variation you see from HoTs, both totems go for 15 or 10 seconds and that's it.

 

The problem is that depending on processing time and latency, the totem isn't destroyed at the "correct" time, and instead persists longer.

 

I suspect it's something like the client sending the server the "totem duration expired" message, it gets processed on the server, returned to the client, and *then* the totem is destroyed. This explains why during testing of this a lower latency shaman like Vixsin returned more consistent results than Dayani or myself who reside in Australia/New Zealand and have higher latency.

[lynx 19]

Well, right now, conceptually totems and hots are different.

Totem is a pet which updates dynamically, while a hot snapshots your stats at the moment of application. So the duration of the totem is constant (up to lag ), while hots get some extra time (or a less time) to run to make sure that all ticks actually happen. Since snapshot mechanics will be removed in WoD we'll have hots that work like totems. So I just hope they won't be affected by latency (futile, I know, but maybe a fractional tick or something).

 

The funny thing about the extension at the end is that it just barely makes up for the delay from totem placement to first tick. Effective HST runtime (first tick till destroy) from my tests was lower than 15 seconds almost always (by 50-200ms).

 

I find it incredibly hard to believe that processing power is a factor here, though network latency sure is. Also we have to remember that latency is not symmetrical on the internet, so while you have a low latency to the server, the server might have a higher latency to you. So a mechanism like totems which requires constant client-server messaging (because it's dynamic) will suffer from high latency on either end, while hots will be affected only by your latency to the server.

Edited February 17, 2014 by lynx

[Stoove 347]

Nope. Haste does affect the number of ticks you get. The problem is that HST & HTT are both fixed durations that aren't affected by haste, so rather than doing the +/- half a tick duration variation you see from HoTs, both totems go for 15 or 10 seconds and that's it.

 

Hi Binkenstein, thanks for your input. I think you misunderstood my post which you responded to - I'm not arguing that Haste doesn't affect the n.o. ticks (that would be absurd), I'm wondering whether ones Haste affects the likelihood to get or not get the extra tick at a breakpoint (the effect we are discussing). I haven't seen a good argument spelt out either way, so I think the only way to understand that is data - does a +/- 100 Haste rating make a difference? (provided that one stays close to the breakpoint)

 

The information regarding personal lag is very useful, thank you.

 

Since snapshot mechanics will be removed in WoD we'll have hots that work like totems. So I just hope they won't be affected by latency (futile, I know, but maybe a fractional tick or something).

 

I've seen some discussion on this, and I don't think that Blizzard have actually decided yet. I did see a discussion about making Haste affect the number of ticks you get by making getting n+1 ticks a random event, with probability determined by your Haste. I suspect that this will work rather well.

 

The funny thing about the extension at the end is that it just barely makes up for the delay from totem placement to first tick. Effective HST runtime (first tick till destroy) from my tests was lower than 15 seconds almost always (by 50-200ms).

 

I'm seeing this, too. My code measures the total lifetime of the totem, I'm seeing the range 14.970-15.020 s, roughly. More data will refine this result though. Personal latency is in the 20ms range, indicating that in my case (far from the breakpoint) there isn't much interesting going on.

 

However, when I moved down towards a lower breakpoint I was seeing the tick-loss phenomenon. More info when I have it.

[CptDan 25]

I haven't forgotten this topic.

I will be doing some farm bosses this week so ill have more time to do different things and gather some data. I might even log some pvp action using it.

 

UPDATE:

 

Tonight we were on farm bosses and testing out trials for a few attempts on each boss. The unfortunate problem is that our healing team is pretty much over geared for the fights that we did tonight. I would estimate the average ilvl for the healing team somewhere around 565 (i'm at 570). I was second on healing for heroic Imm and topped on protectors and norushen. 

 

The problem here is that mana isn't as much of an issue on these fights for me to really start crunching it. To put that into perspective, I have 12.3k Spirit and ended most fights above 85% mana. I was putting MT down for some of the other healers.

 

The main reason I wanted to get raid logs to back these is how the mechanics act a bit differently (meta gem and cloak) while in combat vs just doing it by myself. 

 

That's the update regarding the WA for mana returns.

 

For the HST latency, this is a harder thing for me to gather data. I would like to say i'm pretty good at remembering it as I track it's cool down pretty religiously. This would require a lot of time to just sit and spam HST, and I'll need to do that when I have more time.

Edited February 19, 2014 by CptDan

[Binkenstein 1]

Hi Binkenstein, thanks for your input. I think you misunderstood my post which you responded to - I'm not arguing that Haste doesn't affect the n.o. ticks (that would be absurd), I'm wondering whether ones Haste affects the likelihood to get or not get the extra tick at a breakpoint (the effect we are discussing). I haven't seen a good argument spelt out either way, so I think the only way to understand that is data - does a +/- 100 Haste rating make a difference? (provided that one stays close to the breakpoint)

 

Higher latency increases the chance that you'll get an extra tick from the totem "surviving" longer. The more haste you have, or the closer you are to another break point, decreases the latency required for that extra tick.

[CptDan 25]

Higher latency increases the chance that you'll get an extra tick from the totem "surviving" longer. The more haste you have, or the closer you are to another break point, decreases the latency required for that extra tick.

So latency helps to get an extra tick? I understood that the common issue was latency could cause an extra tick to not happen. If this is true do you know the math for haste vs latency ticks or any data? I'm not arguing it right off but would like to know more.

[Stoove 347]

So latency helps to get an extra tick? I understood that the common issue was latency could cause an extra tick to not happen. If this is true do you know the math for haste vs latency ticks or any data? I'm not arguing it right off but would like to know more.

 

Could be that I have misunderstood this, as well. I don't have time to make my own data, though, but it could be the healing totem breakpoints aren't as bad as I thought.

[lynx 19]

It can net you an extra tick if you're just below the next breakpoint of HST. But you need to be pretty close for this to happen because initial delay is lengthier than the extension (at least was so in my tests). No concrete numbers here, but I can do some analysis later.

 

If we stick to reforging/reggeming haste by breakpoints then I don't see the need to aim just below an extra HST tick simply because I can't find anything notable there. And the only thing of importance I could find is the zerking HTT 8878 breakpoint which you certainly don't want to miss or gamble on (and that's a big reason to go for 9100, just to assure that the tick will happen).

Edited February 20, 2014 by lynx

[CptDan 25]

This thread keeps me thinking: is there a way for you math wizards to go over logs and identify a stat priority based on what worked the most for you personally? This would weigh in factors such as personal style and rad comp. I tried the resto sham stat analyzer Aden and didn't really know what to make of it. I am considering dropping down to the Hr break below the 33 break for HST and putting the rest into crit. I haven't been able to get Thok trinket to drop so I am using the siegecrafter with the multi strike which is far from ideal but my sha trink is only 536 and no Thok at any level so I want to maximize with what I have on hand.

[CptDan 25]

Tonight I will be trying a new stat build:

Low spirit ~10.5k or so / 31% crit / 49% haste for the hr break. On top f this I will be using stoove's WA string and glyphing recall. This will be a balls to the wall attempt at maximizing efficiency and should be fun. On the other hand it may fail miserably.

I will post logs comparing fights with my current stats to fights with new stats. Same gear, different priority.

[SparkSovereign 61]

If we can come up with a way to mathematically represent your interaction with your comp, yeah, probably.  But that's pretty hard, if not impossible.  Might be simmable, though.  It would be a huge amount of work to put something like that together, but once we have a beta for WoD it might be sane enough to try to put one together for next xpac.  I'm already starting to think about how it would work.

 

Shy of a giant tool no one has made yet, best bet is "try it both ways, see what happens".  Really all we can do.  If proving grounds scaled up to your ilvl instead of scaling you down we could do much more controlled testing, but it is what it is.

[CptDan 25]

Well I will have a comparison set of data

[Stoove 347]

I heard at one point that the people behind Simcraft were looking to develop their healer modules. They already have almost all the necessary structure to do a sim, just not the time/manpower/knowledge. If you're interested, see if you can get involved! I would love to be able to devote some time to it personally :)

[CptDan 25]

I heard at one point that the people behind Simcraft were looking to develop their healer modules. They already have almost all the necessary structure to do a sim, just not the time/manpower/knowledge. If you're interested, see if you can get involved! I would love to be able to devote some time to it personally :)

I just can't wrap my mind around all of the non mathematical variables such as healing comp, spell choice, cd timing, etc. I would imagine these are more important than a mathematical crunch of throughput stats.

[Stoove 347]

I just can't wrap my mind around all of the non mathematical variables such as healing comp, spell choice, cd timing, etc. I would imagine these are more important than a mathematical crunch of throughput stats.

 

That's why you sim it. Most of the actual code needed to simulate these variations are already there, at least according to Theck.

[CptDan 25]

That's why you sim it. Most of the actual code needed to simulate these variations are already there, at least according to Theck.

This might be interesting to test. I'd offer myself as a guinea pig if needed.

 

In other news, I tested the 50% haste build out this week. It didn't feel that it was performing that much better at least as far as the numbers go. I go the Heroic WF scepter tonight and I'm going back to a crit build for next week. The haste is fun, it's way more involved and requires more management, but it didn't seem to put out that much more healing compared to the crit build. I will edit this post once I can pull out a good set of comparison logs.

 

For stat comparisons:

 

Haste Build = 50% Haste, ~30% crit (buffed), 10.5k Spirit. I used a regen trinket on most fights

Crit Build = ~9100 Haste (33%), ~40% Crit (buffed), 11.7k Spirit.

 

I am going to tinker some more and see if I can get the spirit around 10k and have crit as high as it will go. I may also drop down to the 30% HR break. On the logs, HR and HST are always among my highest healing spells.

 

The changes in the builds affect healing style in that with the Haste build, i totally forgo the expensive heals such as HS and GHW unless during a LMG Proc. I would have to use recall during certain portions of the fight but couldn't stay on it as good as I should have. Mana didn't feel too bad actually even with the haste and a lower amount of crit. The odd thing was that I thought the haste would allow me to heal more reactively but it seemed to hinder that ability more than help it.

 

With the crit build I'm not afraid to use a HS or GHW outside of an LMG proc. Mana is a secondary thought that doesn't really enter into my spell selection. I am able to keep HR down (I slow it a bit to UE on every one) Spells seem really powerful.

 

TLDR: I'm still collecting data, but I didn't like the high haste build. I'd welcome other sets of data to compare. 

[lynx 19]

I gathered some results from various runs and haste ratings, to see what is the correlation between haste and the 11'th tick of HST (assuming raid %5 haste and AS).

Here's what I got:

 

It's a contour plot of haste levels which serves as a guideline to what haste you want to reforge given the probability of 11'th tick on lower axis and latency on left axis (ok, this is not really your latency, because server lag is involved as well, but it's somewhere close to it).

 

This model works quite well for me. If your mileage varies, do tell!

I also have an excel of this if anyone is really interested.

Edited March 6, 2014 by lynx

[CptDan 25]

I gathered some results from various runs and haste ratings, to see what is the correlation between haste and the 11'th tick of HST (assuming raid %5 haste and AS).

Here's what I got:

 

This model works quite well for me. If your mileage varies, do tell!

I also have an excel of this if anyone is really interested.

Mind... Blown! This is awesome though for sure

[lynx 19]

BTW, I can make another plot which takes into account HST recalls (with Stoove's aura in mind).