Realtime and punched cards

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Realtime and punched cards

Argent Stonecutter
> But that script knows that SL is a realtime environment in the same
> sense a potato knows it is in a field: "What is a field? I wonder...
> what is out there? I cannot see... but they call it a field... so it
> must be a field... I wonder if there are others like me out there?"

What realtime means is that time is relevant to the value of a  
computation. A result calculated too late is a wrong result.

> Bring back punch cards!!! Little prim punch cards for everyone!

Let me know your SL name and I'll send you one. And a PDP-11  
containing genuine PDP-11 boot code.

> Ok, I'll certainly grant that. But isn't the same true for any game
> (without going into the question of whether or not SL is itself a
> game), and would that classify it as a hard-realtime constrained
> environment?

Any user interface is a soft real-time environment. If the user  
interface includes a physics simulation, then it's a hard real-time  
environment within the context of that simulation.

> In my understanding of it, hard-realtime issues concern things like, I
> absolutely need my interrupt handler to be fired within X nanoseconds,
> lest I miss the next data bit on my serial receive pin.

Indeed, and that kind of situation exists in SL. I have code in Mehve  
to detect when you've run into ban lines and brake before you're  
unseated and disconnected from the sim. If the timer does not fire in  
time, the code has failed. If there are dozens of scripts in the sim  
running under interpreters that do not provide fine-grained  
threading, it is far less likely that mine will actually fire, even  
if mine will run faster when it does fire under Mono.

> I certainly didn't mean to underestimate this problem. But regardless
> of what we would say qualifies as a hard-realtime problem, I think
> this problem would be no more difficult to solve with Lua (which was
> your original concern) as it is with Mono.

I entirely agree, this is a difficult problem to solve with Mono.  
Which is why I originally brought this up as a problem with Mono  
replacing LSL. :)

_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
Reply | Threaded
Open this post in threaded view
|

Re: Realtime and punched cards

Taran Rampersad
Argent Stonecutter wrote:
>> But that script knows that SL is a realtime environment in the same
>> sense a potato knows it is in a field: "What is a field? I wonder...
>> what is out there? I cannot see... but they call it a field... so it
>> must be a field... I wonder if there are others like me out there?"
>
> What realtime means is that time is relevant to the value of a
> computation. A result calculated too late is a wrong result.
I'll offer that realtime is time that is *relative* to the value of a
computation.
>> Bring back punch cards!!! Little prim punch cards for everyone!
>
> Let me know your SL name and I'll send you one. And a PDP-11
> containing genuine PDP-11 boot code.
Nobody Fugazi.
>> Ok, I'll certainly grant that. But isn't the same true for any game
>> (without going into the question of whether or not SL is itself a
>> game), and would that classify it as a hard-realtime constrained
>> environment?
>
> Any user interface is a soft real-time environment. If the user
> interface includes a physics simulation, then it's a hard real-time
> environment within the context of that simulation.
Which would mean that time dilation is still a hard real-time environment?

>> In my understanding of it, hard-realtime issues concern things like, I
>> absolutely need my interrupt handler to be fired within X nanoseconds,
>> lest I miss the next data bit on my serial receive pin.
>
> Indeed, and that kind of situation exists in SL. I have code in Mehve
> to detect when you've run into ban lines and brake before you're
> unseated and disconnected from the sim. If the timer does not fire in
> time, the code has failed. If there are dozens of scripts in the sim
> running under interpreters that do not provide fine-grained threading,
> it is far less likely that mine will actually fire, even if mine will
> run faster when it does fire under Mono.
If your scripts run faster under Mono, so does everyone else's. Exactly.
So the script can be real time, but the point is that the framework is
not - and that realtime in what you have described is only relative to
the value of the computation when considered in the field of potatoes.
That is such a horrible metaphor. I will have to come up with something
better.
>> I certainly didn't mean to underestimate this problem. But regardless
>> of what we would say qualifies as a hard-realtime problem, I think
>> this problem would be no more difficult to solve with Lua (which was
>> your original concern) as it is with Mono.
>
> I entirely agree, this is a difficult problem to solve with Mono.
> Which is why I originally brought this up as a problem with Mono
> replacing LSL. :)
Yup. We can have more problems per second. I hope they're switching JIRA
to Mono as well to handle this.

--
--
Taran Rampersad
[hidden email]

http://www.knowprose.com
http://www.your2ndplace.com
http://www.opendepth.com
http://www.flickr.com/photos/knowprose/

"Criticize by Creating" - Michelangelo
"The present is theirs; the future, for which I really worked, is mine." - Nikola Tesla

_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
Reply | Threaded
Open this post in threaded view
|

