On Wed, Dec 06, 2006 at 09:44:25AM +0000, Michael Rogers wrote: > toad wrote: > >I don't understand why slow nodes don't pull down the throttle. Is the > >throttle using the same parameters as on the network proper? > > No, the simulated throttle is much simpler - no RTT measurement, one > throttle for all inserts and requests rather than 4 separate throttles. > To be honest I'm not sure RTT measurement makes much sense when each > search follows a different path, but I'm willing to emulate the current > behaviour more closely if it would be useful.
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? Or decrease/increase with the interval between requests? 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). > > >The thing is, it seems to me that this is exactly what is happening on > >the main network - average bandwidth usage is very low, precisely > >because the throttles aren't starting many requests. > > I don't think the simulations show low bandwidth usage, but I'll check. The real network does. What we want to discover is why... > > >Do the simulations approximate the current shouldRejectRequest() > >behaviour reasonably well? In particular do they emulate the predictive > >bandwidth allocation code? > > Bandwidth prediction and ping time aren't simulated, I'm afraid - > shouldRejectRequest() is just based on a running average of the > bandwidth/congestion delay (ie how long messages are delayed beyond > their coalescing deadlines). > > I'm happy to make the simulations more realistic, but there's a tradeoff > between testing new features (eg token passing) and simulating existing > features accurately - I'm happy to do either, so let me know which would > be more useful. Please simulate the current algorithm with RTT measurement. This was put in to closely match TCP. If it doesn't work very well we can replace it. -------------- 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/20061207/a5347b28/attachment.pgp>
