From: Bill Kelly <billk@...>
Date: 2005-04-17T02:35:27+09:00
Subject: Re: What's beyond Rails?

From: "Francis Hwang" <sera@fhwang.net>
> 
> On Apr 16, 2005, at 2:49 AM, jason_watkins@pobox.com wrote:
> > Still the wrong model. If you were providing Photoshop as a web
> > application, presumibly you'd be providing storage on the server
> > itself.
> >
> > So after your guassian blur filter runs, the app only need to send you
> > back a ~1000x1000 pixel image that reflects the portion of the image in
> > display.
> 
> Okay, but that portion itself represents a significant enough time lag 
> to cause a serious problem for the person who relies on Photoshop to 
> get work done. A 1000x1000 image, at 24-bit color, is about a 2.9 MB 
> image. My downstream is 5 Mbps which means that under peak conditions 
> it takes about 0.48 seconds to download the view. Not the entire image, 
> just the view itself.

That's 5 mega bits, not bytes right?  So more like 4.6 seconds,
at full speed?

With the right kind of compression, could send a lot less data.

[...]
> >>>> This is similar
> > to the problem faced by online FPS engines: Since you can't rely on
> > subsecond response times when you're playing CounterStrike over the
> > network, the server has to give the client more information than
> > strictly necessary and trust it to do what's right until the next time
> > contact is established.
> > <<<
> >
> > While that's true for modems, it's not necessarily true once you get to
> > broadband. This is a complex topic with a lot of details. I happen to
> > have a friend who works professionally in this area. I've played
> > versions of quake3 that remove all prediction and run at a locked 60hz
> > rate both for client side graphics and network state update. Latency
> > isn't necessarily the same as throughput, and human beings are
> > surprisingly tolerant of latency. You can hit up citeseer for the
> > relevant basic research done by the .gov in the initial military
> > simulation days: the net result is that humans can tolerate as much as
> > 150ms of local lag, and that at around 50ms of local lag human
> > observers begin to have trouble distinguishing between lagged and
> > unlagged input.
> >
> > 50ms round trip is possible on broadband these days, though not assured
> > coast to coast in the US or anything.

Regarding, "and human beings are surprisingly tolerant of latency",
it's hard to express how funny this is in the context of games like
quake.  On the one hand it's true the game is quite playable with
and order-of-magnitude difference in latency between players.  But,
oh, the griping, whining, and complaining that ensues!  :)

Here are the round-trip ping times for everyone connected to my
quake2 server at the moment (in milliseconds):

    29 Raditz          
    43 ompa            
    56 Ponzicar        
    58 SKULL CRUSHER   
    59 [EF] 1NUT       
    66 p33p33          
    67 HyDr0           
    70 HamBurGeR       
    74 iJaD            
    93 Lucky{MOD}      
   140 ToxicMonkey^MZC 
   145 Krazy           
   164 nastyman        
   171 Bellial         
   242 mcdougall_2     
   372 Demon

In a game like quake, you can feel the difference in latency
all the way down to LAN speeds.  A couple players, not playing
at the moment, live near the server and even have sub-20
millisecond pings!  Which is pretty close to LAN, but
experienced players still report having to adjust their play
style between 20 msec (lives near the server) and <10 msec 
(LAN play) latency.

> [...] how much data does a FPS 
> have to send out and receive, anyway? It's been my impression that a 
> FPS server sets a lot of the original model when the game sets up, and 
> then sends the clients a continuous stream of location and status 
> updates. I imagine the size of these updates is measurable in bytes or 
> kilobytes.

Quake2 data rate for broadband players is in the range of 
8 to 15 kbytes per second.


 ... In a desperate attempt to say something on-topic: 
I use ruby to write all my quake2 admin scripts.
I haven't tried Rails yet.  The other night I was able
to write a server-status CGI script from scratch in a
couple hours, including spawning multiple threads to
poll all servers concurrently.  (So amazingly easy in
ruby.)
http://tastyspleen.net/quake/servers/list.cgi

I considered trying Rails but had no need for a
database to be involved. . . . Someday I'll try Rails
 - maybe to keep track of all players high scores 
across all game levels.

OK not quite on-topic... I tried <grin>


Regards,

Bill