Ok, in timing things I'm trying to determine (as best as
possible) the amount of time it takes for a fig hit to
travel from the hit to the fighit msg. This way I can be
more precise with my game timing suggestions.

So I wrote this script:




The idea being simple enough. Send a command to hit and
retreat, wait for the message to start rolling back in and
then time various steps.

Now my ping is about 160ms, so the entire timing is late
by 160ms, which I've timed using a similar approach for
confirmation.

On the other end I have:


It simply gets a hit and spits out the time. This way I can
subtract the 2 timings and get the processing delay. Lag will
still be an issue, but because it's the same for both sides,
the $mid timing and the fighit timing should both be offset
by ping.

All in all, what I should be getting is server processing...
or close to it (plus some variance).

Except my testing results are anything but consistent here.

Over 10 different trials, I get this difference from the $mid
trigger and the hit side:

1. 241
2. 131
3. 60
4. 40
5. 70
6. 30
7. 140
8. 220
9. 201
10. 240

That's all over the board. My ping is holding steady around 160ms
peaking to 180 at most, going to 150 at least. So I can see a 20ms
or 30ms variance, but 200ms?

There is something strange going on. I'm not accounting for it,
and I'm not sure what it could be. There's no strange processes or
sudden bursts on my side, nothing that would cause such a big
difference.

I'm wondering if there's something server-side that could be causing
a 200ms processing variance. But I don't see what it could be, or
what could be causing such a massive jump.

Thoughts?

Alrighty. So...

5 sectors of moving and dropping a fig take 1412ms. That's
282ms, plus 5ms for killing a fig. That's 287ms to get out
of the sector.

So the question is, what ping would we need to hit this
reliably, say 50% of the time?

Well the average of the above data set is 137ms. Assuming
then a 137ms difference between hitting and getting the
msg of the hit, what kind of ping would we need?

(mid - hit) + 287 - 25 = ping

Why -25?

-10 for pwarp, -10 for photon, -5 for script processing.

mid-hit = 137, so...

287 - 162 = 125ms.

So a 125ms ping would hit half the time giving the new
timings and the variance shown above.

That is very very tight. Too tight, IMO.

So how to fix this? Drop the photon delay to 2ms and the
pwarp delay to 5ms. That gives us 13ms right there. Bring
up the delay for laying figs to 15ms instead of 5ms, and
bring up the kill fig delay to 10ms instead of 5ms.

That adds 28ms extra total, for a target of 153ms. That's
good, 150ms ping is not too tight for a 50% average hit
rate.

Finally, to prevent pgridding from being too tight, we should
up the landing delay to 10ms. That will need tested a bit more.

did you backtest this against 3.09?

Something you might not be considering here is an event response delay. Basically, whenever the player receives an event that it might respond to, it resets the synch timer. What this means is, if you're going to attack someone and there's a 20 ms synch delay, but it's been 5 seconds since you did anything, you can attack immediately. But if you just did something else and attack immediately after, that's where you'd see the 20 ms delay. So even if you haven't done anything for several seconds, if your game receives an event notification, that would reset your synch timer so if you attacked immediately after, you'd still have that 20 ms delay. I don't know if that effects what you're measuring, but it's something you should factor in. As a general rule, after any notification of an event, your synch timer countdown starts over as if you just finished an action.

As far as what's causing so much variation in timing, there are just so many factors in play here. The obvious ones, plus some internal things like how frequently the game actually checks for events (every 250 ms). I'd guess that's probably your cause. It's just not feasible for event notifications to be instantaneous. The "heartbeat" of the game is a quarter second. When you're talking about nailing these timings down to the millisecond, that just isn't going to happen. In fact, the only way to force things like event notification delay, send/receive delay, and network latency to have a lesser effect on gameplay is to increase these synch delays so that the synch delays absorb the other "background" delays. I'm not saying this would be good for gameplay, but just to illustrate the principle, if there's a 1 second synch delay for any action, then all of these variable delays caused by latency, CPU lag, TW I/O and event processing, etc, are hidden by that synch delay. I don't know how long these pacing delays would have to be to mask out these other delays. If you're seeing a variation of 250 ms, then maybe a 250 ms synch delay would do it (at least for any action that is effected by these background delays). I know it seems like a bad idea to put that kind of delay on anything, but if we're seeing up to that much delay WITHOUT synch delays, then you're not really introducing new delay, you're making the existing (potential) delay consistent.

