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

[Jason Dorje Short <vze49r5w@xxxxxxxxxxx>]

>
>    Raimar
>

Raimar Falke wrote:
> On Tue, Nov 05, 2002 at 05:38:38AM -0500, Jason Dorje Short wrote:
>
> > Juan Uriarte wrote:
> >
> > > Hello,
> > Hi!
> >
> >
> > > On Tue, 5 Nov 2002, Raimar Falke wrote:
> > > > I read your previous posts and thought "another one who implemented
> > > > zlib compression for the TCP stream and failed to provide numbers". So
> > >
> > > Numbers are provided after each read(2) chunk (running with -d 2) and
> > > on the server console when a player disconnects. Typical compression
> > > is less than 50% of the original size (between 30-40 in my experience),
> > > around 20% for dead players.
> > The question isn't whether zlib compresses the data - this much is 
> > obvious.  The question is whether it makes FreeCiv faster.
> > As always, it is a tradeoff that will have different benefits depending 
> > on the situation.  On a fast computer with a slow connection it is a 
> > good thing, whereas with a slow computer on a fast connection it is bad. 
> > The question is: *how* slow, and *how* fast?
> > If we make it an option, then we don't have to worry too much about the 
> > bad cases.  But there should still be numbers (or at least anecdotes) to 
> > show that the compression makes things better for *somebody*.  I'm not 
> > sure how you would get these numbers, but simply looking at packet size 
> > won't do it.
>
> So we need a uncompressed mbytes/s number. Let me start:
>
>   $ -rwxr-xr-x    1 hawk     users     6689723 Nov  5 12:06 a*
> This is the civclient binary. Text would be too easy.
>   $ /usr/bin/time gzip -1 a
>   3.41user 0.14system 0:03.75elapsed 94%CPU (0avgtext+0avgdata 0maxresident)k
>   0inputs+0outputs (103major+106minor)pagefaults 0swaps
>   $ ls -l a.gz
>   -rwxr-xr-x    1 hawk     users     3037763 Nov  5 12:06 a.gz*
>   $ /usr/bin/time gunzip a
>   0.85user 0.17system 0:01.03elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k
>   0inputs+0outputs (108major+38minor)pagefaults 0swaps
>
> So we get (for this kind of input) 50% reduction. This is a P2-400:
>   Compression speed: 6689723/3.41 = 1961 kb/s
>   Decompression speed: 6689723/0.85 = 7870 kb/s
>
> 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).
jason