On Thu, Oct 30, 2003 at 11:26:51PM -0800, Mike Stump wrote: > 6286 is bad. I mean, there are parts that that are really good, like > people back off when I QR and the messageSendTime is really, really > low. The problem is, one person makes a request, I start moving data, > and then I QR everything coming in, then, no one talks to me anymore. > Since I have only one sending, it finishs quickly, then I sit, doing > nothing. Sure, I no longer QR, but because I did in the very recent > past, no one talks to me. It then takes a long while to get any more > Qs to get another one to move data, but then I QR everyone, and then > they stop asking... Instead of averaging 51k QPH, 7K Success QPH, I > do 55 QPH, 55 Success QPH. Notice, looks almost the same, but there > is no k in there. So, this is progress, in some way, but we need just > a tad less progress for it to work well. I think everything is being > served up by stable (or 6284 or before) currently. > > I tried finding the change that did this, none of them looks like they > would do it. Anyway, we need to not QR anything, unless we have more > than at least 5 connections transmitting (or the upstream is saturated > _and_ it is saturated by Qs). The reason is that some can stall, some > can finish quickly, and so on. To maintain a constantly in use > upstream we need at least a few, 5 would be good. I used to die doing > 220+ transmitting, this was killing me. Now I do 0, we've come back > to far. Time to move back into the middle a little. If you don't > like magic like 5, try, as long as messageSendTime is <600ms, allow > more in, as it increases beyond, limit things down. If you don't like > that, maybe limit the messageSendQueueSize to be 8-10, 47 is too much, > 0.002 is too small.
Interesting. This suggests that transfers are moving really fast by Freenet standards... Anyway the fix is not as you suggest; the fix is to make the QR estimators slightly less sensitive. Any suggestions? The simplest way would be to just use a lower decay coefficient (perhaps that starts high when a node is new in the routing table, but then goes down to some value over a short period), but maybe there is a more suitable algorithm. We get reports of 1.0F or 0.0F, we implement the freenet.node.rt.RunningAverage API... > > And, one last thing, the transfer rate did not shoot up when my node > was unloaded. I did expect that because I only had 1 transmitting, > and no Q load, that the rate would be fairly high, but no, 47.6 on the > per minute page. I limit at 8K/second. We need to allow connections > to open up. -- Matthew J Toseland - [EMAIL PROTECTED] Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so.
signature.asc
Description: Digital signature
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
