On Monday 24 June 2002 23:19, Matthew wrote: > > On Tue, Jun 25, 2002 at 04:16:49AM +0100, Matthew Toseland wrote: > > Patch committed, changes overload handling to: > > always accept if in failure table (as now) > > 60%-70% load: > > accept HTL=1, HTL=0 (this is after we have decremented it) > > accept if in most successful 1/256th of the keyspace (by % requests > > fulfilled successfully) See below
> > accept if in datastore > > 70-80% load: > > accept HTL=0 > > accept if in datastore > > 80%+ load: > > reject all except in fail table I'm glad to see someone actively working on fixing the overload problem. Unfortunately, I don't think this approach to selecting which requests to acccept is a good idea. Here are my concerns: 1) Your approach will penalize the nodes that route well (i.e. route to a node that has a high chance of having the data, without consuming much htl) at the expense of those that route poorly (i.e. nodes that route to many nodes unsuccessfully before landing at your node with a low htl). I don't see how this can be good for the global (network wide) routing effectiveness / specialization. It would be a disaster if everyone setup their nodes to route every request to every other node they could get a noderef for with an htl of 0 or 1. 2) Also, I don't think that its a good idea to try to pick a winning discrete segment of the keyspace and ignore all others. Real nodes don't have successful request key distributions with single peaks. What I proposed was that each request would be accepted or qr'd based on its approximate Ps(k) value. What I imagined is that the implementation would keep a Psmin minimum acceptable Ps(k) value which it increases under overload and decreases when not overloaded. All requests with Ps(k) > Psmin would be accepted. 3) I think you need to distinguish between successful DataRequests and InsertRequests. When the network is performance is bad there will be a disproportiate number of successful InsertRequests as compared to the number of successful DataRequests. InsertRequests just mean that data was inserted -- not that it was inserted where anyone else will ever find it. I think that it would better to do the inbound request triaging based on DataRequests only. Regards, --gj p.s. Don't take that proposal as gospel. I haven't heard any comment on it from Oskar yet. It has not yet sustained the withering critique typical of the devl mailing list ;-). > > Oh, and buildVersion++ to 469 (minimum build node will talk to remains > 465). > > > ---------- output from gpg ------------ > gpg: Warning: using insecure memory! > gpg: armor header: Version: GnuPG v1.0.7 (GNU/Linux) > gpg: Signature made Mon Jun 24 23:19:34 2002 EDT using DSA key ID 41FFFAA2 > gpg: Can't check signature: public key not found > ---------- end of gpg output ----------- ---------------------------------------- Content-Type: application/pgp-signature; charset="us-ascii"; name="Attachment: 1" Content-Transfer-Encoding: 7bit Content-Description: ---------------------------------------- -- Freesite (0.4) freenet:SSK@npfV5XQijFkF6sXZvuO0o~kG4wEPAgM/homepage// _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
