On Mon, 15 Oct 2001 23:00:27 +0000 (UTC), in sentex.lists.freebsd.net you
wrote:
>Mike Tancsa writes:
>> >If the forwarding path is maxed out, then it is the application layer's
>> >responsibility to back off (think TCP).
>>
>> Is it better for the networking layer to deal with this (potentially
>> introducing some latency) as opposed to letting the application ?
>
>Oops, can substitute "transport" for "application"..
>
>But no, the network should just do "best effort".. that is, unless
>you are a telco type in which case, go back to your X.25 :-) This
>is a religious issue to some degree, but in practice the war is over
>and the Internet won (vs. the telco way of doing things).
>
>There is probably a good paper somewhere outlining the "best effort"
>philosophy but I don't know what it is. Another way to look at it
>is intelligence in the leaf nodes rather than in the network. This
>is one of the central idea of the Internet dating back to a long
>time ago. I guess the other big idea is packets instead of dedicated
>circuits (which hog resources).
Thanks for the info. Lugi Rizzo was kind enough to figure out what has
been going on. I increased the queue size to 512 on both my OC-3 equipped
machine (via the en device) as well as my pure FastE (via fxp) machines and
the problems have gone away. As to why this solved the problem Lugi wrote,
--------------
oh, did you see drops go to 0 when the queue size is 256 ? I missed
this. Then it means another thing, you are receiving a very large
burst of packet from the interface, larger than ipintrq, and this
is why they get dropped.
In fact, processing is done like this: in the interrupt driver,
while you have packets you fetch them from the device and queue
them in ipintrq. Once you are done with this (which could take
very long and drain a lot of packets if either packets come in very
fast, or the device queue is long and interrupts come late), you
go up and process packets in ipintrq.
Now, I am not 100% sure but the "en" device seems to have 512 slots
in the receive queue, hence the problem...
Normally, using fastforwarding would help because bypasses
ipintrq and calls directly ip_input(), except that "en"
calls atm_intr() which does not know anything about fastforwarding.
I think the above should explain the problem, and then you can
probably either set ipq_maxlen to a large enough value (like 512)
or slightly modify the "en" driver to limit the burst of packets
it produces to some more reasonable amount. Not my area though,
you should contact the author of the device driver to see if this
is possible.
-----------------------------
---Mike
Mike Tancsa ([EMAIL PROTECTED])
Sentex Communications Corp,
Waterloo, Ontario, Canada
"Given enough time, 100 monkeys on 100 routers
could setup a national IP network." (KDW2)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
