toad wrote: > "No flow control" stops at around > 6 because above input load = 6 the network collapses?
Right - actually I did three runs with a load of 6 and it only collapsed in one, but including the other two would have made the figures inconsistent. At a load of 7 it collapsed every time, and at a load of 5 it didn't collapse at all. The collapse seems to happen when messages are being queued more quickly than they can be transmitted, until at some point the queueing delay exceeds the timeout. The exact collapse point varies slightly from run to run because the slow nodes and requesters are chosen at random in each run. > red seems to be overtaking green > at 15, probably this is the result of the expected beneficial effects of > backoff (isolating throttling from the effects of really slow nodes) ? Possibly - there's quite a lot of variation between runs, so we'd probably have to average at least ten runs to be sure we were seeing a trend. Unfortunately I need to use my computer for other things today and tomorrow, but I'll set up some more runs over the weekend. It looks like Jano's simulating higher loads so I'll try to coordinate with him. > It would be useful to see whether red can sustain a lead over green. Is > there an endpoint, or does it tend towards a limit on throughput? I hope both throughput and success rate will level out - that will indicate that we're not allowing searches to start unless they have a good chance of completing (one way or another) without timing out. Then it's just a question of finding the mechanism that levels out at the highest throughput. > At around 10, the success rate and the throughput start to increase with > increasing input load, with throttling, with or without backoff; this is > rather surprising too; I'd expect the throughput to increase a bit, but > the success rate increasing is surprising. That is strange - I hope it will disappear when I do more runs. :-) Cheers, Michael