Of course it's possible that I can improve the situation by looking at ways to optimize my IO and event processing systems. I will continue to look at that. But anything I do to improve the event notification time is likely to increase CPU load. Maybe I have enough to spend on this. I'll look at a 50 ms event period. Back when I first created the processing interval (how often the game looks for events and processes them), the overhead of processing events was pretty high. That's what the "average interval lag" on the @ screen is showing, how long it's taking to process events on average. There was a time when this measurement actually showed something above zero on most games ;) I'll explore this and see if I can do better, and if I can, let's see if that tightens up your event response time.

Ok, my early tests of running a faster event polling rate looks pretty good. I think this is something we can explore. I'm going to give a 50 ms event processing period a try. I'm going to change the @ command output so it shows more meaningful information on this. I'd like to show a percentage of this period that's spent on event processing, to make sure we're leaving plenty of idle time, and I'm also going to display a maximum along with the average for this measurement.

I'll get this loaded up at classictw.com and we can do some more measurements. The only effect it should have is on decreasing the lag between an event showing up in the queue and it being processed by a player. It'll drop from a potential 250 ms delay to a potential 50 ms delay.

JP, I waited at least 3 seconds between each run to
make sure any timers or CPC affects weren't included.

But what it sounds like you're saying is that the game
has a "heartbeat" of a quarter second regardless, so
commands will either happen around the current beat
or the next beat? So either 0+delays+variance or
heartbeat+delays+variance? That would explain my results
a bit, and I did not know that.

If a 50ms polling rate fails, try a 100ms polling rate?
I think either would make a big difference on the averages
and give people with slower pings a better chance.

I look forward to testing it.

Sounds like a photon duration of 1 second not really being one second. Just depends on where you fire before the second clicks.

               / Promethius / Enigma / Wolfen /

"A man who has no skills can be taught, a man who has no honor has nothing."

Which fits observation perfectly. This is why traitor's 1
second photon script uses the clock to time the torp, and
why most people use pwarp to move between sectors with
a 1 second torp. Gives you a chance to maximize the small
window of torpage.

Yeah, this system was never designed to deal with the kind of timing that it's currently played at. Back when it was written, the CPU and connection speeds kept things running slow enough that a 250 ms event polling interval didn't matter much.

Ok, let's really stress this and test a 10 ms polling interval. I changed the interval driver from a windows timer with a resolution of +/- 15 ms to a high resolution timer event with a resolution of +/- 2 or 3 ms. So the range of event processing frequency should be between every 8-12 ms. Back when this was first written, that polling loop alone would have driven the CPU at about 20% at idle. I tested a variety of polling rates and decided that quarter second was fast enough without dragging on the CPU.

I'll post this soon and let you know when it's there. Changing the internal timing is a big change with the potential to create some bugs. I was careful, but the best way to know if there are bugs is just to get it out there so people can play it and report.

Change it on Classic...we have the dregs of a game going and can test there.

Yeh, I can test it there too.

Ok, it's up there. Let's see what this does.

Ok, 10 timings at classic...
120
90
140
140
140
170
200
150
80
90

Avg 132. It definitely helped, narrowed the spread
from high to low and improved the average a bit.

Add in the suggested timing changes above, and I
think we've got a good baseline.

Ok, I'll get those timings changed tonight.

We need to get a good "live" test of the new polling interval to make sure this is stable. Hopefully the classictw.com game will give us a good test. I'd think any problem related to the new timing will stick out like a sore thumb.

At some point, I'd like to do some tests of a few other interval times, just to see if 10 ms is significantly better than 50 or 100. No sense in having it that tight if players don't see a difference.

I'll run wsst tonight and see how it fares.

Nothing says stressin the server like hours of xporting.

Edit: Bought some ships at dock, am running wsst right
now. Everything stable?