Re: Realtime and punched cards

Mark Meijer-4
In reply to this post by Argent Stonecutter
On 22/01/2008, Argent Stonecutter <[hidden email]> wrote:
> > I certainly didn't mean to underestimate this problem. But regardless
> > of what we would say qualifies as a hard-realtime problem, I think
> > this problem would be no more difficult to solve with Lua (which was
> > your original concern) as it is with Mono.
>
> I entirely agree, this is a difficult problem to solve with Mono.
> Which is why I originally brought this up as a problem with Mono
> replacing LSL. :)

Ah :-)
_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
Reply | Threaded
Open this post in threaded view
|

Re: Realtime and punched cards

Mark Meijer-4
In reply to this post by Argent Stonecutter
On 22/01/2008, Argent Stonecutter <[hidden email]> wrote:

> > In my understanding of it, hard-realtime issues concern things like, I
> > absolutely need my interrupt handler to be fired within X nanoseconds,
> > lest I miss the next data bit on my serial receive pin.
>
> Indeed, and that kind of situation exists in SL. I have code in Mehve
> to detect when you've run into ban lines and brake before you're
> unseated and disconnected from the sim. If the timer does not fire in
> time, the code has failed. If there are dozens of scripts in the sim
> running under interpreters that do not provide fine-grained
> threading, it is far less likely that mine will actually fire, even
> if mine will run faster when it does fire under Mono.

Right, I see what you mean. Yeah, that is a hard-realtime problem, and
in that sense I agree that there exist plenty of applications in SL
that are subject to hard-realtime constraints in one way or another.
But I'd say that an SL sim is itself not strictly subject to those
constraints, nor could it possibly be made to guarantee hard-realtime
operation. This raises the obvious question of whether SL is a
suitable platform for hard-realtime constrained solutions. The answer
would have to be, strictly, no.

The problem here I think is one closely related to hard-realtime
issues, and that is deterministic code execution time. OS-induced
causes aside, this problem is probably mostly due to script
throttling, which you also mentioned as being necessary. There's no
way around it. To be hard-realtime constrained means you are
guaranteed a certain minimum timeframe, within which you are
guaranteed to be able to do so much, but no more. I think there is no
way SL could possibly be made to provide any useful, hard guarantees
of that nature for any individual script.
_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
Reply | Threaded
Open this post in threaded view
|

Re: Realtime and punched cards

Mark Meijer-4
In reply to this post by Taran Rampersad
On 22/01/2008, Taran Rampersad <[hidden email]> wrote:
> Yup. We can have more problems per second. I hope they're switching JIRA
> to Mono as well to handle this.

rofl :-D
_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
Reply | Threaded
Open this post in threaded view
|

Re: Realtime and punched cards

Argent Stonecutter
In reply to this post by Argent Stonecutter
Taran Rampersad writes:
> If your scripts run faster under Mono, so does everyone else's.  
> Exactly.

Faster is not the point of a real time system. Predictable is the  
point. A system that is 50 times slower but can be guaranteed to  
complete script processing every frame is a real time system. A  
system that's 50 times faster but script processing can't be  
terminated before the physics frame deadline it's not realtime.

The script is in a realtime environment.

SL itself is a realtime environment.

If they go to mono and people take advantage of it and write scripts  
that do 50 times as much, which you know they will, we're going to be  
back will the same kind of script lag we had last year before they  
got the script throttling right, because Mono is running as native  
code, there's no interpreter, and nothing to stop a script running  
long except the *hardware* threading. And hardware threads are not  
fine-grained enough.


Mark Meijer:
> But I'd say that an SL sim is itself not strictly subject to those
> constraints, nor could it possibly be made to guarantee hard-realtime
> operation.

NO system can do that without qualification. A hard realtime system  
is only realtime subject to constraints. And even on a hard realtime  
OS you have to write your software to satisfy hard realtime  
constraints as well.

In SL, those are "so long as the total script time and physics time  
and so on are low enough that there's time left in each physics frame".

Once script time gets high, it stops providing real-time guarantees  
to scripts to ensure that physics is still meeting hard realtime  
deadlines. Just like, in an RTOS, if you try and run too many tasks  
you'll end up with some of them NOT making hard realtime deadlines  
any more. That 1/35th of a second physics frame is a hard realtime  
deadline for scripts.

Once total time gets high enough it stops providing real-time  
guarantees for physics, and you get time dilation. Physics fails.  
Objects start going offworld because forces are not being calculated  
right, and so on.

Any runtime not designed for this environment will make it harder to  
avoid the latter situation.

_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
Reply | Threaded
Open this post in threaded view
|

Re: Realtime and punched cards

