>Number:         12920
>Category:       kern
>Synopsis:       com(4) doesn't document ibuf floods
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    kern-bug-people
>State:          open
>Class:          doc-bug
>Submitter-Id:   net
>Arrival-Date:   Sat May 12 13:56:00 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     John Hawkinson
>Release:        -current of 11 Apr 2001
>Organization:
	MIT
>Environment:
	
System: NetBSD lola-granola.mit.edu 1.3.2 NetBSD 1.3.2 (ATHENA) #0: Mon Jun 22 17:32:46 EDT 1998 nathanw@antisnork.mit.edu:/u1/var/build/sys-1.3.2/arch/i386/compile/ATHENA i386


>Description:
	com(4) doesn't talk about what ibuf floods are, or COM_RING_SIZE.
>How-To-Repeat:
	
>Fix:
	
	Add text to the man page cribbed from below?:


Subject: increasing COM_RING_SIZE?
From: Steve Bellovin <smb@research.att.com>
To: netbsd-users@netbsd.org
Subject: increasing COM_RING_SIZE?
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 01 May 2001 19:08:46 -0400
Message-Id: <20010501230846.3E8F57B7B@berkshire.research.att.com>

Is there any reason (other than memory consumption) to refrain from 
changing COM_RING_SIZE from 2048 to, say, 32768?  The comments indicate 
that it's patchable, but has to be a power of 2.  It's used as the arg 
to malloc(); are there limits to how large a block kernel malloc() can 
allocate?

My concern is the data rate of the Novatel "Merlin for Ricochet" PCMCIA 
modem.  Linux has problems with its data rate (for details, see
http://homepages.nyu.edu/~gmp216/nrm6842/bigfastuart.html); in a very 
brief test today, I saw some indications that NetBSD was overflowing 
that buffer as well.

		--Steve Bellovin, http://www.research.att.com/~smb


Subject: Re: increasing COM_RING_SIZE?
Date: Tue, 1 May 2001 20:00:17 -0700
From: "Charles M. Hannum" <abuse@spamalicious.com>
To: Steve Bellovin <smb@research.att.com>
Cc: netbsd-users@netbsd.org
Subject: Re: increasing COM_RING_SIZE?
Message-ID: <20010501200017.E12715@mail.netbsd.org>
References: <20010501230846.3E8F57B7B@berkshire.research.att.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010501230846.3E8F57B7B@berkshire.research.att.com>; from smb@research.att.com on Tue, May 01, 2001 at 07:08:46PM -0400


On Tue, May 01, 2001 at 07:08:46PM -0400, Steve Bellovin wrote:
>
> Is there any reason (other than memory consumption) to refrain from 
> changing COM_RING_SIZE from 2048 to, say, 32768?  The comments indicate 
> that it's patchable, but has to be a power of 2.  It's used as the arg 
> to malloc(); are there limits to how large a block kernel malloc() can 
> allocate?

There should be no problems increasing it to any size you want, as long
as malloc() succeeds.

> My concern is the data rate of the Novatel "Merlin for Ricochet" PCMCIA 
> modem.  Linux has problems with its data rate (for details, see
> http://homepages.nyu.edu/~gmp216/nrm6842/bigfastuart.html); in a very 
> brief test today, I saw some indications that NetBSD was overflowing 
> that buffer as well.

Unless you got `silo overflow' or `ibuf flood' messages, that's not the
problem, or the hardware isn't reporting overflows.  It also seems a
little more suspicious since I *know* that we can keep up with a UART
running at 115200 baud, and Ricochet maxes at not much more than that.

So, I doubt this is going to help you, but I would need better
information to say anything else about it.

Subject: Re: increasing COM_RING_SIZE?
Date: Wed, 2 May 2001 03:11:25 GMT
Message-Id: <200105020311.f423BP102081@trinity.ihack.net>
From: "Charles M. Hannum" <abuse@spamalicious.com>
To: Steve Bellovin <smb@research.att.com>
Cc: netbsd-users@netbsd.org
Subject: Re: increasing COM_RING_SIZE?


BTW, something to keep in mind here is that there are actually *three*
buffers -- one on the chip/device, one in the com driver, and one in
the tty layer.

It's already the case that, if hardware flow control is enabled, the
com driver will keep data that doesn't fit in the tty buffer, until it
drains and the tty layer wakes it up again.  I wrote that code.  (I
would have made it do this in the case where there is no flow control,
but for the fact that there was no interface from the tty layer to
notify the driver when the tty buffer drains in that case.)

If the com driver's buffer overflows, or if the chip/device's buffer
overflows, you should get messages logged by the kernel (`ibuf floods'
and `silo overflows', respectively).  If you don't see these, you
should look elsewhere for whatever your problem is.

One common reason for the tty layer to overflow is that it depends on
applications actually reading the data.  This isn't a problem for
in-kernel PPP, but it's often that case that, e.g., kermit will
overflow the buffer by stalling while it's doing disk I/O.  This was
the main incentive to add the overflow logic (that and being able to
assert backpressure and actually turn off receive interrupts when
we're really screwed, avoiding livelock).

Subject: Re: increasing COM_RING_SIZE?
From: "Steven M. Bellovin" <smb@research.att.com>
To: "Charles M. Hannum" <abuse@spamalicious.com>
Cc: netbsd-users@netbsd.org
Subject: Re: increasing COM_RING_SIZE? 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 02 May 2001 07:06:17 -0400
Message-Id: <20010502110617.75DAD7B7B@berkshire.research.att.com>

In message <20010501200017.E12715@mail.netbsd.org>, "Charles M. Hannum" writes:
>
>Release-Note:
>Audit-Trail:
>Unformatted:
 >On Tue, May 01, 2001 at 07:08:46PM -0400, Steve Bellovin wrote:
 
 >
 >> My concern is the data rate of the Novatel "Merlin for Ricochet" PCMCIA 
 >> modem.  Linux has problems with its data rate (for details, see
 >> http://homepages.nyu.edu/~gmp216/nrm6842/bigfastuart.html); in a very 
 >> brief test today, I saw some indications that NetBSD was overflowing 
 >> that buffer as well.
 >
 >Unless you got `silo overflow' or `ibuf flood' messages, that's not the
 >problem, or the hardware isn't reporting overflows.  It also seems a
 >little more suspicious since I *know* that we can keep up with a UART
 >running at 115200 baud, and Ricochet maxes at not much more than that.
 >
 
 In fact, I am getting "ibuf flood" messages -- it was when I looked at 
 the code to see what caused that that I wondered about the ring buffer 
 size.
 
 
 		--Steve Bellovin, http://www.research.att.com/~smb