[Top] [All Lists]

Re: Perf data with recent tg3 patches

To: netdev@xxxxxxxxxxx
Subject: Re: Perf data with recent tg3 patches
From: Rick Jones <rick.jones2@xxxxxx>
Date: Fri, 20 May 2005 15:52:20 -0700
In-reply-to: <20050520.153326.08322399.davem@xxxxxxxxxxxxx>
References: <1116031159.6214.8.camel@rh4> <20050513.222007.78719997.davem@xxxxxxxxxxxxx> <Pine.LNX.4.61.0505201442380.11419@xxxxxxxxxx> <20050520.153326.08322399.davem@xxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.6) Gecko/20040304
Yes, but using such a high value makes latency go into the
toilet. :-)

For low packet rates.

I'd much rather see dynamic settings based upon packet rate.
It's easy to resurrect the ancient code from the early
tg3 days which does this.

If that is the stuff I think it was, it was giving me _fits_ trying to run TCP_RR tests. Results bounced all over the place. I think it was trying to kick-in at pps rates that were below the limits of what a pair of systems could do on a single, synchronous request/response stream.

Now, modulo an OS that I cannot mention because its EULA forbits discussing results with third parties, where the netperf TCP_RR perf is 8000 transactions per second no matter how powerful the CPU... if folks are simply free to set high coalescing parms on their own, presumably with some knowledge of their workloads, wouldn't that be enough? That has been "good enough" for one OS I can discuss - HP-UX - and its bcm570X-based GbE NICs and before to Tigon2.

rick jones

<Prev in Thread] Current Thread [Next in Thread>