On Thu, Dec 07, 2006 at 05:41:51PM +0000, Dieter wrote:

> > However, I don't know what you mean by "data is lost".  Data should
> > never be lost from the filesystem regardless of how slow the I/O is
> > happening, unless there's something else going wrong (e.g. driver
> > bug).
> > 
> > Also, rtprio should not be used in general - see the manpage.  Were
> > you using rtprio in your original scenario?  It can easily cause
> > resource starvation.
> I have data arriving on Ethernet.  The data rate is 2.5 MB/s max,
> but the other end only has a small buffer.  If the BSD box doesn't read
> the port fast enough, the data is lost.  I have a C program (port2file)
> reading from the port into a *large* circular buffer, currently 431,226,880
> bytes.  This should be enough to buffer over 2 minutes of data.  It does
> non-blocking 64KB writes to stdout.  Shell script calls this program and
> redirects stdout to a disk file.  Very little if any other i/o to this
> disk.  Even with disk cache in write-through mode, I can write at about
> 6-7 MB/s.  The process needs very little CPU.  Sounds like this should
> be no problem.
> And it seems to work okay if the system is otherwise idle.
> The problem is that if some other process is writing to some other disk,
> it somehow slows down writes to ALL disks.  Enough that, dispite the 
> non-blocking
> writes (?), the TCP receive window shrinks and shrinks and finally is smaller
> than a packet.  The src machine obediantly stops sending packets, its small
> buffer fills up, and data is lost.
> Things I have done so far:
>    BIG buffer (over 2 minutes worth).
>    The port2file process cranks up the TCP receive window from 65700 to 
> 197100.
>    It also cranks up rtprio from 20 to 5.
>    sysctl net.inet.tcp.delayed_ack=0
> The only process running rtprio is port2file.  All other processes are
> either default priority or niced down with the classic nice(1).

Thanks for explaining the problem in more detail.  Did this problem
start before you made port2file run with rtprio?  Can you please
include a copy of your kernel configuration file and dmesg?


Attachment: pgpbpfD9fod7H.pgp
Description: PGP signature

Reply via email to