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

[Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>]

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 is the stream performance and so it doesn't mirror the time for
small chunks (<4kb) which freeciv will use. Lets look at the setup and
tear-down costs:
  $ ls -l ser
  -rwxr-xr-x    1 hawk     users         963 Aug  6 12:55 ser*
  $ /usr/bin/time gzip -1 ser
  0.00user 0.01system 0:00.00elapsed 200%CPU (0avgtext+0avgdata 0maxresident)k
  0inputs+0outputs (102major+57minor)pagefaults 0swaps

uhh it costs 0 time and this includes a process startup. Lets see what
the other time says:
  $ time gzip -1 ser
  
  real    0m0.007s
  user    0m0.010s
  sys     0m0.000s

less real than user. This normally indicates an SMP system. This isn't
one. Ok we can say that the setup and tear-down costs are <10ms.

Juan may instrument his code to provide better numbers. But IMHO the
raw numbers are good enough. More problematic is that because we don't
have a stream of packets anymore but a meta-packet which consits of
packets the client can't start its expensive graphical updates early
(after the first packet arrived).

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
    1) Customers cause problems.
    2) Marketing is trying to create more customers.
  Therefore:
    3) Marketing is evil.