This is actually dependent on your latency. If you do play at low latency <50ish you can expect to lose a tick. If you play on higher latency such as 250ish (aka the rest of the world outside US) you can expect to get all your ticks irrelevantly of how tightly you spam your keys.
I use a mousewheel for my casts - it is impossible to get them any tighter, of course one could argue about a decimal of a millisecond as compared to a keybind hardware spam macro, but that is not going to make sufficient amount of difference at the end of the fight, even if it's 10 minutes long.
As much as people like to believe that the 'custom lag tolerance' resolves that issue - I would argue to the fact that it does absolutely nothing. I have tested it with the option turned on and off and the combat log still shows the same delay caused by latency - a 1 second GCD, for example, becomes 1.3 seconds with 300 ping, etc.
This is a fairly well documented factor, not only in FD, but also in MM thread where Whitefyst explicitly states that you have to add certain amounts of haste to accommodate for latency caused increase of GCD.
The whole discussion earlier was with regards to exactly that.
ES ES AS ES with 50 latency = 8 ticks
ES ES AS ES with 300 latency = 9 ticks
This is very simple: each GCD with 300 ping is 1.3 seconds. You are casting 3 GCD shots before the final ES = you are actually adding 0.9 seconds which resolves the issue with the final 9th tick. So if Krennick for example, leaves a small gap without casting anything before the final ES he will get the 9 ticks. Higher latency naturally adds that little wait time. This is a rather poor design from Blizzard in sense that they inevitably limiting players with higher latency from ever being the truly highest ranking DPS.

With regards to required haste levels, correct me if I am wrong, but with the 2T13 the haste requirement has become rather obsolete: you no longer have to have cycles with 3 CSs. From my experience raiding with SV in current content - as low as 500ish haste is more than sufficient. Of course this has to take in account the amount of latency you have to ensure that you do not lose too much time waiting for ES to come off the CD (when the time left is < 1 GCD) or have to finish after the ES is off the CD. The goal of haste is to ensure that you are ready to cast ES the very moment it's off the CD. There is no one single cycle to use, you could / should have cycles where you get 2 AS, or 1 AS or even 3 AS, each of these cycles would have a different amount of CS casts, hence the amount of haste required for each to be tight is going to vary. Additionally, haste only affects 2 things: the amount of auto-shots and CS cast time. The amount of CS casts required to sustain a solid cycle with 2T13 is so small that haste has become a nearly obsolete stat in that sense. With regards to auto-attacks and haste - it's a very small portion of our DPS, so i really don't see a point worrying much about it when you can increase all of your elemental damage (80ish% of your total damage) or your crit.

One issue Krennick points out well is that 'custom lag tolerance' introduces spell Qing - that, at least for me, causes a certain amount of LnL procs to be wasted on AS as the first cast. Basically LnL procs right after you Qed AS, and no matter your reaction - there is nothing you can do about it - it will eat the first stack of LnL. The chances of that happening are not drastically high - I've had something like 3-4 occasions of that happening in about a total of 3 hours of combat.

For many people, the primary win for this change is that we won't lose LnL procs to AS shots that were in progress at the time. Additionally, the two drivers that maximize LnL DPS are getting ES on cooldown ASAP and not missing any ES ticks. Given the current DoT implementation for ES, there will only be further benefit at very low latency.

• <50ms latency: ES AS ES AS ES minimizes risk of clipping while continuously dpsing.
• 50-300ms latency: DoT refresh only requires a single shot, so ES is on CD faster with ES ES AS ES
• >300ms latency: accumulated latency for instant shots prevents DoT clipping, so ES ES ES is best

Changes to Simc are required to simulate the latency impacts and ES pushbacks more carefully. For example, at 10ms latency, ES AS ES AS ES lands the third ES back to 4.040 seconds, whereas without the additional AS, it could potentially have landed the ES (and started ES's CD) at 3.030 seconds. That's pushes the ES cooldown back by 1.01 seconds, which reduces the number of ES's that get landed during the fight. Actually landing the third ES at 3.03 would risk clipping, however, since latency is typically variable (e.g., instead of 10ms latency, it would be more like 9-30ms). In my example, 30ms is not a lot of protection from clipping; one packet delay and the DoT gets clipped. So the key question is: How much additional delay is worth inserting in order to protect from the variability of network latency, as opposed to just inserting the additional AS (which gets some dps and precludes clipping, but pushes the ES out by a fair bit)? Just for a concrete datapoint, I took data from a recent (regular) Ultraxion fight.

Fight time	298
AS count	51
AS dmg avg.	20,950
ES count	43
ES dmg avg.	54,070
Sec/ES	6.7

Based on the above data, I compute how many ES would be lost because from cumulative delay to the ES cooldown, and then how much additional dps we get from using that delayed time for AS shots. The pushback also delays all other shots, so an inserted AS only gets "credit" for the amount of otherwise dead time that it uses for an AS (e.g., if ES is delayed by 0.7 seconds, I add ~0.3 * the AS dmg.)

Pushback	0.5	0.6	0.7	0.8	0.9
Total ES pushback	21.5	25.8	30.1	34.4	38.7
#ES lost	4	4	5	6	6
ES dmg lost	216,280	216,280	270,350	324,420	324,420
AS dmg gained	400,355	318,650	230,869	147,279	69,764
Net DMG	184,075	102,370	(39,481)	(177,142)	(254,657)
Net dps	618	344	(132)	(594)	(855)

So for this example, the break even would be right around 0.65 seconds of pushback on the ES; more than that and ES AS ES AS ES is a dps loss vs. ES ES AS ES. So waiting half a second would avoid clipping and be a dps increase. This napkin math has a pretty long average delay in LnL because of the mechanics of the Ultraxion fight. With a tighter ES timing of 6.1 seconds, the breakeven gets tighter (rgiht around 0.5 seconds at 6.1 seconds/ES). The numbers (300-800dps) are large enough to be interesting though, so I look forward to being able to simulate them.

So in the end, what custom lag tolerance would you recommend with a latency <50 ms? I was also thinking about the "cast on button down" feature. Is a good thing to enable it, and is it linked to custom lag tolerance somehow?

I think you both guys are talking about Explosive trap and not Immolation trap. Immo trap deals ridiculous damage.

Explosive trap deals roughly half the damage of BA on single target, there is no reason anymore to keep using it (if there was a reason on 4.3, 99% of progressing hunters where not using it but on Yor'sahj) on single target, now that both spells have the same chance to procc LnL

DPET on BA has not changed, it deals exactly the same damage as before for the same cast time (1 GCD)