--- Begin Message ---
Dear David,
I agree. My point is that currently ingress mode seems to be dropping
more packets than necessary to keep senders from bottlenecking the
connection (when there is a large number of concurrent flows, >8). And
right now, ingress mode is the only mode that achiev
Ingres and Egress are fundamentally different due to the fact that in ingress
mode you are having to throw away data that has successfully traversed the
bottleneck (deliberatly wasting your limited resource now to avoid having
senders bottleneck the queue on the far side of the link)
in Egress
--- Begin Message ---
I meant proportionally to (1-1/sqrt(x)).
On 11/13/2017 8:51 PM, George Amanakis wrote:
I am exploring this idea further. If q->time_next_packet is
incremented for dropped packets proportionally to (1-1/x), where x is
the count of all flows in the tin that is being served,
--- Begin Message ---
I am exploring this idea further. If q->time_next_packet is incremented
for dropped packets proportionally to (1-1/x), where x is the count of
all flows in the tin that is being served, ingress mode works much more
smoothly: latency is still <50ms and throughput is very nea
