[Tech] LIFO simulations

[Michael Rogers]

Jano wrote:
> Ummm. Each branch is counted as a success? All of them must succeed? Just
> the longer one? Is this nonsense?

Not nonsense, but the choice between the various options seems to be 
fairly arbitrary. On the other hand there's only one way to define route 
length for requests, so I guess we could add a hop counter to 
ChkDataFound and SskDataFound.

> * I'm dropping messages at the tail when queues reach 50.000 messages queued
> (for search and transfer queues). I implemented this in the hope of getting
> rid of OOMs. I'm getting them anyway, so I've screwed something in the
> process.

Not necessarily - 500 peers * 2 queues * 50,000 messages could easily 
eat a gig or two of memory.

> I could only simulate up to 30 with lifo queues and this change;
> see the graph. I don't think it's correct. Have we some idea on what is the
> theoretical maximum throughput for the simulated network, as currently
> defined?

It depends on how far the data's travelling. Ignoring inserts and slow 
nodes for the moment, half the requests are for CHKs and half are for 
SSKs, so the average size of a reply is about 17 KB. The total capacity 
of the network is 1500 KB per second, and the maximum sustainable 
throughput (for FIFO at least) seems to be about 8000 in replies in 2 
hours = 11 replies per second. That would imply that replies are 
travelling an average of 1500/(11*17) = 8 hops, but that's a *very* 
rough estimate.

> * I'm counting just remote successes. If we are measuring the load balancing
> performance, I don't think the local hits are of any interest and could
> mask the remote ones.

Good point - maybe that's why our figures for backoff at high loads are 
different. (I'm also at revision 11135 by the way.) It makes sense that 
you'd see a low success rate but high throughput if requests were either 
succeeding locally or not at all.

Unfortunately this suggests that simply counting the number of successes 
(or even remote successes) isn't an adequate measure of throughput - 
being able to retrieve the nearest tenth of the keyspace in one minute 
isn't equivalent to being able to retrieve the entire keyspace in ten 
minutes...

Any suggestions for a better metric?

> * I'm not computing failures anymore since messages dropped by far exceed
> successes. Half an hour of simulation would produce near 1GB of logs, given
> the amount of msgs dropped!

We should probably replace the logging statements with a static counter. 
Bear in mind that a dropped message doesn't necessarily lead to a 
failure - under some circumstances the upstream node can move on if it 
gets a timeout, so a search can suffer several dropped messages and 
still succeed.

Cheers,
Michael