Hello, Samuel.
You wrote 15 декабря 2011 г., 16:32:47:
Other benchmarks in the Phoronix suite and their representations are
similarly flawed, _ALL_ of these results should be ignored and no time
should be wasted by any FreeBSD committer further evaluating this
garbage. (Yes, I have been down
Hello, Adrian.
You wrote 16 декабря 2011 г., 20:43:27:
Guys/girls/fuzzy things - this is 2011; people look at shiny blog
sites with graphs rather than mailing lists. Sorry, we lost that
battle. :)
My thoughts exactly.
--
// Black Lion AKA Lev Serebryakov l...@freebsd.org
On 12/19/11 09:27, Lev Serebryakov wrote:
Hello, Samuel.
You wrote 15 декабря 2011 г., 16:32:47:
Other benchmarks in the Phoronix suite and their representations are
similarly flawed, _ALL_ of these results should be ignored and no time
should be wasted by any FreeBSD committer further
2011/12/19 Lev Serebryakov l...@freebsd.org:
Hello, Samuel.
You wrote 15 декабря 2011 г., 16:32:47:
Other benchmarks in the Phoronix suite and their representations are
similarly flawed, _ALL_ of these results should be ignored and no time
should be wasted by any FreeBSD committer further
On Mon, Dec 19, 2011 at 6:49 PM, Samuel J. Greear s...@evilcode.net wrote:
FreeBSD actually does _BETTER_ (subjectively) in this test than the
Linux system when you look at what is really going on. FreeBSD is
favoring writes, which is _GOOD_. FreeBSD does not need to be fixed,
the benchmarks
On 19 dec 2011, at 12:50, Samuel J. Greear s...@evilcode.net wrote:
2011/12/19 Lev Serebryakov l...@freebsd.org:
Hello, Samuel.
You wrote 15 декабря 2011 г., 16:32:47:
Other benchmarks in the Phoronix suite and their representations are
similarly flawed, _ALL_ of these results should be
IMHO, no offence, as always.
As were told, Phoronix used default setup, not tuned.
So? Is average user will tune it after setup? No, he'll get same defaults,
and would expect same performance as in tests, and he probably get it.
The problem of FreeBSD is not it's default settings, some kind of
On 12/19/11 13:21, Andreas Nilsson wrote:
On 19 dec 2011, at 12:50, Samuel J. Greear s...@evilcode.net wrote:
2011/12/19 Lev Serebryakov l...@freebsd.org:
Hello, Samuel.
You wrote 15 декабря 2011 г., 16:32:47:
Other benchmarks in the Phoronix suite and their representations are
similarly
В Sat, 17 Dec 2011 23:13:16 +0200
Andriy Gapon a...@freebsd.org пишет:
on 17/12/2011 19:33 George Mitchell said the following:
Summing up for the record, in my original test:
1. It doesn't matter whether X is running or not.
2. The problem is not limited to two or fewer CPUs. (It also
on 19/12/2011 19:46 Ivan Klymenko said the following:
В Sat, 17 Dec 2011 23:13:16 +0200
Andriy Gapon a...@freebsd.org пишет:
on 17/12/2011 19:33 George Mitchell said the following:
Summing up for the record, in my original test:
1. It doesn't matter whether X is running or not.
2. The
Problem solved - it was indeed an endian thing.
The problem is that fsck uses a real_dev_bsize variable that is declared long,
but the DIOCGSECTORSIZE ioctl takes an u_int argument.
A PR has been submitted.
Cheers
Michiel
___
On Mon Dec 19 11, Nathan Whitehorn wrote:
On 12/18/11 04:34, Adrian Chadd wrote:
The trouble is that there's lots of anecdotal evidence, but noone's
really gone digging deep into _their_ example of why it's broken. The
developers who know this stuff don't see anything wrong. That hints to
me
On 2011-Dec-19 22:27:49 +0100, Michiel Boland bolan...@xs4all.nl wrote:
Problem solved - it was indeed an endian thing.
The problem is that fsck uses a real_dev_bsize variable that is declared long,
but the DIOCGSECTORSIZE ioctl takes an u_int argument.
To be accurate, this isn't an endian
13 matches
Mail list logo
