Re: LIFO simulations

Michael Rogers wrote:

> Jano wrote:
>> My Sim.NODES is 100?
> 
> Mine too, but each Node has an average of five Peers.
> 
>> In any case the queues getting larger are the
>> transfers, and with your below 17KB mean reply size that's clearly a lot
>> more than 2G. By large.
> 
> 17 KB is the average size of a reply inside the simulated network. In
> the simulator itself the messages are much smaller, but even if they're
> only 40 bytes that would add up to 2 GB.

Of course; my bad. I tried reducing the queues to a meager 10 slots, and
even so I get OOMs.

>> But, assuming the 8hop average, we have only ~79k
>> maximum throughput, and then my last simulation is clearly overboard.
> 
> Right - I think what we're seeing is that when the network is
> overloaded, short-range requests are succeeding but long-range requests
> are failing, so the average route length is no longer 8 hops. Which
> means route length isn't necessarily a good metric either. :-/

I'd not jump to any conclusion based on that last simulation of mine. What
you suggest may be true and we should remember it, however. Perhaps they're
indeed single-hop successes...

>>> Any suggestions for a better metric?
>> 
>> At this preliminary point, I'd say that remote successes are a good
>> start. We could later study the hop count of successes in a non-saturated
>> network and compare to the saturated cases.
> 
> Good plan - I've added separate counters for local and remote successes.
> 
>> I'll take advantage of this and redo my lifo changes more
>> carefully. If I could get svn write right I could put them in a new
>> "phase" in the sim repository...
> 
> Sounds good - or even better, add a lifo switch to the command line that
> sets a static flag in Peer, then check the flag when adding messages to
> the queue. That way if we make any other changes we don't have to
> maintain two parallel branches.

Ok.