Lately I've been experiencing intermittent lag. It happens fairly frequently, but the pause is never more than 1-2 seconds. I could be wrong, but I don't think it's my connection.

Worth investigating?

n/t

So long, and thanks for all the fish!

Still seeing this, btw. Whenever I do I ask on the newbie channel and usually get broad agreement that it's game-wide and not just my connection. Just thought I'd mention it in case it's fallen off the radar.

Ticks seem to be longer too. But the pause in game is killing me, really breaks the flow of the game.

No text

That which does not kill us,
makes us stronger.

more than once because I thought wifi or something died. Luckily the game pauses and it isn't packet loss or anything.

>Still seeing this, btw.

And I've got no idea what it is. No clue where to look. Everything in game is running smooth and silky, which means it's likely other processes on the box I have no control over.

So long, and thanks for all the fish!

Do we share the hardware with other folks? I guess I assumed it was dedicated.

>Do we share the hardware with other folks? I guess I assumed
>it was dedicated.

We do share now. Prior to the move it was dedicated hardware.

On the plus side...I do have a new theory...will reboot and test it out in a little bit.

So long, and thanks for all the fish!

So what was the culprit?

100+ sql queries/updates in the same function.

So long, and thanks for all the fish!

Holy crap. Yeah, that sounds no bueno.

FWIW I was on for about 30 minutes today and didn't run into any lag.

As in, the pace of rounds coming are very slow. I feel like I can take a sip of coffee in between rounds. And then there's the lag spikes like you mentioned too.

I never paid attention, but if it lags specifically at tick change, it's probably some prog that needs optimisation. The muds are not processor-intensive, but they typically have peaks of CPU load on tick change.

Otherwise, it may be a problem with the hoster not providing enough bandwidth, losing packets of data or whatever else.

This was a problem a year or two ago and Zulg fixed it by optimizing a bunch of stuff. I'll dig up that same script I used last time to see if the lag was periodic or if it occurred randomly.

My script from last time is available here:

http://forums.carrionfields.com/dc/dcboard.php?az=show_topic&forum=6&topic_id=24340&mesg_id=24340&listing_type=search#24342

"go" to start and "off" to stop.

I ran it again and it did indeed show some lag spikes, but they're not regularly occurring and don't seem to be related to game ticks.

99% of all commands had a round trip of ~250 ms, but a few were ~1000 ms and one was 4817 ms. I had ping running simultaneously in a separate window and it didn't register any network issues.

Along with that optimization I added in a boatload of data-mining with regards to performance for the various things that happen at regularly scheduled intervals.

Of those there are two that are over their goals.

|Function                      |Rate           |Max     |Goal    |Over Goal|
----------------------------------------------------------------------------
|mobile_update()               |4 seconds      |0.35 sec|0.25 sec|0.10%
|violence_update()             |3 seconds      |0.18 sec|0.15 sec|0.06%

So long, and thanks for all the fish!

Hmm. Are you calling time() to get wall clock time? Or using clock() and CLOCKS_PER_SEC to calculate process time? If the latter, then the monitoring code wouldn't pick up slow ticks caused by I/O waits or another process monopolizing the CPU.

Not trying to patronize you here- just brainstorming. In the minute or so that I let the script run there were maybe 4 or 5 round-trips that were longer than 500 ms. (My ping from work is a ridiculous 7 ms).

>Hmm. Are you calling time() to get wall clock time? Or
>using clock() and CLOCKS_PER_SEC to calculate process time?
>If the latter, then the monitoring code wouldn't pick up slow
>ticks caused by I/O waits or another process monopolizing the
>CPU.

Good point...I'm using clock() & CLOCKS_PER_SEC...great...now I have more work to do

So long, and thanks for all the fish!

Both are valuable. clock() teases out problems with the mud code itself while time() catches resource contention issues.

Do you run the mud at certain "nice" and "ionice" levels? Upping both those priorities might help in the short term.

nice -19 ionice -c1 -n0 /path/to/mud/executable {args}

That should give the mud code the absolute highest CPU and I/O priority. (Which may be a bad thing if it monopolizes either.)

>Both are valuable. clock() teases out problems with the mud
>code itself while time() catches resource contention issues.

Yeah, problem with time() is that it doesn't have the precision since it's smallest unit is one second. I did add in checks using it, so we'll see if anything shows up.

>Do you run the mud at certain "nice" and "ionice" levels?
>Upping both those priorities might help in the short term.

Nope, run the mud at standard priorities. I'll keep it in mind if the recent changes don't turn up anything.

So long, and thanks for all the fish!

>Yeah, problem with time() is that it doesn't have the
>precision since it's smallest unit is one second.

Doh. Forgot about that. One of these may work:

http://linux.die.net/man/2/gettimeofday
http://linux.die.net/man/3/clock_gettime

First looks more promising. If the system is Solaris you could try:

http://manpages.unixforum.co.uk/man-pages/unix/solaris-10-11_06/9F/gethrtime-man-page.html

>Nope, run the mud at standard priorities. I'll keep it in
>mind if the recent changes don't turn up anything.

Another alternative is to run your non-mud jobs at lower priorities. Like if you're doing a build, running a test server, etc.

To get the current time, do something like:

#include <sys/time.h>
...
struct timeval start;
gettimeofday(&start, NULL);
long lStart_secs = start.tv_sec;
long lStart_ms = start.tv_usec / 1000;

but, yeah, it's affecting me, too. And I'm in the Northwest, not anywhere near Texas. Latency ftl.