At 07:38 PM 6/8/00 +0100, Alan Cox wrote:
>> eepro100. The freeBSD drivers in the exact same hardware survive the same
>> tests gracefully. When stuff comes in faster than it can go out linux fails
>> after a short while.
>What test set are you using for this. Ive run several tests against .15/.16
>drivers saturating 100Mbit lans without problems. Im curious what is
>in your environment that might be tripping this
The problem seems to occur when the system has a high number of buffers
allocated, although you would know why mallocs would fail better than I. By
stealing buffers from the system (using a bandwidth manager does this
easily) the condition can be forced.
By setting up a box with 1 100Mh/s eepro100 and 1 10Mb/s eepro100 (so that
the input is substantially higher than the output), setting numbers of
buffers to be held by the bandwidth manager (effectively the transmit queue
since we send data unidirectionally in this test)...once a certain number
of buffers are outstanding the eepro100 begins to complain about resources,
and eventually craps out, first with long periods on inactivitiy and
"restart" messages, then it locks up altogether. With 64M in the machine,
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.
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.....
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.
The bottom line is that the eepro100 driver just doesnt handle situations
where buffers cannot be replenished eloquently, and seems to fail when a
relatively small number of buffers are outstanding (and there *should* be
memory available...this may be an OS issue).
It seems likely that the same test with one of linux' shaping mechanism can
be done the same way.
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to firstname.lastname@example.org
This archive was generated by hypermail 2b29 : Thu Jun 15 2000 - 21:00:40 EST