John Carmack (of armadillo aerospace[2] and idsoftware fame) gave me
permission to repost from this private email...
John Carmack jo...@idsoftware.com writes:
I would really like to help, but I don't know of a good resource for
you [for 3D visualizations of bufferbloat]. If I could clone
At the risk of sounding like someone mentioning a product, let me mention a
product. This assumes, of course, that you're using Cisco equipment. But it
allows you to measure delay (how long does it take to get from here to there),
jitter (first derivative of delay/dt), and packet loss.
On 13 Mar, 2011, at 12:21 am, Fred Baker wrote:
At the risk of sounding like someone mentioning a product, let me mention a
product. This assumes, of course, that you're using Cisco equipment. But it
allows you to measure delay (how long does it take to get from here to
there), jitter
On 13 Mar, 2011, at 12:23 am, richard wrote:
However, large TCP windows do consume RAM in both server and client,
and with a sufficient number of simultaneous clients, that could
theoretically cause trouble. Constraining TCP windows to near the
actual BDP is more efficient all around.
Having read some more documents and code, I have some extra insight into SFB
that might prove helpful. Note that I haven't actually tried it yet, but it
looks good anyway. In control-systems parlance, this is effectively a
multichannel I-type controller, where RED is a single-channel P-type
