"Rogier R. Mulhuijzen" wrote: > At 11:42 1-1-2002 -0500, [EMAIL PROTECTED] wrote: > >Just note that "no buffers" often means that the queue is full, not that you > >are out of system buffers. You may be chasing a ghost. > > Well a queue should be cleaned shouldn't it? The mount_smbfs fails even > hours after I run the stresstest on my device. > > And which queue exactly are we talking about, and where/how do I check its > status?
Transmit queue depths are administratively limited. Consider that the default is ~16k (there was some discussion about upping this recently, which I think would be unwise). So a server with would be limited to 125,000 connections, if all transmit and receive queues were full, and there were a total 4G of RAM dedicated to nothing other than buffers. In practice, you can only sustain ~64k connections without memory overcommit or window size adjustment of some kind (overcommit works in this case, so long as you know what you are ddoing, and understand queueing theory). The problem you are running into is that your device is not draining the transmit queue fast enough. One way around this is to simply limk mbufs onto the transmit queue (ignore the limits). Another is the sysctl for send space, which will let you up it to any number you want (but you can run out of real memory and deadlock, if you set the administrative limit so that it is effectively unlimited). If you are hitting this limit, you should look at how your device operates. It would be a good idea to batch up your requests, for example (e.g. like the interrupt coelescing built into the Tigon II and Tigon III card drivers and firmware, or like the soft interrupt coelescing patches I posted for a number of network drivers a while back). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
