On Thu, Dec 07, 2006 at 08:39:29PM +0000, Michael Rogers wrote: > toad wrote: > > If there is no RTT measurement, then how does it work? It only does the > > additive increase multiplicative decrease part, on the rate of sending > > requests? > > Right. The node keeps locally generated searches in a queue. There's no > limit on how quickly searches can be added to the queue, but there's an > enforced delay between releasing searches from the queue. The enforced > delay is 1/r, where r (the search rate) is additively increased whenever > a search succeeds and multiplicatively decreased whenever a search fails. > > When the throttle's disabled, locally generated searches are processed > immediately. > > > Can > > you compare this with the current algorithm, which includes the RTT? It > > may be that your simplified algorithm is better than the strict copy of > > TCP which is currently deployed (which measures the RTT). > > Will do. Could you give me a quick idea of what RTT means in this > context? Do you measure the time between generating the search and > receiving a reply, or between sending the search and receiving a reply? > Do searches that time out or otherwise fail count towards the RTT?
Time between sending the search and completing the request. Success, DNF, RNF, verify failure all count for requests. For inserts, we wait for the all transfers completed notification. > > Thanks, > Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20061208/0f3084c1/attachment.pgp>
