[Prism54-devel] Re: TxDescriptors -> 1024 default. Please not for every NIC!
Jean Tourrilhes
jt@hpl.hp.com
Thu, 20 May 2004 09:38:11 -0700
On Thu, May 20, 2004 at 10:11:11AM -0400, Luis R. Rodriguez wrote:
> On Wed, May 19, 2004 at 01:27:00PM +0300, Pekka Pietikainen wrote:
> > On Wed, May 19, 2004 at 11:30:28AM +0200, Marc Herbert wrote:
> > > - Me argues that we all lived happy for ages with this default
> > > setting of 100?packets @?100?Mb/s (and lived approximately happy @
> > > 10 Mb/s), but we'll soon see doom and gloom with this new and
> > > brutal change to 1000?packets for all this _legacy_ 10-100 Mb/s
> > > hardware. e1000 data only is not enough to justify this radical
> > > shift.
> > >
> > > If you are convinced by _both_ items above, then the patch below
> > > content _both_, and we're done.
> > >
> > > If you are not, then... wait for further discussion, including answers
> > > to latest Ricardo's post.
> >
> > Not to mention that not all modern hardware is gigabit, current
> > 2.6 seems to be setting txqueuelen of 1000 for 802.11 devices too (at least
> > my prism54), which might be causing major problems for me.
>
> Considering 802.11b's peak is at 11Mbit and standard 802.11g is at 54Mbit
> (some manufacturers are using two channels and getting 108Mbit now) I'd
> think we should stick at 100, as the patch proposes. Jean?
>
> Luis
I never like to have huge queues of buffers. It waste memory,
and degrade the latency, especially with competing sockets. In a
theoritical stable system, you don't need buffers (you run everything
synchronously), buffer are only needed to take care of the jitter in
real networks.
The real throughouput of 802.11g is more around 30Mb/s (at
TCP/IP level). However, wireless networks tend to have more jitter
(interference and contention). But, wireless cards tend to have a fair
number of buffers in the hardware.
I personally would stick with 100. The IrDA stack runs
perfectly fine with 15 buffers at 4 Mb/s. If 100 is not enough, I
think the problem is not the number of buffers, but somewhere else.
For example, we might want to think about explicit socket callbacks
(like I did in IrDA).
But that's only personal opinions ;-)
Have fun...
Jean