[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Help-gnunet] Bandwidth calibration
|
From: |
Christian Grothoff |
|
Subject: |
Re: [Help-gnunet] Bandwidth calibration |
|
Date: |
Wed, 22 Oct 2003 16:56:53 -0500 |
|
User-agent: |
KMail/1.4.3 |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wednesday 22 October 2003 04:23 pm, Alexander Blazej wrote:
> I used gtk-gnutella for about a year and am now switching to gnunet.
> Under gtk-gnutella my cable modem reliably uploads at 32 kB/s, and
> almost always maxs at 42 kB/s. Download limit is always 222 kB/s. I'm
> the only user utilizing my Internet connection. Aside from when I web
> surf and manually check my e-mail box, nothing uses my bandwidth (true
> 98% of the time).
>
> I'm trying to configure and tune my gnunet 0.60a bandwidth settings.
> My "messages expired (bandwidth stressed too long)" is always greater
> than my combined "times outgoing msg sent (bandwidth ok)" and "times
> outgoing msg deferred (bandwidth stressed)". I interpret this to mean
> that my servant is harming (sometimes greatly) the gnunet network by
> dropping most messages. I don't know how to fix this.
That's not really true. Say for example your peer receives one query and
decides that it may forward it to all 12 (20? 200?) peers that it is
currently connected to. So it queues the query 12 times. But each the
*other* peers have told your peer that their upstream is only X kbps. So in
fact regardless of how much bandwidth you have, you are also limited by how
much the other peers have (and, well, if you have lots more than the others,
you'll try to compensate by connecting to more peers). Anyway, if this
happens a lot, it is clear that some queries may be in the queue very, very
long (after all, X may be much smaller than the amount of things that you
could queue in this fashion for any given peer). Now, since you have bounded
memory and replies that arrive after a decade would not help anyway, your
peer drops messages that have been waiting in the queue for too long
("bandwidth stressed"). That's not an intrinsically bad thing though, since
the system is designed around the fact that message delivery is *unreliable*.
If none of the queries (or replies) makes it, the request is simple
retransmitted by the initiator after a (certain but random) time interval.
Which is in part why the system is so slow. But it is also why it is quite
difficult for an adversary to determine what a peer is really doing (since
peers have dozens of factors that decide if it will drop, delay, respond to
or indirect a request).
> Below are some
> test runs. Even when I set my upload max speed to 8 kB/s, 3 times as
> many messages are expired compared to the combined msg sent and msg
> deferred. I as of yet have inserted nothing into gnunet (I have not yet
> used gnunet-insert).
>
> Why is my servant dropping more messages than it's sending?
Because it is designed to quite agressively produce (queue) messages to make
sure that the bandwidth is always used (not wasted), knowing that the least
important (!) messages will be dropped by the bandwidth allocation code
anyway.
> Is this a problem?
No.
> How do I fix it?
No need to.
> Must MAXNETDOWNBPSTOTAL <= MAXNETUPBPSTOTAL to not harm gnunet?
No.
> When I set MAXNETUPBPSTOTAL to 32000 why does gnunet constantly send
> between 52 and 73 kB/s?
Hmm. That's strange. In my tests, the bandwidth limitations are followed
quite closely (as in: in 15s intervals it hardly ever goes above 10% of the
maximum). What does "gnunet-stats | grep load" say? The load percentages
should be around 100% most of the time (they are relative to the limit
specified). Note that bytes-received can go above 100% a bit easier since
it is more difficult to precisely control how much other peers send you
(longer latency between changes -- and it requires that they cooperate on
this). Oh, and CPU load is likely to go above 100% with lots of bandwidth in
0.6.0a, this has been resolved in CVS.
> Considering my internet connection is ISP limited to 32 - 42 kB/s, why
> doesn't gnunet or the TCP/IP layer throttle to the actual throughput?
Hmm. If your ISP would limit you to 32-42 kbps, how could GNUnet use 52-73
kbps? Either your bandwidth numbers are wrong or your ISP is not really
limiting you to that. And on the technical side, I don't think it is
possible to use the TCP/IP layer in any meaningful way to throttle bandwidth
use in our setting. What GNUnet does is that it counts the number of bytes
it is sending, computes a rate, and drops messages whenever it would go above
the user-defined limits. I'm running peers at 2000/2500/4000 and 50000 bps
and they all stick quite nicely to their limit (at least according to
gnunet-stats, I did not look at the traffic on the wire since it would
require work to sort out GNUnet-traffic and other traffic :-) ).
Let's look at your stats:
# Uptime (seconds) :
10077
# bytes received via udp :
91032508
# bytes sent via udp :
46735572
# bytes received via tcp :
184188852
# bytes sent via tcp :
12402572
So total: 91032508+184188852 received in 10077 => 27311 byte / second
Limit specified: 222000 bps, so it used less than 15% *on average*, but again,
your download limit is very high compared to your upload limit, so you can
expect that it is difficult to convince other peers to send you that much
traffic if you can send that little (it is possible, but with a short up-time
like that, not very likely):
MAXNETUPBPSTOTAL = 8000
MAXNETDOWNBPSTOTAL = 222000
And for the up-stream, we have: 46735572+12402572 => 5868 byte / second
Which is well within the 8000 bps specified in the configuration.
As for the peeks that you mention below, try CVS (more stats) and run it with
the "contrib/visualizeStats.sh" script. That will result in graphs that show
*what* type of traffic is being send at what time (visualize runs
gnunet-stats repeatedly and produces graphs with gnuplot). I have not seen
any odd behavior in traffic as you describe it (minus bugs that are fixed),
but this traffic visualization would help to track them down if there is
(still) a problem.
I hope this rather long explanation helps...
Christian
>
>
> GNUnet v0.6.0a, gnunet-stats v2.0.1
>
> BASICLIMITING = NO
> MAXNETUPBPSTOTAL = 32000
> MAXNETDOWNBPSTOTAL = 222000
> # typical upload 52 - 70 kB/s
> # typical download 45 - 60 kB/s
How do you get these values?
> # 42573 secs (11.8 hours) later
> # up 7 - 10 kB/s
> # down 51 - 73 kB/s
> # Uptime (seconds) :
> 42573
> # % of allowed network load :
> 67
> # % of allowed cpu load :
> 54
> # # bytes of noise received :
> 229946664
> # # bytes received from clients :
> 14656
> # # times outgoing msg sent (bandwidth ok) :
> 42211
> # # times outgoing msg deferred (bandwidth stressed) :
> 703379
> # # times incoming msg accepted (cpu ok) :
> 1343256
> # # times incoming msg dropped (cpu overloaded) :
> 0
> # # messages expired (bandwidth stressed too long) :
> 1860604
>
> BASICLIMITING = YES
> MAXNETUPBPSTOTAL = 32000
> MAXNETDOWNBPSTOTAL = 220000
> # up 18 - 22 kB/s
> # down 48 - 65 kB/s
> # Uptime (seconds) :
> 755
> # % of allowed network load :
> 69
> # % of allowed cpu load :
> 96
> # # bytes of noise received :
> 2010092
> # # bytes received from clients :
> 3520
> # # times outgoing msg sent (bandwidth ok) :
> 6349
> # # times outgoing msg deferred (bandwidth stressed) :
> 31264
> # # times incoming msg accepted (cpu ok) :
> 10587
> # # times incoming msg dropped (cpu overloaded) :
> 0
> # # messages expired (bandwidth stressed too long) :
> 49772
>
>
>
> BASICLIMITING = NO
> MAXNETUPBPSTOTAL = 8000
> MAXNETDOWNBPSTOTAL = 222000
> # typical upload 2 - 42 kB/s Uplead will often be 2 - 8 kB/s, then peek
> around 30 - 42 kB/s for a few minutes.
> # typical download 42 - 52 kB/s
> # Uptime (seconds) :
> 10077
> # % of allowed network load :
> 415
> # % of allowed cpu load :
> 48
> # bytes of noise received :
> 68534868
> # bytes received from clients :
> 3744
> # times outgoing msg sent (bandwidth ok) :
> 6962
> # times outgoing msg deferred (bandwidth stressed) :
> 361660
> # times incoming msg accepted (cpu ok) :
> 179663
> # times incoming msg dropped (cpu overloaded) :
> 0
> # messages expired (bandwidth stressed too long) :
> 1085182
> # sessionkeys received :
> 254
> # valid sessionkeys received :
> 254
> # sessionkeys sent :
> 979
> # connections shutdown :
> 1112
> # messages in all queues :
> 1528
> # currently connected nodes :
> 24
> # bytes noise sent :
> 28496
> # encrypted bytes sent :
> 12775348
> # bytes decrypted :
> 211037748
> # ping messages sent :
> 37475
> # ping messages received :
> 34844
> # pong messages sent :
> 34844
> # pong messages received :
> 229
> # bytes received via udp :
> 91032508
> # bytes sent via udp :
> 46735572
> # bytes received via tcp :
> 184188852
> # bytes sent via tcp :
> 12402572
> # HELO messages received from http server :
> 0
> # HELO messages received overall :
> 82514
> # valid HELO messages received :
> 82513
> # HELO messages forwarded from other peers :
> 35611
> # HELO messages originated :
> 309
> # Bloomfilter (content_bloomfilter) hits :
> 0
> # Bloomfilter (content_bloomfilter) misses :
> 189602
> # Bloomfilter (content_bloomfilter) adds :
> 0
> # Bloomfilter (content_bloomfilter) dels :
> 0
> # Bloomfilter (keyword_bloomfilter) hits :
> 4505
> # Bloomfilter (keyword_bloomfilter) misses :
> 602538
> # Bloomfilter (keyword_bloomfilter) adds :
> 26476
> # Bloomfilter (keyword_bloomfilter) dels :
> 0
> # indexed files :
> 0
> # size of indexed files :
> 0
> # lookup (SBlock, search results) :
> 0
> # lookup (3HASH, search results) :
> 54
> # lookup (CHK, inserted or migrated content) :
> 4467
> # lookup (ONDEMAND, indexed content) :
> 0
> # lookup (super query) :
> 0
> # lookup (data not found) :
> 0
> # blocks AFS storage left (estimate) :
> 8171507
> # kb downloaded by clients :
> 125
> # routing entry replaced during delaytime :
> 0
> # routing entry replaced during lookup :
> 0
> # kb ok content in :
> 6990
> # kb dupe content in :
> 9442
> # kb orphan or pushed content in :
> 69883
> # routing table full :
> 700
> # routing table entry replaced :
> 21426
> # routing table entry already in place :
> 834006
> # p2p queries sent :
> 733079
> # p2p queries received :
> 488541
> # p2p CHK content received (kb) :
> 81760
> # p2p search results received (kb) :
> 68
> # client queries received :
> 116
> # client CHK content inserted (kb) :
> 0
> # client 3HASH search results inserted (kb) :
> 0
> # client file index requests received :
> 0
> # file index requests received :
> 0
> # super query index requests received :
> 0
> # client CHK content deleted (kb) :
> 0
> # client 3HASH search results deleted (kb) :
> 0
> # client file unindex requests received :
> 0
> # file unindex requests received :
> 0
> # super query unindex requests received :
> 0
> # client SBlock insert requests received :
> 0
> # client namespace queries received :
> 0
> # peer namespace queries received :
> 0
> # SBlocks received :
> 0
> # kb content pushed out as padding :
> 16
> # client trace requests received :
> 0
> # client trace replies sent :
> 0
> # p2p trace requests received :
> 0
> # p2p trace replies sent :
> 0
>
>
>
> BASICLIMITING = NO
> MAXNETUPBPSTOTAL = 42000
> MAXNETDOWNBPSTOTAL = 222000
>
>
> Uptime (seconds) :
> 713
> % of allowed network load :
> 53
> % of allowed cpu load :
> 100
> # bytes of noise received :
> 147120
> # bytes received from clients :
> 696
> # times outgoing msg sent (bandwidth ok) :
> 4501
> # times outgoing msg deferred (bandwidth stressed) :
> 18834
> # times incoming msg accepted (cpu ok) :
> 1202
> # times incoming msg dropped (cpu overloaded) :
> 0
> # messages expired (bandwidth stressed too long) :
> 61856
> # sessionkeys received :
> 43
> # valid sessionkeys received :
> 41
> # sessionkeys sent :
> 80
> # connections shutdown :
> 99
> # messages in all queues :
> 2183
> # currently connected nodes :
> 16
> # bytes noise sent :
> 1287512
> # encrypted bytes sent :
> 6706384
> # bytes decrypted :
> 1669996
> # ping messages sent :
> 152
> # ping messages received :
> 28
> # pong messages sent :
> 28
> # pong messages received :
> 21
> # bytes received via udp :
> 1314440
> # bytes sent via udp :
> 968792
> # bytes received via tcp :
> 3970392
> # bytes sent via tcp :
> 5776540
> # HELO messages received from http server :
> 0
> # HELO messages received overall :
> 252
> # valid HELO messages received :
> 252
> # HELO messages forwarded from other peers :
> 1975
> # HELO messages originated :
> 31
> # Bloomfilter (content_bloomfilter) hits :
> 0
> # Bloomfilter (content_bloomfilter) misses :
> 2928
> # Bloomfilter (content_bloomfilter) adds :
> 0
> # Bloomfilter (content_bloomfilter) dels :
> 0
> # Bloomfilter (keyword_bloomfilter) hits :
> 118
> # Bloomfilter (keyword_bloomfilter) misses :
> 12922
> # Bloomfilter (keyword_bloomfilter) adds :
> 150
> # Bloomfilter (keyword_bloomfilter) dels :
> 0
> # indexed files :
> 0
> # size of indexed files :
> 0
> # lookup (SBlock, search results) :
> 0
> # lookup (3HASH, search results) :
> 0
> # lookup (CHK, inserted or migrated content) :
> 798
> # lookup (ONDEMAND, indexed content) :
> 0
> # lookup (super query) :
> 0
> # lookup (data not found) :
> 35
> # blocks AFS storage left (estimate) :
> 8387937
> # kb downloaded by clients :
> 0
> # routing entry replaced during delaytime :
> 0
> # routing entry replaced during lookup :
> 0
> # kb ok content in :
> 138
> # kb dupe content in :
> 147
> # kb orphan or pushed content in :
> 247
> # routing table full :
> 15
> # routing table entry replaced :
> 4270
> # routing table entry already in place :
> 10089
> # p2p queries sent :
> 15327
> # p2p queries received :
> 7764
> # p2p CHK content received (kb) :
> 448
> # p2p search results received (kb) :
> 1
> # client queries received :
> 15
> # client CHK content inserted (kb) :
> 0
> # client 3HASH search results inserted (kb) :
> 0
> # client file index requests received :
> 0
> # file index requests received :
> 0
> # super query index requests received :
> 0
> # client CHK content deleted (kb) :
> 0
> # client 3HASH search results deleted (kb) :
> 0
> # client file unindex requests received :
> 0
> # file unindex requests received :
> 0
> # super query unindex requests received :
> 0
> # client SBlock insert requests received :
> 0
> # client namespace queries received :
> 0
> # peer namespace queries received :
> 0
> # SBlocks received :
> 0
> # kb content pushed out as padding :
> 715
>
>
> _______________________________________________
> Help-gnunet mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/help-gnunet
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE/lv0l9tNtMeXQLkIRAk+2AJ9cc2iuJIoMNTSiB912kPA4wIUr3wCeP+mB
KhuS0WYa3kp5TCZnmpaiz78=
=XdCl
-----END PGP SIGNATURE-----