On Tue, 2003-08-05 at 12:14, Toad wrote: > > > > Another semi-related problem is that nodes sometimes get too much data > > in their sendqueues. I think I remember someone on this mailing list > > saying that their sendqueue got up to 80 MB. This is simply too large. > > Nobody has yet explained to me why a sendqueue of 80MB is a problem. > This is the total amount of data to send, including all the files in the > datastore. It is not expected to be sent immediately - we probably don't > HAVE all the 80MB.
A large sendqueue is bad if smaller files don't get priority. Web pages, frost messages, SpliteFile indexes, etc. should receive priority over 1 MB SplitFiles because big SplitFiles downloads don't really need low latency, and they have FEC. Also, a large sendqueue = longer time to transmit the data = higher latency. Although, NGR should see this higher latency and choose other routes. > > Back on topic, why do we default nodes with only 8 to 20 k/sec upload to > > 512 connections? 512 seems ridiculously large, even for nodes with 200+ > > k/sec max upload rates. I have a cable modem with about 12kb/sec upload, > > and my upstream is filled with a max of 30 connections. It does, > > however, take a little longer for the node to get up to full speed. I > > should probably try fewer connections and see how my node does. > > Because most of these connections will either be idle or be transferring > at a very low rate, since they are limited by the slowest node on the > chain. Remember that connections are asymmetric. with 15k/sec up, 3 dial up users can fill a cable modem user's send bandwidth. Or at least my send bandwidth is saturated with only 30 open connections. > And because it is REALLY expensive to open a new connection. IIRC, part of establishing a connection involved an algorithm that would generate a random key to be used to route to a new node. With NGR, will we really need this? Are there any other ways that the cost of establishing a connection can be reduced? _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
