From owner-freebsd-net Wed Aug 1 22: 3:55 2001 Delivered-To: freebsd-net@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id AC62537B40E for ; Wed, 1 Aug 2001 22:03:38 -0700 (PDT) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id f7253jY08157; Thu, 2 Aug 2001 00:03:45 -0500 (CDT) (envelope-from jlemon) Date: Thu, 2 Aug 2001 00:03:45 -0500 (CDT) From: Jonathan Lemon Message-Id: <200108020503.f7253jY08157@prism.flugsvamp.com> To: shalunov@internet2.edu, net@freebsd.org Subject: Re: TCP problems with large window sizes on FreeBSD (GigaTCP) X-Newsgroups: local.mail.freebsd-net In-Reply-To: Organization: Cc: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In article you write: > >I cannot get it to run with window sizes greater than half a megabyte. > >The story, with some very preliminary analysis, is at >http://www.internet2.edu/~shalunov/gigatcp/ Very nice analysis! >1. How do I fix the ti driver problem that apparently is holding me > back? What number of jumbo slots would be "good"? I think problem 2 is a larger issue here. However, you should be able to bump up the number of jumbo buffers allocated simply by tweaking TI_JSLOTS to a larger value; the number of actual hardware descriptors used is specified elsewhere (TI_JUMBO_RX_RING_CNT == 256). > >2. Why doesn't Fast Retransmit kick in? (See the annotated sender's > view of the stalled connection.) Because the acks aren't completely duplicate acks, the window size changed. Fast Retransmit doesn't kick in unless a completely duplicate ack is received. The packets are stored in the reassembly queue, and don't count against the advertised receive window. However, since the receiver is slowly draining the buffer, it keeps opening the window and no dupacks are actually transmitted. >3. Is there an off-by-one error in RST handling? (See the end of the > annotated receiver's view of the stalled connection.) Looks like it. The code currently reads: if (SEQ_GEQ(th->th_seq, tp->last_ack_sent) && SEQ_LT(th->th_seq, tp->last_ack_sent + tp->rcv_wnd)) { And this probably should be "SEQ_GEQ(..) && SEQ_LEQ(...)". -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message