>   Note that we presently don't lock anything (this is expected, we
> haven't gotten there yet). However, note also that in the new version we
> also do an "_IFQ_DROP()" if we have exceeded the ifq_maxlen, and
> finally, also note that the new test is ">" and not ">=" - I don't know
> why it is ">=" to begin with. One would think that we should be testing
> for whether we are going to _exceed_ ifq_maxlen, not if we're going to
> reach it (we should be allowed to reach it).

OK, this makes a lot of sense.

> > So, no solution, right? :(
>       Well, you're sending out packets faster than your hardware can
> transmit them. You can `artificially' define IFQ_MAXLEN to something
> greater than 50 but practically, you probably won't get much besides for
> consuming more memory for the output queue.

Well, my main worry is to make sure FreeBSD works at least as well as any
other OS our customers may be using or familiar with; I'm not really
worried about performance of my -CURRENT laptop (or I'd run -STABLE ;-).
Given that it's more of an hardware issue, I'm not really tempted to
hack around it, expecially given that you admit it won't do much.

So, at least now we know what to answer if the question arises again (I
has several people who send 'me too' emails to me).

Thanks for helping, Bye,

     The three Rs of Microsoft support: Retry, Reboot, Reinstall.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to