On 2/6/13 4:46 AM, John Baldwin wrote:
On Wednesday, February 06, 2013 6:27:04 am Randall Stewart wrote:
John:
A burst at line rate will *often* cause drops. This is because
router queues are at a finite size. Also such a burst (especially
on a long delay bandwidth network) cause your RTT to increase even
if there is no drop which is going to hurt you as well.
A SHOULD in an RFC says you really really really really need to do it
unless there is some thing that makes you willing to override it. It is
slight wiggle room.
In this I agree with Andre, we should not be *not* doing it. Otherwise
folks will be turning this on and it is plain wrong. It may be fine
for your network but I would not want to see it in FreeBSD.
In my testing here at home I have put back into our stack max-burst. This
uses Mark Allman's version (not Kacheong Poon's) where you clamp the cwnd at
no more than 4 packets larger than your flight. All of my testing
high-bw-delay or lan has shown this to improve TCP performance. This
is because it helps you avoid bursting out so many packets that you overflow
a queue.
In your long-delay bw link if you do burst out too many (and you never
know how many that is since you can not predict how full all those
MPLS queues are or how big they are) you will really hurt yourself even worse.
Note that generally in Cisco routers the default queue size is somewhere between
100-300 packets depending on the router.
Due to the way our application works this never happens, but I am fine with
just keeping this patch private. If there are other shops that need this they
can always dig the patch up from the archives.
This is yet another time when I'm sad about how things happen in FreeBSD.
A developer come forward with a non-default option that's very useful
for some specific workloads, specifically one that contributes much time
and $$$ to the project and the community rejects the patches even though
it's been successful in other OSes.
It makes zero sense.
John, can you repost the patch? Maybe there is a way to refactor this
somehow so it's like accept filters where we can plug in a hook for TCP?
I am very disappointed, but not surprised.
-Alfred
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
