The Dammed Lag - Page 2

Znurre · 05-02-2007, 09:23 AM

Well... It's true that the inner realm lag is not noticable.
The warzone is the problem.

I bet the servers cant handle all the information, the CPU gets overloaded.
And that's surely because of the server code.

Indeed, server code can be very tricky

So it's not a very easy job for NGD.
They are trying to stress test the servers in the experimental server, so the best thing you can do if you want to help them reduce the lag is to come there when they write like "- TODOS AL EXPERIMENTAL -" in the official server.

The more users currently online in the experimental server, the better tests they can do. So please help by joining the experimental server, if just for 20minutes

mute · 05-02-2007, 10:26 AM

That's right.

I was levelling in the WZ and it was impossible for me to play with the lag.

Then I went outside the WZ and there I had no problems.

_Meldanen_ · 05-02-2007, 10:28 AM

I remember the chat didn't lag yesterday. Is it on another server as well?

The reason for lag isn't limited CPU resources or limited memory by default.
E. g.: If you have an event queue that suspends the members for an amount of time, given:
System time 2:00:00.000

Items to suspend:
i1 for 2000[ms], i2 for 4000[ms], i3 for 6000[ms]

now you have two options:
1. use a delta queue, this leads to:
i1 for 2000[ms] -> i2 for 2000[ms] -> i3 for 2000[ms]

2. use a system time queue, this would lead to:
i1 at 2:00:02.000 -> i2 at 2:00:04.000 -> i3 at 2:00:06.000

Both queues have pros and cons.
E. g.: it is not possible to ensure that the suspend time was exactly 2000[ms]. Therefore the delta queue needs a correction or errors will sum up.
Let's say the real suspended time on the delta queue was:
2008[ms], 2004[ms] and 2012[ms]
Therefore i3 was delayed for 6024[ms]. Given enough events and no correction this can considerably lag items if the list grows larger, even if the CPU isn't stressed at all.

But I'm sure the employees at ngd know the basics - it was moreover an example that it's not always a CPU issue. We don't know the code, therefore it would be wild guessing but we can help by describing very detailed where the problem is and what is affected.

Regards

05-02-2007, 09:23 AM	#11
Znurre Marquis Join Date: Jan 2007 Location: RA Posts: 1,897	Well... It's true that the inner realm lag is not noticable. The warzone is the problem. I bet the servers cant handle all the information, the CPU gets overloaded. And that's surely because of the server code. Indeed, server code can be very tricky So it's not a very easy job for NGD. They are trying to stress test the servers in the experimental server, so the best thing you can do if you want to help them reduce the lag is to come there when they write like "- TODOS AL EXPERIMENTAL -" in the official server. The more users currently online in the experimental server, the better tests they can do. So please help by joining the experimental server, if just for 20minutes __________________ Winning a fight is not what makes you a good player, it's how you do it. http://home.znur.re/screenshot%20201...2011_39_37.jpg

05-02-2007, 10:26 AM	#12
mute Master Join Date: Mar 2007 Location: Germany Posts: 254	That's right. I was levelling in the WZ and it was impossible for me to play with the lag. Then I went outside the WZ and there I had no problems.

05-02-2007, 10:28 AM	#13
_Meldanen_ Pledge Join Date: Mar 2007 Posts: 46	I remember the chat didn't lag yesterday. Is it on another server as well? The reason for lag isn't limited CPU resources or limited memory by default. E. g.: If you have an event queue that suspends the members for an amount of time, given: System time 2:00:00.000 Items to suspend: i1 for 2000[ms], i2 for 4000[ms], i3 for 6000[ms] now you have two options: 1. use a delta queue, this leads to: i1 for 2000[ms] -> i2 for 2000[ms] -> i3 for 2000[ms] 2. use a system time queue, this would lead to: i1 at 2:00:02.000 -> i2 at 2:00:04.000 -> i3 at 2:00:06.000 Both queues have pros and cons. E. g.: it is not possible to ensure that the suspend time was exactly 2000[ms]. Therefore the delta queue needs a correction or errors will sum up. Let's say the real suspended time on the delta queue was: 2008[ms], 2004[ms] and 2012[ms] Therefore i3 was delayed for 6024[ms]. Given enough events and no correction this can considerably lag items if the list grows larger, even if the CPU isn't stressed at all. But I'm sure the employees at ngd know the basics - it was moreover an example that it's not always a CPU issue. We don't know the code, therefore it would be wild guessing but we can help by describing very detailed where the problem is and what is affected. Regards