There are a few problems here:
1) Getting your instructions to the router and back takes time. This
the latency that Paul mentions. Based on the time it takes to get
through the wires and electronics of all the hops, it ought to be
less than half a second, and generally less. But there tends to be
"stuff" in the way:
a) One serious problem I've noticed is that service providers
tend to limit bandwidth (the amount of bits transmitted per unit
time). They throttle the bits -- still delivering them, but not
delivering more than the allotted amount per unit time. If you're
transmit, say, 10 big messages in rapid succession (i.e., back to
back), then the first message will take longer for the last packet to
be delivered, the next message longer still, and the last message
hopelessly late. Quite often, you'll feel like stuff isn't getting
through at all, so you end up sending even more messages (clicking
and waiving your mouse around and such).
We can address this in several ways. Croquet messages are two long
(they have too many bits that we don't need) and are too frequent
(they are sent more often than are needed). That's tuning. I know
that David and Andreas have made great improvements here, but that
code is still under development and not available yet. In addition,
the Collaborative code already does some ham-fisted improvements that
are in the KAT demo, but not any of the others. See http://
www.wetmachine.com/itf/item/685
b) Longer term, we might consider transmission protocols other
than TCP. I'm not rushing to that. We'll see.
2) In between sending to the router and getting the response back
from the router, there is, of course, the router and its box. The
Collaborative box is running the routers for 13 worlds, several VNC/
RFB servers, a Web server, and more. All through the same Network
Interface Card, and using one processor. I don't know if we're
getting delays from this or not. Anyone know how to tell?
3) Even when we get #1 and 2 as good as we can, I'm not certain that
it will be entirely satisfying to have to wait for a round trip from
your box to the router and back before you see any response in your
world. The previous (U.Wisconsin-only) version of Croquet, called
Dormouse, sacrificed some generality in order to let users see the
result of their own actions immediately, as a sort of speculative
evaluation. See
http://www.wetmachine.com/itf/item/429 (There's a
link in there to powerpoint with more info.) I think we might want to
do something like this.
On Apr 15, 2007, at 3:02 PM,
[hidden email] wrote:
> Hans N Beck:
>
> "BTW, for me there is often a great delay of pressing a button to the
> action, so
> moving exactly is sometimes very hard."
>
> Though I am not sure my language is correct or clear,
> I believe this might be said feedback is slow on shared events
> or is related with some other words I can't find
> to a concept called latency found in music over internet
> (but words somewhat "abused" by musicians pretending to be engineers
> and so with perhaps muddled consensus on what latency means).
>
> It is somewhat awkward to talk when none of us is a definitive
> source and we are talking across international boundaries,
> but sometimes merely expressing the awkwardness
> lubricates fertile conversations!
>
> A beautiful moment in a movie, "Ordinary People" had a young lady
> apologize for giggling and explain the feeling underneath it
> was embarrassment. This was a great "opening" of the heart.
>
Locked
Screenshot.png (175K)