>>>>> "Ingo" == Ingo Molnar <mingo@chiara.csoma.elte.hu> writes:
Ingo> On 8 Feb 2000, Jes Sorensen wrote:
>> 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.
Ingo> i suspect the difference is that my system is not
Ingo> saturated. (has CPU cycles left). I'm saturating the TCP pipe
Ingo> (107MB/sec) and the gigabit card, while you are saturated
Ingo> CPU-power-wise. So it's pretty natural that if the CPU is too
Ingo> busy processing frames, workload gets clustered up into bigger
Ingo> chunks. Also, on which side do you have 2.5K ints/sec?
Oh it's been a while since I ran those tests, it was about the same
order for both receive and transmit. With Jumbo frames the numbers
certainly didn't go up.
Ingo> another difference might be TX interrupts - i'm using a TX
Ingo> interrupt per TX-ed descriptor (this way descriptors get freed
Ingo> up ASAP and the outgoing pipe can be restarted quickly)
Eeeek, now thats mean, how big is the TX ring on the SK card?
Ingo> if we (or the card) are clustering incoming frames even if load
Ingo> is not high, thats a latency problem - we want to know about
Ingo> available frames as soon as possible.
There's a latency tradeoff there, most coalescing algorithms basically
do wait for X packets and generate an interrupt or generate the
interrupt inbetween if there is more than Y usecs between packets. You
do not want an interrupt for each packet coming in.
Jes
-
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/
This archive was generated by hypermail 2b29 : Tue Feb 15 2000 - 21:00:13 EST