Author Topic: Virtual time in fluffos  (Read 3720 times)

Offline FallenTree

  • BFF
  • ***
  • Posts: 482
    • View Profile
Virtual time in fluffos
« on: September 04, 2013, 02:28:54 AM »
Hey guys, I'm currently doing callout eventloop integration and here is a question:

FluffFOS since 2.0 has switched to a virtual timing system, virtual time plays catch up with real time,  (it executes multiple rounds together, if you've previously lost some time) that means when you add a call_out , you are actually delaying to a virtual time it will execute several time in a loop until it catches up,  So, visually it would be like this

...X....X....XX...X...X...X...XXX...XX....

It is actually pretty good,  smoothing inevitable delays into some small chunk that is easier to deal, while also prevent losing heartbeats. However, this means some call_outs() are actually executed early (they were targeted to a delay of virtual time, which will advance fast).

While working on integerating callout and heartbeat into eventloop i realized above and i am using a different model, in my model

call_outs corresponds to real time , when you say call_out(1), it will always be executed in no less than 1 seconds.  Heartbeat is still under virtual time,  so that we could have

1) try to keep up with real time by executing heartbeat faster

X...XX....X...XX....X...XX  (X means heart_beat execution)

2)  or simply drop heart_beat when things delay too much

X....X....X.............X (some thing happened cause delay and driver only execute one round of heartbeat and reset heartbeat).

So it boils down whether we would accept losing heart_beats() in time of lag.  by time T we should have executed T/interval s of heart_beats but due to execution time loss we only executed X , should driver catch up ? or should river silent ignore? Which one do you prefer?

Offline quixadhal

  • BFF
  • ***
  • Posts: 629
    • View Profile
    • WileyMUD
Re: Virtual time in fluffos
« Reply #1 on: September 04, 2013, 09:51:37 AM »
From a gaming perspective, skipping heartbeats is probably going to a friendlier choice on what players expect from the system.

Consider... if (somehow!) your MUD is lagging due to resource starvation, players will already be noticing that it feels choppy and sluggish.  If your combat is based on heart_beat(), having it skip rounds will just feel like the kind of lag you're already experiencing.  Having it cluster heart_beat() calls to try and "make up" for lag will be chaotic, and I suspect most players will find it frustrating because of the perceived lack of control.

In either case, somebody out there will say it breaks their system.. but I know I'd prefer it be broken on the side of giving the player more control over what's happening, rather than spamming them with combat events they can't react to.

The one thing I'd check (perhaps using Discworld's lib?) is how this will affect code that was written to detect failed/missing heart_beats.  I know in the OLD MudOS, it was pretty common to have your heart_beat get broken or lost, and there were even commands to let you "restart" your heart when this happened.  You'd need to make sure to describe how to correct this if such code thinks a couple of skipped heart_beats means you've "lost" it, so mudlib authors can correct their code for the newer versions of the driver.

Offline wodan

  • BFF
  • ***
  • Posts: 434
  • Drink and code, you know you want to!
    • View Profile
Re: Virtual time in fluffos
« Reply #2 on: September 05, 2013, 01:48:25 PM »
wouldn't be player friendly at all on dw (which is why I changed it to never miss anything)
hitpoints are added in hear_beat, but more interesting actions that hurt you are from call_out, so missing heart beats can be deadly

Offline wodan

  • BFF
  • ***
  • Posts: 434
  • Drink and code, you know you want to!
    • View Profile
Re: Virtual time in fluffos
« Reply #3 on: September 05, 2013, 01:52:28 PM »
also wouldn't like delaying call_out from the current time, as that would upset the call_out loops that keep things going nice and regular, lag effects would just keep building up (also, unlike the heart_beat thing, call_out has always been on virtual time on mudOS as well)

Offline FallenTree

  • BFF
  • ***
  • Posts: 482
    • View Profile
Re: Virtual time in fluffos
« Reply #4 on: September 05, 2013, 02:09:16 PM »
Wodan:  so you prefer not losing heat-beat,  and ignore the cost of call_out being potentially very inaccurate ?  (This inaccuracy will be worse if your lib lags more).

Another change could be change the meaning of call_out to be the round of heart_beats (which is 1s in most case afaiu),  this way you would be sure that call_out doesn't come earlier than expected.  How does that sound?

Offline quixadhal

  • BFF
  • ***
  • Posts: 629
    • View Profile
    • WileyMUD
Re: Virtual time in fluffos
« Reply #5 on: September 05, 2013, 06:47:19 PM »
I would totally hate linking call_out() and heart_beat().

I've been pushing for sub-second call_out()'s for years now, specifically because I don't WANT everything in the entire game to click along in perfect lock step.  My own idea for a combat system would have weapon swing timing based on the speed of the weapon itself, which pretty much requires staggared actions, and forcing them to lock into a 1 or 2 second click defeats the entire system.

Offline FallenTree

  • BFF
  • ***
  • Posts: 482
    • View Profile
Re: Virtual time in fluffos
« Reply #6 on: September 05, 2013, 10:49:36 PM »
well hold on:  I think we are arguing in wrong direction.  I think I now thinks heart_beat() just a persist version of call_out()  (which i assume would be reasonable) . That actually means there should be no special treatment on which to lose and which to not lose, they should both happen in natural order and neither should be skipped. 

Also, there is not much point of keeping a virtual game time, I am not sure why this concept was invent in the first place now.

Offline quixadhal

  • BFF
  • ***
  • Posts: 629
    • View Profile
    • WileyMUD
Re: Virtual time in fluffos
« Reply #7 on: September 06, 2013, 10:12:15 AM »
FWIW, the DGD driver doesn't have heart_beat() at all.  Dworkin decided it was a better application of his time to optimize call_out() well enough that you can just simulate heart_beat() in LPC if you really want it.  AFAIK, heart_beat() is a legacy thing from back when LPMUD 2.4.5 ran on a 386/33 with 4M of RAM, and it was too expensive to have hundreds or thousands of pending call_out()'s queued up.

Now, heart_beat() will still be more efficient because it loops across all the LPC objects in one loop at the driver level, and thus avoids extra context switches for the LPC state machine... the question is, does it matter anymore?

It would be a great experiment if somebody could simulate the load a successful mud like Discworld has with heart_beat() disabled in the driver and replaced by an LPC daemon that does the same thing.  I'm curious how much of an impact it would really have.

Offline FallenTree

  • BFF
  • ***
  • Posts: 482
    • View Profile
Re: Virtual time in fluffos
« Reply #8 on: September 06, 2013, 12:27:03 PM »
Another consider factor is that heart_beat() is called in a tight loop with no chance of other command execution in between.  It is probably worth it to keep it that way?

Offline wodan

  • BFF
  • ***
  • Posts: 434
  • Drink and code, you know you want to!
    • View Profile
Re: Virtual time in fluffos
« Reply #9 on: September 06, 2013, 02:53:26 PM »
MudOS did have call_out based on the heart_beat interval, which was really annoying (as dw has a 2 second heart_beat).
Virtual time makes sense when you do get lag as you can still do everything as you catch up with real time, but it's also a big gain when you're not lagged as getting time() just gets a global variable instead of having to do a system call. It also makes it easier to do a nice constant rate call_out loop, if you're late once, you'll be back in the correct time next time round, where if it was based on real time it would just get delayed further all the time, and you'd actually have extra lag from all the calls to get the current time.
And unless your mud is really laggy (and then you have bigger problems to look at) players won't be able to tell if the slightly shorter time between calls was catching up with netlag or actually a problem on the mud

and yes, discworl relies on everything actually happening, even if it's late, it's done miracles in cutting down player complaints about death through lag. (of course these days lag is rare anyway, but when it happens it's good to know that all code assumptions will still hold!).

Offline FallenTree

  • BFF
  • ***
  • Posts: 482
    • View Profile
Re: Virtual time in fluffos
« Reply #10 on: September 06, 2013, 03:15:49 PM »
It also makes it easier to do a nice constant rate call_out loop, if you're late once, you'll be back in the correct time next time round, where if it was based on real time it would just get delayed further all the time, and you'd actually have extra lag from all the calls to get the current time.

But, in fluffos 2.0, the catch-up rate is not constant, This is partly due to get_current_time() being at "second" level ,  so it is either you catch 1 seconds, or 2 seconds together,  during the catch up, callout and heart_beat() will get run together and no user command is accepted.

I agree that syscall() might be a issue,but that is probably the least of worries , the big problem is , when your code does call_out(1),  it is natural to think this call will be executed at least 1 second later.  But in current model your call_out(1) call_out(2) call_out(3)  will probably be executed together in one batch, due to the catch up effort.  That is the most annoying part.

There is another model where we can preserve call_out() spacing by retroactively fixing delays that caused by previous actions. So that   your call_out(1) and call_out(2) will be sure have at least a second a part.  The virtual world timeline may shift behind in a accumaltive way, (which is not big deal, virtual time has 0 meaning in physical world)  but the relative spacing between each callout and heartbeat will be preserved , which is the most important I think.

Offline wodan

  • BFF
  • ***
  • Posts: 434
  • Drink and code, you know you want to!
    • View Profile
Re: Virtual time in fluffos
« Reply #11 on: September 06, 2013, 04:11:09 PM »
if they stay in line with heart_beat that would certainly help, but it wouldn't be much good for things like our cron handler, things that need to happen at specific times are rather special though, so it wouldn't be too much effort to change the code for those, perhaps we can add a call_out_at() call or something to run at a specific time, that would be easier for the code as well (compared to having to calculate how many seconds away something is). If that would be available it may well be an improvement over the current way.

Offline FallenTree

  • BFF
  • ***
  • Posts: 482
    • View Profile
Re: Virtual time in fluffos
« Reply #12 on: September 06, 2013, 04:16:15 PM »
that is what I thought too, there need to be two flavor of  call_out() , one operate in real time and one operate in virtual time.

call_at(real_time) make sure it will be called mostly at specific time, and call_out(1) call_out(2) guarantee there is at least 1 second apart.

Cheers.

Offline quixadhal

  • BFF
  • ***
  • Posts: 629
    • View Profile
    • WileyMUD
Re: Virtual time in fluffos
« Reply #13 on: September 06, 2013, 07:28:11 PM »
So, what I'm hearing is this pretty much destroys the idea of sub-second call_out()'s ever happening.

If call_out()'s are going to be linked to heart_beat(), and heart_beat() happens every 1 or 2 seconds, the idea of a thief wielding two daggers (attack speed once per 0.75 and once per 0.9 seconds) is pointless, since they'll both fire every 1.0 seconds anyways (barring lag). :(

Offline FallenTree

  • BFF
  • ***
  • Posts: 482
    • View Profile
Re: Virtual time in fluffos
« Reply #14 on: September 06, 2013, 07:45:37 PM »
NO, you misunderstood. The precision of virtual time is inreleavent. If we make virtual time increment in 0.1s, then it is possible to have sub second callout and heartbeat

My system make sure things happens in order and spacing is preserved, doesn't garuntee the laggness, as, your 0.1 callout may actually execute at 1 sec later due to lag, but your 0.2 callout wkll sure happen no early than 0.1s later.