On Thu, 18 Oct 2001, Terry Lambert wrote:
> In the non-LRP case, the percentage drop in interrupt overhead
> is ~10% (as has been observed by others). THis makes sense,
> too, if you consider that NETISR driving of receives means
> less time in interrupt processing. If we multiply the 15%
> (100% - 85% = 15% in transmit) by 3 (12000/(12000-8000) =
> 100% / 33% = 3), then we get 45% in transmit in the non-LRP
> case.
Hrm, so the reduction I saw is repeatable; good. If there are no
objections, I'll fix up the whitespace later this week, fix the warning,
and commit it. (The whitespace applies to the unified diff I created;
your context one may have correct whitespace.)
> It would be nice if someone could confirm that slightly less
> than 1/2 of the looping is on the transmit side for a non-LRP
> kernel, but that's about what we should expect...
If it is, I wonder if we could put a larger number of packets in the queue
and disable transmit interrupts for a while. MMmm, dynamic queues.
Sounds like something that would take a lot of work to get right,
unfortunately. (Presumably, this tactic could be applied to most network
cards, although all the better ones probably have really good transmit
interrupt mitigation.)
> I'm really surprised abuse of the HTTP protocol itself in
> denial of service attacks isn't more common.
Well, the attack your proposed would require symmetric bandwidth (if I
understood it correctly), and is of course traceable. My guess would be
that even script kiddies are smart enough to avoid attacks which could
easily be traceable back to their drones.
> Even ignoring this, there's a pretty clear off the shelf
> hardware path to a full 10 gigabits, with PCI-X (8 gigabits
> times 2 busses gets you there, which is 25 times the largest
> UUNet hosting center pipe size today).
Are you sure about that? I recently heard that Internet2 will be moving
to 2.4Gbps backbones in the near future, and I assume that qwest wouldn't
be willing to donate that bandwidth unless they had similar capabilities
already. ("They" being generalized to all backbone providers.)
> Fair share is more a problem for slower interfaces without
> hardware coelescing, and software is an OK band-aid for
> them (IMO).
>
> I suspect that you will want to spend most of your CPU time
> doing processing, rather than interrupt handing, in any case.
>
> -- Terry
Yep, probably. Are you implementing fair sharing soon?
Mike "Silby" Silbersack
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
