New default timer interval (50ms -> 20ms)

[Playtester]

Hello all,

 

As of yesterday's commit (https://github.com/rathena/rathena/commit/525e8178c27327f000e15ba557c6ed37a371c0b2) the default timer interval was reduced from 50ms to 20ms.

This might increase CPU usage of your map-server. If you have trouble running your server with these settings, you can simply change it back.

 

To change it back just find /src/common/timer.c and change

#define TIMER_MIN_INTERVAL 20

to

#define TIMER_MIN_INTERVAL 50

 

In the following I will explain in-depth why we decided to change it despite the additional cost and what it'll effect.

First of all, the official interval is 20ms, for everything. This was known for quite a while already, even back in eAthena. Back then it was decided that performance is more important, so higher intervals were set and for certain cases workarounds were written.

Workarounds, however, are usually not a perfect emulation. Eventually there will always be a special case that is then again different from official servers and then you write another workaround for that. In the end, your code is full of workarounds (or simply not emulating accurately).

The intervals were added the way they are around 10 years ago. Of course back then not only was the hardware a lot worse, but there were also a lot more servers with a high population. These days the hardware is a lot better and you already consider a server with 100 players as one with a high population. The official timer interval of 20ms, should no longer be a hindrance for most machines and servers anymore.

Even if some server really has trouble with the interval, the owner can simply set the timer interval to what he needs (or buy better hardware alternatively), but we decided that the default setup for rAthena should be as close to official as possible.

So what are the benefits?

The greatest benefit of using the official interval for our timers is that it strongly improves the synchronisation between client and server. I realized this when I investigated why skills could be "chained" on official servers but failed to chain most of the time on my local rAthena test server. I originally thought the official server had implemented some kind of "skill queue" system that remembers all commands from the client and then executed them whenever there was time, this proved to be wrong. In fact, the client is the part that handles the skill queueing itself. It will remember skill requests the user requested and only send them to the server when it thinks a new skill can be used.

But this also means that server and client need to be in perfect sync or otherwise the client will send a new skill request while the server still thinks that no skill can be used yet. This is especially noticable at the end of a cast time. When the client doesn't receive the skill use packet fast enough, it will think that the skill failed and then send the next skill requests from its queue.

 

To illustrate this, here is an example:

Basically what happens with 50ms interval is this (assuming 160 aspd = 400ms aMotion):

- 0ms: the player casts a skill with 2000ms cast time

- 0ms: we tell the client "cast time 2000ms"

- 0ms: we create a timer to execute skill_castend at 2000ms

- 1000ms: the player issues another command to cast the same skill again, the client will remember it

- 2000ms: nothing happens (timer interval not reached yet)

- 2030ms: we receive a skill request from the client to cast the skill again, but since the current skilltimer is still active, we just drop it

- 2050ms: the skill gets executed

- 2450ms: now the server is ready to receive a new skill request (aMotion ended)

Because of this the skill request given during cast time gets completely lost.

With a timer interval of 20ms the following will happen:

- 0ms: the player casts a skill with 2000ms cast time

- 0ms: we tell the client "cast time 2000ms"

- 0ms: we create a timer to execute skill_castend at 2000ms

- 1000ms: the player issues another command to cast the same skill again, the client will remember it

- 2000ms: nothing happens (timer interval not reached yet)

- 2020ms: the skill gets executed

- 2020ms: client realizes the skill is executed and applies aMotion delay to the remembered skill

- 2420ms: now the server is ready to receive a new skill request

- 2450ms: we receive a skill request from the client to cast the skill again, server will accept it and execute the skill

In this case the skill request is not lost and you can easily chain skills together.

 

Note, that only some skills can be chained like this, particularly those with no after cast delay like e.g. Holy Light.

 

Of course this is just one example where client-server synchronisation matters. Timers are used almost everywhere, so there is a wide array of benefits from using the official interval. Everything simply feels more "fluent".

 

Another benefit is that with a timer interval of 50ms, skills with cast time would go off 30ms later than officially. It might only be a small delay, but especially for skills with low cast time or special situations where you get attacked a lot while trying to cast, an interval of 20ms is a noticable improvement. It also closes the gap between instant cast and cast time a little.

 

The interval is also relevant for "timer damage" as in, damage you receive in regular intervals. The timer interval used can for example have an effect on whether you manage to walk to the next cell between hits or not.

 

 

While we updated the timer interval, we did not update the skill unit timer interval you can find in skill.c:

#define SKILLUNITTIMER_INTERVAL	100

Even though the official interval is again 20ms, reducing this interval will have quite a big cost increase as it means that every single placed skill unit needs to be checked in this interval and there are only two skill units that even still use an interval this small: Firewall and Crimson Fire Formation.

