Hey, Sing, sorry to do this to ya, but I need you to do another test pass with the version I just uploaded. I think there must have been a game hung in the task manager because the new TW.exe didn't take. I just did a new install and verified that it's the correct version.

With this version, the current load of players is pulling about 10% CPU with most players idle. So we're definitely seeing overhead from this tight polling interval of 10 ms. I want to leave it at that because it's a good stress test, and we can also get a good idea of how much this interval effects our event timing. But I'm pretty sure I'm going to need to increase it from 10 ms because this is too much CPU for idle.

Alrighty, just a few...

Edit: With the new polling, I'm getting a lot of 0
differences. At most, I've seen maybe 30ms. So
the new poll timing could definitely be relaxed.

Edit 2: How's the load looking?

Ok, so this definitely tightened up your readings?

The load isn't terrible. With you running your script and others idle its about 20%, with one spike to about 35%. The polling CPU load has periodic spikes. I'm going to look and see if there's some kind of deadlock that's causing spikes. One process will be 0 CPU for a few seconds, then spike to 3, up to 8% for a split second, then back to 0. Since I started the server again, the idle games have only logged about 15 to 20 seconds of CPU time. You've logged a lot more with your scripts. TWGS, btw, has logged about 10 seconds of CPU time, just for reference.

Whatever is pulling the extra CPU, it's caused by having several players in a game. With one or two players, the CPU stays at 0.

I'll explore it a bit and see what I can figure out. I definitely think we're on to something here that will improve the performance of the game. I can make this a setting as well so a gameop with a powerful system can set this to as low as 10 ms and get very fast response times, but someone with a slower system may want to run it closer to the old 250 ms setting.

Yes, to the point where it's not worth even posting them.
20 0ms, a few 10ms, a few 20ms, 1 30ms. No 200ms.



What's xport delay at? And does space abort the xport
list details? Wsst moves, xports a bunch back and forth
in a burst, busts, furbs, repeats. The lag bursts you're
seeing are very common in unlims where people run a
lot of worldSSTs. Anything you can do to reduce that load
would be awesome, it's a big problem.



I think that's a good idea.

I did put in the full abort code for transport list, fig list, mine list, etc, the whole list you gave me. So those should be more efficient.

The CPU spikes I'm seeing are definitely not caused by any player activity. It's entirely internal processing. I'll do some profiling and figure out where it's coming from.

We are not doing much in game G atm but it appears steady and pings are even.
Cim's and fig refresh are fast and smooth

If nothing else, I can do that too while I'm at home today.

Feel free to shoot me if you want. Might be fun!

Darnit.. closed game.

Good news. I decided to split the event processing out from the background processing (internal alien movement, etc). The background processing will continue to happen every 250 ms as before, but event processing will happen on demand. Back when this was written, the only way to do events was to have each game polling a message queue. But now that the DOS version is no longer supported, I'm not limited to systems that work under DOS. I created a way to pass messages directly between games using the windows message system. When a game posts an event to the message queue (something like "player entered sector", or an update of a data file), it posts an alert to the recipient of the event. This tells the recipient game to pull the event from the message queue as before. Without any load, this allows the recipient to pull and process the event within the same millisecond that the sender posted the event. We'll have to see how much lag there is with a heavy load of players. Hopefully no more than a few milliseconds.

The benefit here is that the game runs with the same negligible CPU load at idle, but has an approximately zero event notification delay rather than the up to 250 ms delay that it has had.

I'll post this on classictw.com so we can test it. The majority of the event system is unchanged. The only change is in how games are pulling the events (on demand rather than polling). If there are bugs, it would result in some messages being missed, data not getting refreshed when changed by another player, etc.

Something is broke. Fig refresh get about 20 records then exits u to main menu

Fixed.

Ok, the new event system is functional on classictw.com. It's back to running at about 2% CPU rather than 20% with the currently active players. Hopefully if there are any issues with the event system, it'll show up over the next few days.

Sing, if you have a chance to do some timing tests to see how this works, let me know your results.

Thanks!

Fascinating. I'll give it a good test tonight.

Will there be a problem with large corps? If
there's 20 ppl on a corp, and a single fighit
to broadcast to all of them, would that cause
a problem?

What about the same situation, but where
someone mows thru and hits a dozen figs?

New results:
20
10
0
0
0
30
0
0
10
20
0

Now my ping varies 20ms/30ms, so the variance
here could be my ping. Altho, that doesn't explain
the even increments of 10. Never-the-less...

Looks a lot better. If it runs stable, then I think its
a winner.

Now its just a matter of figuring out the timings on
the new system.

Oh, Sing, I forgot to mention that the @ screen now includes a "Event Lag" line. What this does is grab the current time, post a test event, wait for that event to come back, then grab the time again. It shows the elapsed time for sending an event. Even though this test event comes right back to the same game, it uses the exact same pathway that all events will use, so it's an accurate measure of the time for an event to be sent and received. Under heavy load, this can be used to determine if event lag increases.

As for the timings, I'm ready to implement the timings you requested. I wanted to make sure the timing results were as expected and nothing changed that might effect the timings you requested. If you still feel they're the best, I'll go ahead and give them a try.

JP if your going to make this a sysop option can you see about getting the low end of the setting down to 5 ms. Some of us with multiple cpu's can make use of it. TWGS v2 and worldgroup together have yet to use more than 3-6% cpu usage with 20-25 users online.