On Fri, Dec 08, 2006 at 12:35:02PM +0000, Michael Rogers wrote: > toad wrote: > > Well there are two issues here: > > 1. Simulations don't seem to show a consistent lead for backoff plus > > throttling over just throttling. At least, recent ones - do yours? If > > this is true, then why? > > Recent simulations show that backoff plus throttling and throttling > alone are pretty evenly matched.
Even with slow nodes? > I would guess this is because > throttling keeps load at a low enough level that backoff rarely occurs. Perhaps. If this is true, then throttling with some slow nodes would keep load far below the network capacity. Backoff is supposed to prevent this, but it doesn't work for some reason. > That would also explain why backoff alone slightly outperforms the other > two mechanisms when there are slow nodes - backoff is a local reaction > to overload whereas throttling is a global reaction, so backoff > misroutes around the slow nodes, whereas throttling slows down the whole > network. Neither is optimal! > > > 2. Why is the real network so slow? It uses far less bandwidth than the > > specified limit; this suggests that the throttling has gone mad, or > > something (pre-emptive rejection) has broken it. Can we reproduce this > > in the simulation, and show why it happens / that it doesn't happen if > > we slightly change things? > > I hope so, but there are a lot of places a bug could be hiding. Are > there any clues in the logs about what's triggering RejectedOverloads? Generally they are pre-emptive. > At one point inserts were much slower than requests - is that still the > case? Is the insert throttle slower than the request throttle, and if > so, why are inserts more likely to trigger RejectedOverloads than > requests are? Inserts are significantly slower than requests because: 1) An insert will touch a lot more nodes on average than a request. 2) This means the likelihood of getting a RejectedOverload is much higher. 3) It also means it takes much longer. 4) The RTT on a request is from sending it to finishing receiving data; the RTT on an insert is from sending it to receiving the all downstream transfers complete notification. -------------- 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/d1ae6bce/attachment.pgp>
