Re: eepro100 troubles

From: Dennis (dennis@etinc.com)
Date: Thu Jun 08 2000 - 19:19:20 EST


At 12:26 AM 6/9/00 +0100, you wrote:
>> if the number of buffers outstanding is limited to 500, the card will
>> complain about no buffers but will continue to operate. Once the number is
>> allowed to grow to 1000, it will reset regularly and eventually fail. With
>> 16M it will fail even with 500 buffers outstanding.
>
>You need to retune the VM by the sound of that. The rest/retry cycles sound
>like you've stolen so much memory at atomic priority the rest of the system
>is taking defensive action 8)

They are just skbufs...system network buffers. We dont do any allocations.
Its analogous to a big queue.

>
>> Typically you may need to hold as many as 5000-8000 buffers (maybe 30M for
>> a 100Mb/s medium), so this is no even a cutting edge test.....
>
>30Mbytes of buffers ?? your shaping algorithm sounds broken.

Our product is a bandwidth manager, not a "shaper". You may have to hold 3
seconds worth of data for each limit with an upper limit of the full
medium, thats 300Mb of real data...and buffers are larger than the data.

>
>> In contrast, the same test on freebsd, the fxp driver will complain about
>> not enough buffers (only once) but will continue to operate continuously
>> without resets or gaps in operation, regardless of the amount of memory in
>> the machine or the number of buffers held by the bandwidth manager. This is
>> as expected: if memory isnt available frames will be dropped but operation
>> will continue as best as is possible given the resources available.
>
>BSD preallocates a network buffer pool we are UMA.
>> It seems likely that the same test with one of linux' shaping mechanism can
>> be done the same way.
>
>The traffic shaper never gets about about 200 buffers.

hence its lack of robustness....if you have 1000 IP addresses being
limited....holding 1 buffer per defined limit is not much. Surely cbq or
something else can shape more than a few 100k of traffic?

the *point* is that the driver fails when there are no buffers and it
shouldnt. The bandwidth manager just accelerates the process. Its just a
test to cause the condition. If you have 8 ethernets and each has a
transmit queue of 100 buffers, you can have 800 buffers outstanding just in
the transmit queues. With a T3 frame relay line with 100 DLCIs you could
have 100*100. Its not an impossible or unnatural condition. In fact its
quite common.

Dennis
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.rutgers.edu



This archive was generated by hypermail 2b29 : Thu Jun 15 2000 - 21:00:40 EST