Taran Rampersad
Argent Stonecutter wrote:

> Taran Rampersad writes:
>> If your scripts run faster under Mono, so does everyone else's. Exactly.
>
> Faster is not the point of a real time system. Predictable is the
> point. A system that is 50 times slower but can be guaranteed to
> complete script processing every frame is a real time system. A system
> that's 50 times faster but script processing can't be terminated
> before the physics frame deadline it's not realtime.
>
> The script is in a realtime environment.
>
> SL itself is a realtime environment.
I actually disagree with you on this.

> Mark Meijer:
>> But I'd say that an SL sim is itself not strictly subject to those
>> constraints, nor could it possibly be made to guarantee hard-realtime
>> operation.
>
> NO system can do that without qualification. A hard realtime system is
> only realtime subject to constraints. And even on a hard realtime OS
> you have to write your software to satisfy hard realtime constraints
> as well.
>
> In SL, those are "so long as the total script time and physics time
> and so on are low enough that there's time left in each physics frame".
>
> Once script time gets high, it stops providing real-time guarantees to
> scripts to ensure that physics is still meeting hard realtime
> deadlines. Just like, in an RTOS, if you try and run too many tasks
> you'll end up with some of them NOT making hard realtime deadlines any
> more. That 1/35th of a second physics frame is a hard realtime
> deadline for scripts.
And this is where I say, "Verily, Second Life is not a real time
system". Having worked on Nav systems that are placed on things that
move really fast and sometimes go boom, realtime is realtime. You are
describing a Physics engine that is realtime, from what I can tell - but
the rest of the system is not.

And I think you might agree with that. We may be looking at the same
coin from different angles.
> Any runtime not designed for this environment will make it harder to
> avoid the latter situation.
And, conversely, an environment not designed for the runtimes... :-)

--
--
Taran Rampersad
[hidden email]

http://www.knowprose.com
http://www.your2ndplace.com
http://www.opendepth.com
http://www.flickr.com/photos/knowprose/

"Criticize by Creating" - Michelangelo
"The present is theirs; the future, for which I really worked, is mine." - Nikola Tesla

_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
Reply | Threaded
Open this post in threaded view
|

Re: Realtime and punched cards

Mark Meijer-4
In reply to this post by Argent Stonecutter
On 23/01/2008, Argent Stonecutter <[hidden email]> wrote:
> If they go to mono and people take advantage of it and write scripts
> that do 50 times as much, which you know they will, we're going to be
> back will the same kind of script lag we had last year before they
> got the script throttling right, because Mono is running as native
> code, there's no interpreter, and nothing to stop a script running
> long except the *hardware* threading. And hardware threads are not
> fine-grained enough.

On this point I'd have to come back and say, this is not entirely
true. In fact, they're not using "hardware" threads or OS threads or
whatever to deal with concurrency. Well, at least not primarily. The
code may be running natively in Mono, but it is JIT compiled from
bytecode. And that bytecode gets heavily instrumented by SL sothat,
essentially, each script is forced to monitor and deal with their own
problems such as, am I allowed to run, am I about to get serialized,
or whatever. The instructions for that are injected into the bytecode
of each script. The result of that instrumentation is what's being JIT
compiled into native code.

It basically sounds, to me, like a form of cooperative multithreading,
except the "cooperative" part of that is forced by the platform (SL),
rather than relying on scriptwriters to add a yield every now and
then. And at the cost of increased overhead, they could probably make
that as fine-grained as they want. Whether it's pretty is a different
question :-P


> In SL, those are "so long as the total script time and physics time
> and so on are low enough that there's time left in each physics frame".
>
> Once script time gets high, it stops providing real-time guarantees

I'm thinking we may be talking about slightly different things. Yes, a
sim should ideally meet that 1/35th timeframe for a simulation step,
and if it doesn't, then one could say it has failed, and all kinds of
things start to happen. To help prevent such conditions, a scripting
framework that can handle a huge level of concurrency under those
constraints, will certainly be an asset, if not a necessity.

But from any script's point of view, even a system that perfectly
meets the above requirements can not guarantee anything for that
script, in terms of amount of work done (by the script) or amount of
time allotted (to the execution of that script) during any single
frame. At least not until you get to pick exactly what scripts are
allowed to run on that sim, and how many. And this is exactly because,
in order to meet that deadline, script execution will *have* to be cut
off or throttled in some way.

Result, non-deterministic script execution time. In other words, no
framework or scripting engine for SL could possibly support
hard-realtime requirements for any script, unless you as the
scriptwriter have absolute control over what scripts get to run on
your sim (if you have one), and their implementation. I don't know if
that's a realistic requirement even for privately owned islands.
_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters