[ ... bad throughput on bad NICs ... ]
Nate Lawson wrote:
> > FWIW, the root cause is likely a result of something in the
> > last 8 months, which means log2(240)+1 = 8 compiles to find
> > the problem on your hardware; if, in the last 2.5 years,
> > which we know to be the case, it's log2(2.5*365)+1 = 10
> > compiles.
>
> My guess is mii_tick() latency.
Off the top of my head, I would blame one of:
1.79 don't strip the Ethernet header for input packets
1.72 If we get 0xffff back when reading the status register,
assume the card has gone away instead of spinning in
the interrupt handler. This stops my machine from
hanging when I eject a rl(4)-based cardbus card.
1.71 Fix if_timer logic to make sure that there is always a
timeout pending if there are packets queued for
transmission.
1.69 Add DEVICE_POLLING support to the "rl" driver. The
diffs are very similar to the ones for the "sis" driver.
If I had to place a bet, I would bet it was 1.69, even though he said
it happens with/without polling, he didn't say whether he disabled it
as a compilation option or just by using the sysctl. If he used the
sysctl method, that means an extra registration function call in
rl_intr(), each time an interrupt happens, which is nothing (but it
does affect the benchmarks, making polling look betther than it really
is, in a side-by-side comparison), and the rl_poll code gets called
on all the clock ticks, potentially skewing the hardware state: the
ether_poll code should probably also check that IFF_POLLING is set.
If it's not that, then my next favorite to blame would be 1.79, which
seems to me is a *massive* change.
I pick both of those because they are relatively driver-agnostic
changes, and he said they happened on both drivers.
My third choice, is "something else in the system was changed",
which makes it better to do the binary search.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
