3 ms·
I see. I get the impression Aspera is built on a really simple solution, "pressure-adjusted" over a very long time to account for the fact that the real world i
by exikyut 7y ago
I see. I get the impression Aspera is built on a really simple solution, "pressure-adjusted" over a very long time to account for the fact that the real world isn't a vacuum :D
Hearing I can get to 80% quickly is encouraging from a MVP viability point of view, thanks. (And also from a fail-fast perspective; I've now gotten to wondering how much additional performance might be eked out of start-stop style traffic, and it's good to know it won't take long to find out whether the pursuit is worthless or not. Yay.)
I read the second half of that second paragraph as describing a network model simulation that "compiles" a particular routing graph/topology into a set-in-stone sequence of packet events that you then later analyze...? (I'm interpreting "the algorithm" is my target application code, and "synthetic time events" and "configured schedule" as hints at non-real-time pregeneration. This may be incorrect.)
Eek, the delay distributions you describe almost sound like they might be NP-complete to solve.
- ncmncm 7y agoThe idea of fast simulation is to feed just your sending-rate update algorithm with fake time samples, with nothing like actual packets anywhere, so you can get very quick evaluation of your algorithm's numerical behavior under a wide variety of conditions. Routes tend to start monomodal and split and rejoin at specific times, so it is not usually as bad as you imagine. Also, the number of routes does not get large.