Please upgrade your browser for the best possible experience.

Chrome Firefox Internet Explorer
×

How to reduce ability delay?

STAR WARS: The Old Republic > English > Classes > Roles
How to reduce ability delay?

thatguybil's Avatar


thatguybil
02.11.2016 , 01:12 AM | #21
Measure using Star Parse. Measured from the time of Star Parse registers the ability activation not the damage.

Imp sniper zero alacrity
corrosive dart--->penetrating blast. expected ~1.5 second Average over 10 runs 1.407 (faster then expected)
Penetrating blast--->FT expected ~2.0 seconds. Average 2.03 seconds.
Snipe-->Snipe Expected ~1.5. Average 1.55. Low 1.505 High 1.6

Rep
Gunslinger. 977 Alacrity (10.04%)
VS-->PR expected ~1.35 seconds. Average 1.04 seconds
PR-->TS Expected ~1.8 second. low = 1.996 Average 2.12 range 1.996-2.237
CB-->CB expected 1.35 seconds Low 1.382 High 1.455

Rep
Gunslinger 73 alacrity (0.9%)
VS-PR expected ~1.5 Average 1.37 Low 1.317 high 1.409
PR-TS expected ~2 average 2.087 Low 2.085 High 2.096
CB-->CB expected ~1.5 average 1.59 Low 1.515 High 1.631

Rep
GS Burst Volley alacrity buff 20.04
PR-->TS Expected ~1.6 seconds
1.807
1.897
1.897
1.789

I'll do some more testing but going from PR-->TS is not working correctly. It is consistently longer (slower) than I would expect.
Also the time from an instant (VS) to a cast (PR) is shorter than I would expect

cxten's Avatar


cxten
02.12.2016 , 03:21 AM | #22
Did some testing on my Sage with zero gear on, so a GCD of 1.5 seconds, using disturbance, mind crush, saber strike, and weaken mind. Round numbers of 1.50 and 1.60 seconds (rounded to the nearest .01) show up surprisingly often. Here are my impressions from looking through the logs trying these various abilities. (My apologies for being too lazy to provide more concrete counts and statistics.)

Disturbance: The large majority of casts took 1.60 seconds.

Mind Crush: Smaller sample size, as I put these in a rotation with Disturbance, but a majority took 2.10 seconds

Saber Strike: Nearly all took 1.50 seconds. Notably, several of the times that it was off it was 1.60 seconds (though there were rare other values as well).

Weaken Mind: Here the majority were 1.50 seconds, but there were also a good deal of 1.60 seconds (as well as a few others)

I also tried alternating Disturbance - Saber Strike. This was interesting:

Time elapsed for Saber Strike was often 1.60 seconds
Time elapsed for Disturbance was often 1.50 seconds
(there was occasional variation with less round values, as above, but a sizable number were round)

(Time elapsed for an ability means the time from its activation in the log to the activation of the following ability.)

What this seems to suggestis that there's a problem which primarily shows up at the beginning of a casted ability that causes a 0.1 second delay.

(For reference, my server lag during this experiment was 84 ms. I took the less scientific route and just spammed the keys. My spamming rate was perhaps on the order of 0.1 seconds, though I was not entirely consistent; I also tried faster spamming, probably close to 0.05 seconds, with similar results.)

One more anecdotal observation: I tried casting Disturbances only pressing the key once per cast. This still was mostly 1.60 seconds, but there were a small number of 1.50 casts, whereas when I simply spammed the key I had no 1.50 casts. Sample size roughly 20 for each.

-

As to the post above me referencing the Penetrating Rounds - Trick Shot transition as being slow, this has been the case going back to Speed Shot - Trick Shot days. My guess has been that there's some delay here related to confirming that Trick Shot has in fact reset/procced.

Elzen's Avatar


Elzen
02.15.2016 , 11:43 PM | #23
From a programmers perspective (though not one who has ever actually written/worked with large distributed systems), excessive button mashing could be causing synchronization problems that is adding latency. I've heard anecdotal evidence from a couple of people who parse heavily that *reducing* the queue time and pressing a key only once can actually help with latency; though sometimes at the cost of the skill not going off at all due to dropped packets. Perhaps someone can do an experiment with this somehow?
Quote: Originally Posted by Grumpftard View Post
The secret to tanking is to play like a crappy DPS. Play it like that DPS in the GF that always makes you say "*** is this guy doing?"

KeyboardNinja's Avatar


KeyboardNinja
02.16.2016 , 06:12 PM | #24
Quote: Originally Posted by Elzen View Post
From a programmers perspective (though not one who has ever actually written/worked with large distributed systems), excessive button mashing could be causing synchronization problems that is adding latency. I've heard anecdotal evidence from a couple of people who parse heavily that *reducing* the queue time and pressing a key only once can actually help with latency; though sometimes at the cost of the skill not going off at all due to dropped packets. Perhaps someone can do an experiment with this somehow?
Generally, the only case I'm aware of where button mashing can result in increased latency is if you're button mashing on a cyclic period which intersects poorly with your latency and your ability action queue, resulting in you getting the ability to the server later than you would have with a calmer (and more measured) timing. In this case, we've eliminated that possibility.

Regarding your broader point…* The SWTOR client doesn't send every keystroke or even every activation attempt to the server. Doing so would allow malicious users to DoS servers by simply sending an impossible number of failed activations per second, forcing the server to react to them all. Instead, what happens is the server communicates to the client on the timing of the GCD, and the client then determines a queue of actions which fit within that GCD. Anything off-GCD is of course exempt to this. Once the timing "quantizes" between the server and the client (i.e. a GCD boundary is about to be reached), the client sends the top element of this queue to the server, which then puts it in its own queue and activates the action at the true GCD boundary (rather than just trusting the client). This results in some weird syncing behavior sometimes, notably where your client's notion of timing can fall a bit out of sync with the server and your abilities start going off at the "wrong" time.

This sort of "buffer, enqueue and dump" design is very common in all forms of distributed systems as it encodes a variant of "negative feedback". Basically negative feedback is where a system speeds up its processing as a function of input volume as you apply higher load to it. In this case, the "load" is simply the keystrokes/clicks, and the processing rate is the number of calculations which must be performed by the server and the client per activation. The negative feedback comes from the fact that the client is able to discard most of the information you're giving it, and the server is further able to discard an additional subset, and they are both able to make that determination efficiently. This improves responsiveness on both sides and allows the server to scale to a large set of concurrent users.
Computer Programmer. Theory Crafter. Dilettante on The Ebon Hawk.
Tam (shadow tank) Tov-ren (commando healer) Aveo (retired sentinel) Nimri (ruffian scoundrel)
Averith (marksman sniper) Alish (lightning sorcerer) Aresham (vengeance jugg) Effek (pyro pt)

December 13, 2011 to January 30, 2017

thatguybil's Avatar


thatguybil
02.18.2016 , 01:19 AM | #25
More testing
Change ability queue time from 0.75 to 0.25

GS
Alacrity 10.04%
expected ~1.35
VS-->PR
1.293
1.298
1.298
1.324
1.191
Mostly faster then expected. No change from queue time of 0.75-->0.25

PR->TS
expected ~1.8
2.194
2.065
2.094
2.186
2.095
Slower then expected

(CB-->CB)-->AS-->TS
I am using CB to buff AS and already have TS ready. Per theory above TS is delayed after PR because the server needs to register the TS is available. If TS is already available we should not see a delay after the AS cast.
expected ~1.35
1.51
1.495
1.416
1.518
1.43
Average 1.474
range 1.43-1.51
Still not as fast as expected but better then PR-->TS

(CB-->)PR-->TS
Same test. Using CB to buff TS before doing the PR channel.
Expected ~1.8
1.904
1.809 ("clipped" logged all five, but screen stated channel was canceled)
1.913
1.903
1.9
1.913

I was not able to get another clipped PR where all 5 shots (5 main hand and 5 off hand) registered.

I am not sure what to make of this.
For Rep Gunslingers
1: Instant abilities seem to be slower then expected after channeled and casted abilities
2: For PR-->TS it is way slower then expected. Like due to the delay in registered the buff.
3: VS-->PR the ability is faster then I would expect by a wide margin.
4: Change the Queue time from 0.75-->0.25 did not seem to make a difference.

Lodinn's Avatar


Lodinn
02.18.2016 , 06:59 AM | #26
Quote: Originally Posted by KeyboardNinja View Post
set the automated keyboard frequency to something like 1/40ms; my music background suggests that I'm spamming my abilities right around that rate when I parse).
Just logged in to say that I'm amazed with you yet again, KBN. That's just brilliant

EDIT: Also, 1/40 ms is... err... Are you even human?
Lterri | Estiuette | Shulmanu |Tenebrosa | Fabantou |
Sneitha | Ton'itra | Lodinn | Flèchette | Tiponi |
Pls'taunt | Gjalla/This'is'madness | Guédé | Cornifer
TRE pugging all the way [IMP]

Lodinn's Avatar


Lodinn
02.18.2016 , 07:29 AM | #27
Quote: Originally Posted by KeyboardNinja View Post
Generally, the only case I'm aware of where button mashing can result in increased latency is if you're button mashing on a cyclic period which intersects poorly with your latency and your ability action queue, resulting in you getting the ability to the server later than you would have with a calmer (and more measured) timing. In this case, we've eliminated that possibility.
Not necessarily cyclic, but you reminded me - if you can make some programmably-fed input, it's totally worth to make it pseudo-random with different density parameters so to eliminate weird frequency response that might happen otherwise.

Quote: Originally Posted by KeyboardNinja View Post
Instead, what happens is the server communicates to the client on the timing of the GCD, and the client then determines a queue of actions which fit within that GCD.
Isn't that making latency strike at its full? I've always thought queued ability actually IS sent to server, all that is needed is to contact client twice and not just once.
I mean, let's suppose my lag is 100 ms. If i set ability queue to 250ms and server contacts me 250ms before my GCD ends, finds an ability, executes it exactly at the end of GCD, during the remaining 250ms I find myself in a pretty bad place so I try to press some defensive but some other ability is already being executed. So in this case I probably have killed myself with the ability queue setting, thus I lower it to 100ms or something and voila!

Also, how do you resolve alacrity issues? Especially those coming from raid buffs etc.?
I mean, don't you have to contact clients at the rate provided by alacrity hard cap rather than 0% alacrity?
Lterri | Estiuette | Shulmanu |Tenebrosa | Fabantou |
Sneitha | Ton'itra | Lodinn | Flèchette | Tiponi |
Pls'taunt | Gjalla/This'is'madness | Guédé | Cornifer
TRE pugging all the way [IMP]

KeyboardNinja's Avatar


KeyboardNinja
02.22.2016 , 02:32 PM | #28
Quote: Originally Posted by Lodinn View Post
Just logged in to say that I'm amazed with you yet again, KBN. That's just brilliant

EDIT: Also, 1/40 ms is... err... Are you even human?
LOL. I suspect most gamers are capable of achieving that rate without even thinking too much about it. Here's a bit of timing intuition…

Imagine you're looking at a user interface element, like a button. You know that when you click the button, something is supposed to change state (like, the UI turns green). You click that button and it feels like the response was not quite instantaneous, but very close. In other words, you perceived enough of a delay that you wondered for a split second if the button click had even registered. That amount of time is 150 milliseconds (200 for most people, but as a gamer you have faster reflexes, so probably closer to 150). So scale off of that. One button click every 40ms is right around four clicks in the span of time it takes you to wonder whether or not a UI is frozen. As I said, I'm pretty sure most gamers are capable of achieving that input rate. :-)

Quote: Originally Posted by Lodinn View Post
Not necessarily cyclic, but you reminded me - if you can make some programmably-fed input, it's totally worth to make it pseudo-random with different density parameters so to eliminate weird frequency response that might happen otherwise.
Indeed. If we could run automated testing of this sort (the devs can, so the engine is certainly capable), we would be able to provide much more statistically robust input.

Quote: Originally Posted by Lodinn View Post
Isn't that making latency strike at its full? I've always thought queued ability actually IS sent to server, all that is needed is to contact client twice and not just once.
The queued ability is sent to the server, but only once it is actually necessary. The client does pre-send it, but only "action queue window" time prior to the GCD interval.

Quote: Originally Posted by Lodinn View Post
I mean, let's suppose my lag is 100 ms. If i set ability queue to 250ms and server contacts me 250ms before my GCD ends, finds an ability, executes it exactly at the end of GCD, during the remaining 250ms I find myself in a pretty bad place so I try to press some defensive but some other ability is already being executed. So in this case I probably have killed myself with the ability queue setting, thus I lower it to 100ms or something and voila!
The server is actively syncing GCD boundaries with the client. It's not that the server asks the client "what ability do I do now?" Rather, the server actively keeps the client apprised of "I will need the next ability at this point in time", and the client contacts the server at some point prior to that time, as determined by the action queue window.

Also, you can most certainly kill yourself with the action queue window. A notable place where this happens is interrupts on casters, since the action queue window is used to define a period at the tail end of a cast where you're "locked in" and the cast is going to complete, regardless of what you do (another place where this happens is reflects, as on Ruugar).

Quote: Originally Posted by Lodinn View Post
Also, how do you resolve alacrity issues? Especially those coming from raid buffs etc.?
I mean, don't you have to contact clients at the rate provided by alacrity hard cap rather than 0% alacrity?
Yep. This is taken into account with the server's active syncing. When the next boundary shifts, it notifies the client accordingly. If you have high enough latency, this can result in client-side "hitching" if the window moves dynamically from a period in the future to the past (from the perspective of the client).
Computer Programmer. Theory Crafter. Dilettante on The Ebon Hawk.
Tam (shadow tank) Tov-ren (commando healer) Aveo (retired sentinel) Nimri (ruffian scoundrel)
Averith (marksman sniper) Alish (lightning sorcerer) Aresham (vengeance jugg) Effek (pyro pt)

December 13, 2011 to January 30, 2017

GrandLordMenace's Avatar


GrandLordMenace
02.29.2016 , 03:36 PM | #29
Quote: Originally Posted by Lodinn View Post
Just logged in to say that I'm amazed with you yet again, KBN. That's just brilliant

EDIT: Also, 1/40 ms is... err... Are you even human?
IIRC my WPM is 98 in typing tests. KBN's like 180. Chew on that.

/criesincorner
Rydarus Veneris the Revanchist, Beater #fedaracarrychist
Vigilance Guardian guide on Dulfy! Like my guide? Support my Referral Link!
Last Guardian DPS because dead game

KeyboardNinja's Avatar


KeyboardNinja
02.29.2016 , 05:42 PM | #30
Quote: Originally Posted by GrandLordMenace View Post
IIRC my WPM is 98 in typing tests. KBN's like 180. Chew on that.
Not quite. :-) It's 150-180 depending on what I'm typing and only if I'm typing on a real keyboard (Cherry MX switches ftw) and also only if I'm actually trying to type fast. On this precise keyboard (my macbook), I cap out around 130, and I usually sit closer to a comfortable 115 just because it's less effort.

Incidentally, Ry, your typing test may be selling you short. Most tests are designed for people who sit in the 50-90 WPM range (e.g. by showing a sentence at a time). A lot of people actually type quite a bit faster than that, but the test itself doesn't allow for higher speeds due to the way it interacts with the mechanics of typing so fast. A better test is something that literally just shows you a paragraph or two of text and asks you to copy it. The reason being that extremely fast typists have a tendency to plan their motions more than a sentence in advance (I generally think in terms of phrase "blocks"). Seeing the whole paragraph allows you to do that, while a more conventional test does not.

So google around for a real test and try again. You might find you're faster than you think you are.
Computer Programmer. Theory Crafter. Dilettante on The Ebon Hawk.
Tam (shadow tank) Tov-ren (commando healer) Aveo (retired sentinel) Nimri (ruffian scoundrel)
Averith (marksman sniper) Alish (lightning sorcerer) Aresham (vengeance jugg) Effek (pyro pt)

December 13, 2011 to January 30, 2017