[Freeciv-Dev] Re: Network bandwidth, and other things.

[Thomas Strub <ue80@xxxxxxxxxxxxxxxxxxx>]

On Tue, Nov 05, 2002 at 03:54:49PM -0500, Jason Dorje Short wrote:
> >These number are IMHO high enough. The GTK client for example will
> >happily spend 100ms in some graphical update. In this time we can
> >compress 196kb. This is the game data for a lot of turns.
> 
> This really doesn't answer the question.  The question is: does it make 
> FreeCiv faster?
> 
> Looking only at compression time versus compression results can not 
> answer this.
> 
> * As Vasco points out, the bottleneck points of the network may already 
> do compression - in this case compressing the data may make the packets 
> bigger, and will certainly increase latency.
> 
> * As Christian points out, in most cases it is latency that makes 
> freeciv slow, not lack of throughput.  Does compression decrease 
> latency, or increase it?
> 
> * Just because the GUI is a bottleneck for CPU time doesn't mean using 
> more CPU power on the client end is fine.  In fact, it would mean the 
> opposite.  (I don't think this should be an issue, since most of the 
> client's time is not spent in GUI code, but it needs to be answered.)
> 
> * If the server has to compress packets, then it has to compress 
> everybody's packet.  10 ms/packet may not be much, but in a large game 
> this means 10ms slowdown for everyone when the server sends a packet to 
> anyone.  Those 10ms can quickly add up.
> 
> Note that at least the last one applies to the delta-packets concept as 
> well.
> 
> I still have no answer for how you would go about showing that freeciv 
> was "faster" or "more responsive" under one of these patches.  But as I 
> said, an anecdote would be a good start.  Unfortunately one needs the 
> right network to get such an anecdote (or real numbers, for that 
> matter), so not anyone can do it (unless they are clever and simulate a 
> slow network).

Perhaps someone should try my pingpatch ... but changes like that are
only visible with an offset < 1 min ...

Thomas
-- 
Thomas Strub  ***  eMail ue80@xxxxxxxxxxxxxxxxxxx
Nur weil das Aufzeichnen, Kopieren und Schnüffeln bei elektronischem 
Datenverkehr leichter als bei der klassischen Post ist, darf man es nicht
einfach tun.