On Mon, Nov 27, 2006 at 06:59:46PM +0000, Michael Rogers wrote: > toad wrote: > >In which case, can you detect at what point the throttle becomes the > >limiting factor rather than the submission of requests? > > The network with no flow control gets better throughput than the > networks with flow control even at very low request rates - this > probably just reflects the fact that it's hard to get 100% utilisation > from an adaptive throttling mechanism. Anyway the difference is small at > low request rates. > > The difference gets larger as the request rate increases - then > somewhere between 10 and 12 requests per node per minute, the throughput > of the network without flow control drops practically to zero as the > message queues get long enough to cause most requests to time out. This > is with 15 kbyte/s upstream and downstream bandwidth per node. I don't > think asymmetric bandwidth will make a big difference, because upstream > bandwidth will remain the bottleneck - the point where the collapse > occurs might shift a bit due to reduced queueing delays on the > downstream side, but the collapse will still happen. > > By 16 requests per node per minute, the throughput of the various flow > control mechanisms seems to be tailing off slightly - I need to run more > simulations to see whether this is due to random variation or whether it > represents a trend, but either way there's no dramatic collapse like > there is without flow control.
Okay, so there is a dramatic collapse because it reaches the maximum capacity of the network. Whereas with flow control, we keep on adding requests even though the network is overloaded, and they are misrouted, and not tried properly; we progressively route requests to fewer and fewer nodes. So the axes on the graph are a little misleading. We start very many requests, but we don't properly attempt them. This is bad; throttling is supposed to prevent us from trying so many requests that hardly any of them are properly attempted. So throttling should, on your axes, cut out some time before an unthrottled network cuts out. In fact, throttling on its own should not reduce the success rate, it should simply cause an earlier cut-out. We have to design the network on the basis that a lot of users (maybe most users) will have lots of files queued up; any throttling that is necessary to manage demand must be executed _by the network_. Ideally this means that the network would have nearly full performance up to some amount of input load, and then it would just stop, having reached its input load limit. > > Cheers, > 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/20061127/30e9059f/attachment.pgp>
