Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 18 Nov 2006 21:41:27 +1100 (EST)
From:      Bruce Evans <bde@zeta.org.au>
To:        Marcelo Gardini do Amaral <marcelo@registro.br>
Cc:        Robert Watson <rwatson@FreeBSD.org>, freebsd-performance@FreeBSD.org, kreios@gmail.com
Subject:   Re: DNS Performance Numbers
Message-ID:  <20061118202518.U15111@delplex.bde.org>
In-Reply-To: <20061117163534.GA57732@registro.br>
References:  <20061030192702.GG76994@registro.br> <20061111091844.I63959@fledge.watson.org> <20061116164053.GR57732@registro.br> <20061117201026.N11101@delplex.bde.org> <20061117163534.GA57732@registro.br>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 17 Nov 2006, Marcelo Gardini do Amaral wrote:

>>> I made some tests using 7.x with all the debugging disabled:
>>>
>>>                               queries / s
>>>
>>> Int     bind (d_t)      bind (e_t)      nsd (1_s)       nsd (2_s)
>>> ---     ----------      ----------      ---------       ---------
>>>
>>> bge     15439           14733           12910           10946
>>> em      37655           34092           42411           41974
>>> ...
>>
>> Try my fix for bge's interrupt handling in freebsd-net.
>
> I tried but I didn't get any improvement.

I also have some latency and overhead optimizations for bge.  I think
your test uses many threads to get parallelism so latency optimizations
wouldn't help much for it, but perhaps the problem is that the type
of interrupt moderation used by bge accidentally limits parallelism,
and then my changes might help by accidentally increasing parallelism
(they are only intended to help much for the non-parallel case).  bge
hardware has fairly sophisticated interupt moderation, but poor tuning
of it results in it reducing to almost the equivalent of polling at a
rate of 6667 Hz or 2*6667 Hz depending on whether the tx and rx polls
accidentally get in sync.  (Intentional use of polling would give even
worse latency unless you pessimize HZ too.)  To reach em's number of
operations per second, bge would have to do operations in bursts of 7
or 3.5 operations per poll, and the details of the operations or the
polling might prevent this.

For a quick test of latency reduction, try initializing
sc->bge_rx_coal_ticks to 150 instead of 1.

Bruce



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061118202518.U15111>