Re: eepro100 troubles

From: Dennis (
Date: Thu Jun 08 2000 - 19:56:33 EST

At 01:17 AM 6/9/00 +0100, Alan Cox wrote:
>> >You need to retune the VM by the sound of that. The rest/retry cycles
>> >like you've stolen so much memory at atomic priority the rest of the
>> >is taking defensive action 8)
>> They are just skbufs...system network buffers. We dont do any allocations.
>> Its analogous to a big queue.
>Thats the memory you are stealing
>> 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.
>The bandwidth manager
>> 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?
>CBQ can shape a lot more - and without using 300Mb of data.

buts its still crap...try to think outside the box.

>> 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
>With a T3 you should have about 60 buffers. Having more is just damaging
>the performance
60 buffers could be as little at 3600 bits on a 45Mb/s medium. Im really
surprised as your lack of understanding of the subject. But it does explain
the problems.

Your answers have done nothing to solve the problem, but I guess you feel
good about contradicting me. If you are only going to test within your
narrow realm of thought, the problems will continue. Thats why the drivers
are so buggy; you're spending your time arguing with the tests rather than
fixing the drivers.

Luckily we have BSD to fall back on. If you can't sell it, make sure its
there as a backup!

To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to

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