[GNUnet-developers] core stats & cadet/DHT use

[Christian Grothoff]

Hi!

I just tried to analyze the network traffic profile of my peer
at the "core" level, to get a better idea of where we are
performance-wise.


Total observed:
===============
 # encrypted bytes given to transport:       1051171301
                    # bytes encrypted:       1000261123
         # bytes of payload decrypted:       1027526214
                    # bytes decrypted:       1066727660

So we are talking about ~1 GB in/out.

Main contributors:
==================
 # bytes of messages of type 138 received:        578621700 57%
file-sharing (result data)
 # bytes of messages of type 137 received:         12724384  1%
file-sharing (queries)

 # bytes of messages of type 146 received:        188849811 18% DHT PUT
 # bytes of messages of type 147 received:        135020348 13% DHT GET
 # bytes of messages of type 148 received:         36362860  4% DHT RESULT

 # bytes of messages of type 262 received:         33749044  3% CADET KX

        # bytes dropped (out of sequence):         21288419  2% lost
             # bytes dropped (duplicates):            37483

Note that this is a peer that was just started, with no local
user interaction.  I expect CADET traffic to increase once
more users start to actually use CADET-based applications.
3% of the DHT queries originated locally, from CADET.

I'm a bit surprised at the very good FS query/result ratio, but
that may be because the network is still small (NSE = ~25).

DHT GET vs. RESULT is a bit worrying, as it shows that most CADET
requests never get a reply, despite also rather high DHT PUT load.
Assuming the 97% of the DHT queries received from the network are also
from CADET (we need to start tracking DHT queries by type) -- which is
currently the only plausible explanation --, then something is clearly
wrong: in a network of this size, CADET should hardly need many DHT
queries in the first place, and those it does issue should be way more
successful.  That is, unless we have some peers trying to establish
connections to peers that don't exist.  In that case, CADET might
simply be too aggressive.

Bart, any idea?


Just for completeness, these were the other message types
I had at the CORE level:

Insignificant:
==============
HELLO:
  # bytes of messages of type 17 received:           171456
  (as expected)

Misc FS:
 # bytes of messages of type 139 received:            55856
  (as expected by design)

Misc CADET:
 # bytes of messages of type 256 received:          1446504 (connection
create)
 # bytes of messages of type 257 received:           126432
 # bytes of messages of type 258 received:           232200
 # bytes of messages of type 266 received:             1476
 # bytes of messages of type 268 received:            69480
 # bytes of messages of type 269 received:              560
 # bytes of messages of type 280 received:           179980 (payload!)
  (I suspect the 'payload' here is revocation / set)

NSE:
 # bytes of messages of type 322 received:            86856
  (as expected by design)


Happy hacking!

Christian