[Freeciv-Dev] Re: Network bandwidth data.

[Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>]

On Fri, Nov 08, 2002 at 11:52:57PM +0100, Raimar Falke wrote:
> On Fri, Nov 08, 2002 at 06:26:18PM +0100, Juan Uriarte wrote:
> > Hi,
> > 
> > the latest version of the patch is in freeciv/incoming/diff.compress12++.
> > It includes cycle counting for linux/i586 and hamming statistics
> > for the flags.
> > 
> >  Random results:
> > 
> > AI game,  1 controller, 4 obs, 60+ cities, start 1719, after a few turns:
> > 
> > Cycles per compression call:
> >  Total cycles compressing: 16654721537, avg per call: 34058, total calls: 
> > 489000
> > Started higher, converges around 35000
> > 
> > An update took ~4000+ packets/player @ 700Mhz == 0.2 seconds/player
> > (that update had a 25% compression ratio) (it was around 7kbyte compressed)
> > (cpu mobile p3)
> 
> While I think I have a better solution for the delta stuff I'm
> interrested in the performance of the zlib change. So I changed your
> patch a bit to print this information. It is possible that the patch
> also did this before but I didn't find it. It prints a lot of info. I
> also disabled your delta/caching.
> 
> A lot of the packets at turn end are merged and produce results like
> this:
> 
> 2: compressed 202 packets (16794 bytes into 1408 bytes: ratio = 8,383947%) in 
> 34,451000ms = 487 bytes/ms
> 2: compressed 185 packets (15577 bytes into 854 bytes: ratio = 5,482442%) in 
> 22,624000ms = 688 bytes/ms
> 2: compressed 185 packets (16121 bytes into 928 bytes: ratio = 5,756467%) in 
> 27,246000ms = 591 bytes/ms
> 
> The transfer of the ruleset is also merged:
> 
> 2: compressed 378 packets (49191 bytes into 18726 bytes: ratio = 38,067939%) 
> in 56,487000ms = 870 bytes/ms

One number was missing: the delay between the first packet put into
the compression queue and the last packet.

For turn done these numbers are:

2: compressed 202 packets (16794 bytes into 1408 bytes: ratio = 8,383947%) in 
35,853000ms = 468 bytes/ms; delay=1979,280000ms
2: compressed 185 packets (15577 bytes into 854 bytes: ratio = 5,482442%) in 
24,066000ms = 647 bytes/ms; delay=1977,065000ms
2: compressed 185 packets (16121 bytes into 928 bytes: ratio = 5,756467%) in 
19,422000ms = 830 bytes/ms; delay=1937,266000ms

How to read: there was a time difference of 1.979s from starting
compressing the first of the 202 packets and last packet leaving the
compression compressed. So the server needed (1979-35)=1944ms to
generate all the packets (and do the turn-done calculations). And
during this ~2s zlib needed 35ms to compress all the data. This is
1.8% of the total time!!

In the above example a modem would need about 16794/(56000/8)=2.4s in
the uncompressed case. These time however will be interleaved with the
calculation time of the server. So it won't add but the total time is
at least MAX(1.979s, 2.4s)=2.4s. With compression you get 1.944s +
1408/(56000/8) = 2.14s. Not much gain. If however the calculation time
for the server is reduced (just don't use my P2-400 but a faster CPU)
you get a case for the compressing. So if we assume that the server
can do its job in 1s we have 2.4s for the uncompressed case and 1.2s
for the compresses case. Factor 2.

Lets look at the ruleset transfer:

2: compressed 378 packets (49191 bytes into 18726 bytes: ratio = 38,067939%) in 
123,283000ms = 399 bytes/ms; delay=162,776000ms

Here the zlib needed 76% of the time. Uncompressed case: MAX(7s,
39ms)=7s. Compressed case: 2.6s + 162ms = 2.762s.

Another point is that the client can't start doing the updates during
these 2s but has to wait these 2s and then do all the stuff at
once. For stuff we already queue (chat window for example) this isn't
a problem. The other cases (city window, map canvas) should also be
changed to support FREEZE/THAW HINT.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "The very concept of PNP is a lovely dream that simply does not translate to
  reality. The confusion of manually doing stuff is nothing compared to the
  confusion of computers trying to do stuff and getting it wrong, which they
  gleefully do with great enthusiasm." 
    -- Jinx Tigr in the SDM