[vworld-tech] Maximum Latency? + per-task accountability

[ceo]

replying from the archives...

----------------jim purbrick:
 > Bruce Mitchener
 >
 > I do think that this is a good reason for having as much per-task
 > accountability as possible.

This is interesting. Is a task your unit of work, which you can start, stop
and schedule? I'm currently thinking about adding support to measure
end-to-end latency in Warhammer, it will measure latency induced by each
processing step and the information will be transmitted with the messages so
will include latency induced by the client, network and servers. It's quite
a lot of work, but it seems that you're saying it's worth it.
 
I've got network I/O and as I say I'm looking at latency. Your system sounds
quite neat. Have you got any architectural documents on it?
----------------jim purbrick:

Ideally you want an architecture that is designed to do this, and then 
it becomes close ot trivial. Once class of architectures that do this is 
"staged", of which there are a few examples.

Look at SEDA for a start (google or there's a direct link from the page 
I quoted months ago).

We made the grexengine a staged architecture from day one partly for 
this accountability reason (along with ease-of-tweaking of sub-systems 
for performance/bottleneck resolution), although it's noticeably 
different from SEDA at a couple of key points. SEDA is much more "pure" 
(as befits a research system).

PS how come you're only looking at internal-RTT latency now? (nb: that's 
the term we use for "time from the moment the client request arrives at 
the cluster to the moment the response leaves the cluster") I thought 
you'd looked at this area a long time ago (IIRC from earlier MUD-DEV 
posts of yours)

Adam

(who is about to re-lurk; even only reading this list once a month it's 
not until 1:30 am at the office that I get a chance to do it :(  )