With the default settings these skills will simply deal 5 hits every 100ms rather than 1 hit every 20ms. It is different from official servers and it is noticable and certainly not perfect in all situations.

If you just have a small server or think your machine can take it, then feel free to change the interval to 20ms:

#define SKILLUNITTIMER_INTERVAL	20

I tested this locally and it works perfectly fine (but of course me playing alone and placing a few fire walls and blaze shields is nothing compared to a big server with hundreds of units placed all the time).

[Azura Skyy]

Awesome update. Recently decided to nuke my server (pre-launch yet) and update rAthena and all that jazz, so this is certainly a welcome news post. However small the update may seem with this timer change, it actually sounds really great.

 

 

The interval is also relevant for "timer damage" as in, damage you receive in regular intervals. The timer interval used can for example have an effect on whether you manage to walk to the next cell between hits or not.

 

I look forward to seeing if things like this are at all noticeable and how people react to any differences they see.

Thanks as always,
~Azura Skyy

[Skorm]

Any improvements to usability are welcomed. Although the "official" algorithm used for moving is a hindrance at best so official isn't always better in my book.

 

Good job.

 

Edit: I read this twice and it seems sarcastic, but I genuinely approve of this change.

[Azura Skyy]

Any improvements to usability are welcomed. Although the "official" algorithm used for moving is a hindrance at best so official isn't always better in my book.

 

Good job.

 

Edit: I read this twice and it seems sarcastic, but I genuinely approve of this change.

Having said what you did, have you played with the movement on this time interval? How does it feel? Your statement seems like you don't like how that is effected.

Eagerly awaiting your reply,

~Azura Skyy

 

[Playtester]

I guess for default movement speed for players which is 150ms/cell a 50ms interval is more fluent because on official interval it alternates between 140ms and 160ms per cell. But the moment you have Agi Up it should a lot more fluent with the new interval because instead of alternating between 100ms and 150ms per cell it will only alternate between 100ms and 120ms per cell.

Of course irregular intervals might be welcome as it makes it easier to escape hitlock.

And in any case, default rAthena really should aim to be closest to official kRO as possible by default. In case of "official bugs and annoyances", we can always just provide a define or a conf option for it. Then it's up to the server owners to decide what they want to be official and what not.

[Skorm]

 

Having said what you did, have you played with the movement on this time interval? How does it feel? Your statement seems like you don't like how that is effected.

Eagerly awaiting your reply,

~Azura Skyy

 

 

It feels fine to me but unfortunately I'm not able to test it under circumstances that would matter most... Like pvp etc.

 

 

Edit:

 

If anyone wants like a visual representation of what this patch kind of does...

 

[Azura Skyy]

 

 

Having said what you did, have you played with the movement on this time interval? How does it feel? Your statement seems like you don't like how that is effected.

Eagerly awaiting your reply,

~Azura Skyy

 

 

It feels fine to me but unfortunately I'm not able to test it under circumstances that would matter most... Like pvp etc.

 

 

Edit:

 

If anyone wants like a visual representation of what this patch kind of does...

 

 

 

Thought you might like some acknowledgement on your illustration as you did put some effort into making it. Well done, Skorm. 

 

Regards,

~Azura Skyy

[Cydh]

In case of "official bugs and annoyances", we can always just provide a define or a conf option for it. Then it's up to the server owners to decide what they want to be official and what not.

just messing around and just noticed that this sentence is ambiguous, between rA also implement the "official bug" as "main dish" and put conf as "side dish" or put conf for "official bug" as "side dish"

[anacondaq]

Can anyone explain to me the bad side of this implementation in few words?

Is it affect PVP? WoE?

Edited December 27, 2014 by Anacondaqq

[Playtester]

I already explained all the effects above.

 

Skills will chain, the bad side is if you chain them but then later on decide you want to use another spell you can't because the chained skill will take priority.

Everything is checked in 20ms intervals which means things that were dividable by 50ms but aren't dividable by 20ms might flutuate more.

And more CPU usage of course.

 

Generally it should only bring improvements as long as your server is good enough for the amount of players you have.

[anacondaq]

I already explained all the effects above.

 

Skills will chain, the bad side is if you chain them but then later on decide you want to use another spell you can't because the chained skill will take priority.

Everything is checked in 20ms intervals which means things that were dividable by 50ms but aren't dividable by 20ms might flutuate more.

And more CPU usage of course.

 

Generally it should only bring improvements as long as your server is good enough for the amount of players you have.

 

Thank you very much. I think, it's not bad side of this improvement. I think it's good side! Thank you for this update.