Messages in this thread | | | Date | Tue, 8 Feb 2000 14:40:43 +0100 (CET) | From | Ingo Molnar <> | Subject | Re: Gigabit Linux Server Bottlenecks |
| |
On 8 Feb 2000, Jes Sorensen wrote:
> Ingo> yep, also with jumbo frames (mtu 9000) there is no problem at > Ingo> all. Eg. the SysKonnect cards i use do just over 20k IRQs/sec > Ingo> when i'm saturating 107MB/sec TCP bandwith - this IRQ load is > Ingo> simply not a problem at all for an APIC controller. I've seen > Ingo> IRQ rates of 80k/sec as well. > > Sorry but thats *BAD* performance by the SK card. I do around 2.5K > ints/sec with the Alteon when doing 65MB/sec traffic in one direction > with regular sized frames. The load is maybe not a problem for the > APIC, but 80k/sec truly sucks for the CPUs considering the number of > context saves/restores they have to do.
i suspect the difference is that my system is not saturated. (has CPU cycles left). I'm saturating the TCP pipe (107MB/sec) and the gigabit card, while you are saturated CPU-power-wise. So it's pretty natural that if the CPU is too busy processing frames, workload gets clustered up into bigger chunks. Also, on which side do you have 2.5K ints/sec?
another difference might be TX interrupts - i'm using a TX interrupt per TX-ed descriptor (this way descriptors get freed up ASAP and the outgoing pipe can be restarted quickly), but i'll switch to the logic i've added to eepro100.c: cluster TX interrupts if the queue is not full (there is no danger of Tx descriptor shortage in this case), and if the queue gets full then stop the queue until a certain number (# != 1) of descriptors have been freed. (hysteresis) [There might be some difference in queueing here since i'm doing this based on Alexey's softnet 'next generation networking' code.]
if we (or the card) are clustering incoming frames even if load is not high, thats a latency problem - we want to know about available frames as soon as possible.
-- mingo
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |