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.
