On 6 Apr 2012, at 12:48, "O. Hartmann" wrote:
> I'm looking for a way to force FreeBSD 10 to maintain/watch ECC errors
> reported by UEFI (or BIOS).
> Since ECC is said to be essential for server systems both in buisness
> and science and I do not question this, I was wondering if I can not
> rep
page before installation you can
tweak everything from the location of the bootloader to sysctl values. I
know this has been tried before, but I wonder if we need a project to
build a new installer that can do this, perhaps funded through the
FreeBSD Foundation?
--
Bruce Cran
___
with him to get him what
he needs.
Who's 'reppie'?
--
Bruce Cran
___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "freebsd-performance-unsubscr...@freebsd.org"
ems with ULE on a dual-socket quad-core Xeon
machine with 16 logical CPUs. If I run "tar xf somefile.tar" and "make
-j16 buildworld" then logging into another console can take several
seconds. Sometimes even the "Password:" prompt can take a couple of
seconds to app
correct value
of this, seemingly, important tunable.
Note that I said "for example" :)
I was suggesting that there may be sysctl's that can be tweaked to
improve performance.
--
Bruce Cran
___
freebsd-performance@freebsd.org ma
'm wondering if the installer should ask people what the
typical use will be, and tune the scheduler appropriately.
--
Bruce Cran
___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To u
ows really grok multi-socket, multi-core
HyperThreaded systems and prefer real cores on the same NUMA node when
running a multi-threaded application, whereas it seems FreeBSD struggles
sometimes.
--
Bruce Cran
___
freebsd-performance@freebsd.org ma
in a SAS RAID-10 configuration.
Exactly: since the disk obviously can't write at 210MB/s (115 seems to
be about its maximum) ZFS is buffering the data and then has to spend
time flushing it to disk during which time it can't accept any new I
g 80k iops and
210MB/s for a few seconds followed by several of 0.
--
Bruce Cran
___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "freebsd-performance-unsubscr...@freebsd.org"
e disk at 100% for several seconds even after
the application has finished. Despite seeing iops go as high as 65k the
average seems not so impressive at around 15k, though it is only on a
single SATA drive.
--
Bruce Cran
___
freebsd-performance@freebsd.org
On Fri, 07 Jan 2011 10:19:05 -0600
"Mark Felder" wrote:
> On Fri, 07 Jan 2011 09:19:30 -0600, Bruce Cran
> wrote:
>
> > People seem to forget that debugging is turned off before the RC
> > builds are done, which is what Phoronix tested (8.0 RC1).
>
> Th
seem to forget that debugging is turned off before the RC builds
are done, which is what Phoronix tested (8.0 RC1).
--
Bruce Cran
___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscrib
't
> make it into src \ tree. by now it's probably outdated and needs to
> be reworked quite a bit.
>
> does anybody know something about this?
Google suggests that the work was a GSoC project in 2005 on a pluggable
disk scheduler.
--
Bruce Cran
_
more than 15 on Linux.
--
Bruce Cran
___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "freebsd-performance-unsubscr...@freebsd.org"
ood at keeping user-interactive processes
> responsive while compiles or what-not are going on in the background.
I've definitely seen problems when running builds in an xterm. I've
often resorted to canceling it and running it on a syscons console
instead to impr
was running a kernel
with WITNESS and INVARIANTS, but I've found ZFS to be far better if you
want good interactivity when reading/writing to disks.
--
Bruce Cran
___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinf
y case, as +20 seems not to be the
> idle priority anymore?!?
Have you tried increasing kern.sched.preempt_thresh? According to
http://groups.google.com/group/mailing.freebsd.stable/browse_thread/thread/05a39f816fd8acc6/82affa9f195b747d?lnk=raot&fwc=1&pli=1
a good value for desktop use woul
On Wed, 30 Sep 2009 04:56:51 -0500
Robert Noland wrote:
> On Wed, 2009-09-30 at 09:53 +0200, Oliver Lehmann wrote:
> > Daniel O'Connor writes:
> >
> > > In the end I got a PCI Silicon Image 3114 based controller and it
> > > worked fine.
> >
> > I thought about getting a controller with a SiL-
r and less "proven".
>
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/acpica/acpi_hpet.c
shows some of the history behind the decision. Apparently it used to
be slower but it was hoped it would get faster as systems supported it
better. I guess that's happening now.
--
19 matches
Mail list logo
