On Wed, Apr 24, 2013 at 1:46 PM, Sami Halabi wrote:
> 3. there some point of improved performance (without fw) that went down
> again somewhere before Clang got prod.
Found it !
It's commit 242402: "Rework the known mutexes..."
ministat -s 242401.forwarding 242402.forwarding
x 242401.forwarding
TB --- 2013-04-25 00:07:39 - tinderbox 2.10 running on freebsd-current.sentex.ca
TB --- 2013-04-25 00:07:39 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64
TB --- 2013
On 4/24/2013 6:45 AM, Olivier Cochard-Labbé wrote:
> # Why all these benchs ? #
>
> I've found performance regression regarding packet forwarding/ipfw/pf
> speed on -current comparing to 9.1 on my old server.
BTW, how much of a drop in performance as compared to 9.1 ?
---Mike
--
--
On 4/24/13 6:45 PM, Olivier Cochard-Labbé wrote:
Hi all,
here is the result of my simple-and-dummy bench script regarding
forwarding/ipfw/pf performance evolution on -current on a single-core
server with one flow only.
It's the result of more than 810 bench tests (including reboot between
each)
On Wed, Apr 24, 2013 at 12:25:02AM +0400, Gleb Smirnoff wrote:
T> just upgraded from r245115 to r249810 and now box reliably panics on
T> boot a second after mounting root.
I've nailed it down. It is a stack buffer overflow in the
nvidia-driver. I've submitted patch to port maintainer.
--
Totu
On Tue, 2013-04-23 at 21:03 +0200, Dimitry Andric wrote:
> On Apr 17, 2013, at 21:16, Jung-uk Kim wrote:
> > On 2013-04-17 06:07:47 -0400, Dimitry Andric wrote:
> >> On Apr 17, 2013, at 07:31, Jan Beich wrote:
> >>> Dimitry Andric writes: On Apr 16, 2013, at
> >>> 00:42, Jan Beich wrote:
> >> .
Sean Bruno wrote:
> Would we need a change to /etc/defaults/rc.conf to set ${named_confdir}
> to the default location if not set?
I'm not sure. It's derived:
load_rc_config $name
# Updating the following variables requires that rc.conf be loaded first
#
required_dirs="$named_chrootdir"#
On Wed, 2013-04-24 at 16:35 +0200, Ian FREISLICH wrote:
>
> --- /usr/src/etc/rc.d/named 2013-04-15 20:17:58.0 +0200
> +++ /etc/rc.d/named 2013-04-24 16:16:52.0 +0200
> @@ -109,7 +109,7 @@
>
> named_reload()
> {
> - ${command%/named}/rndc reload
> + ${comman
Hi
I often run named outside of the system default directories so that
amongst other things a mergemaster fumble doesn't break my name
servers. This however breaks rndc because it is not imbued with
the clue of where to find its key.
/etc/rc.d/named does create the key file in the correct place
TB --- 2013-04-24 12:49:07 - tinderbox 2.10 running on freebsd-current.sentex.ca
TB --- 2013-04-24 12:49:07 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64
TB --- 2013
On 24.04.2013 12:45, Olivier Cochard-Labbé wrote:
Hi all,
here is the result of my simple-and-dummy bench script regarding
forwarding/ipfw/pf performance evolution on -current on a single-core
server with one flow only.
It's the result of more than 810 bench tests (including reboot between
each)
On Wed, Apr 24, 2013 at 1:46 PM, Sami Halabi wrote:
> Oliver,
> Great and impressive job.
Thanks,
> 3. there some point of improved performance (without fw) that went down
> again somewhere before Clang got prod.
=> Yes, I'm still working on detected the commit that create this degradation.
>
Oliver,
Great and impressive job.
If I interpret the plot as is the result say (approximatly of course):
1. Forwarding using ipfw with single rule degrades ~25% the pps.
2. Forwarding with pf however gets ~50%+ of degredation if performance pps.
3. there some point of improved performance (without
Hi all,
here is the result of my simple-and-dummy bench script regarding
forwarding/ipfw/pf performance evolution on -current on a single-core
server with one flow only.
It's the result of more than 810 bench tests (including reboot between
each) done twice for validating my methodology.
# Discla
14 matches
Mail list logo
