Messages in this thread | | | Subject | Re: Gigabit Linux Server Bottlenecks | From | Jes Sorensen <> | Date | 08 Feb 2000 17:37:45 +0100 |
| |
>>>>> "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/
| |