Hi all,
First of all thanks for the wonderful lightweight configurable free
software. :-)
I've just started running a GTKG ultrapeer after a long time as a leaf
(my new machine finally has enough physical memory) and I'm seeing some
behaviour that I think might be a bug. Briefly, when the upstream
bandwidth is throttled and there are uploads in progress, the message
queues of neighbouring ultrapeers can start to fill up. This causes the
ultrapeers to be marked as inactive and dropped, and GTKG starts looking
for new ultrapeers. A large number of connections are opened, which
causes further congestion, so once again the new connections are marked
as inactive and dropped. This 'storm' of new connections can continue
indefinitely. It seems to be possible to stabilise things by reducing
the number of neighbours and the number of connections used to find new
neighbours, at which point the gnet bandwidth drops, the message queues
start to empty, and GTKG stops dropping connections.
It seems like this problem might be caused by TCP's slow start
mechanism: long-running TCP connections are much more robust to packet
loss and RTT variance than new connections, so the newly established
ultrapeer connections can't compete for bandwidth with existing HTTP
connections, and the low throughput causes the message queues to fill up
even if the remote peers are perfectly responsive.
Another factor might be vendor selection: my peer quickly reaches a
state where 60% of its neighbours are either LimeWire or BearShare, at
which point around half of the new connections it makes will be dropped
straight away because of the vendor. Although I like this feature, it
must be causing quite a lot of load on the network.
Here's how my bandwidth is configured:
Use surplus bandwidth = yes
Prefer compressed connections = yes
Use IP Type of Service = no
General incoming traffic = 5 KiB/s
General outgoing traffic = 5 KiB/s
Ultrapeer mode incoming traffic from leaves = 5 KiB/s
Ultrapeer mode outgoing traffic to leaves = 5 KiB/s
HTTP cumulative download rate = 245 KiB/s
HTTP cumulative upload rate = 20 KiB/s
Enable dynamic upload slots allocation = yes, 70%
Compute upload connection speed = yes
Here's what it displays for available bandwidth:
Total input bandwidth limit = 250 KiB/s
Total output bandwidth limit = 25 KiB/s
Measured HTTP latency = 0.000 s
(By the way it's always puzzled me why the total limit doesn't seem to
include the ultrapeer mode leaf traffic. Another thing that puzzles me:
when I specify "Try to keep at least 20 and allow at most 35 total
connections up", I can see 66 active ultrapeer connections (28 black,
which I assume means outgoing, and 38 grey). Do the figures only relate
to outgoing connections, and if so, is there any way to limit the number
of incoming connections?)
With my current settings (at least 20 and at most 35 connections, use 4
connections to connect more quickly), gnet traffic is at about 2 KiB/s
in and 1 KiB/s out, and leaf traffic is at about 0.2 KiB/s in and 1
KiB/s out. HTTP is using the rest. The message queues are pretty much
empty. If I increase the settings to at least 32, at most 40 connections
then sooner or later it gets into another storm
I'm running the GTK2 Debian package of version 0.96 from the website, on
Debian testing (Linux 2.6.14), with a cable connection (nominally 4 Mb/s
down and 384 Kb/s up).
Hope this is enough information. ;-)
Cheers,
Michael
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Gtk-gnutella-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
