Hi mark, i just happened to lurk around and read the thread.
Did you try to run iozone on both systems?
Benchmarks like this are designed to test performance
of filesystems on a rather wide domain of all related values
(block size, file size, etc...)
It also produces graphs so that someone can eas
Bill Moran wrote:
In response to Mark Kirkwood <[EMAIL PROTECTED]>:
JoaoBR wrote:
I am not convinced that this kind of test is of any value for comparing
systems at all because there are too much factors involved - unless the
competitors are installed on identical hardware. On the other side
Oliver Fromme wrote:
Mark Kirkwood wrote:
> Exactly, that's why I did the comparison - I think you missed the part
> where I mentioned the 2 systems were *identical* with respect to cpus,
> memory, mobo - in fact even the power supplies are identical too!
So I assume your benchmark measure
Has anyone tried these tests with 4.x? Well, i did, and i was surprised
how good the performance is, it gave me the highest number of all tests,
even compared to much faster HW. Although this is all different
hardware, it seems like the performance drops the higher the version of
FreeBSD is, sp
On Thu, 2006-Dec-21 23:22:38 +1300, Mark Kirkwood wrote:
>Pieter de Goeje wrote:
>>On Wednesday 20 December 2006 11:38, Mark Kirkwood wrote:
>>>In fact if you note that the PIII HW *can* actually do 700MB/s, it
>>>suggests that your HW is capable of considerably more than 900MB/s -
>>>given that op
Pieter de Goeje wrote:
On Wednesday 20 December 2006 11:38, Mark Kirkwood wrote:
In fact if you note that the PIII HW *can* actually do 700MB/s, it
suggests that your HW is capable of considerably more than 900MB/s -
given that opteron's have excellent cpu to memory bandwidth, and the
speed of y
Pieter de Goeje wrote:
> Mark Kirkwood wrote:
> > Pieter de Goeje wrote:
> > > Copying /dev/zero to /dev/null yields more than 5GB/sec on a simple 2Ghz
> > > Athlon64. It imagine there are quite a few extra things done when copying
>
> On second thought, this is wrong because /dev/zero isn't
On Wednesday 20 December 2006 22:20, Mark Kirkwood wrote:
> Pieter de Goeje wrote:
> > On Wednesday 20 December 2006 11:38, Mark Kirkwood wrote:
> >> In fact if you note that the PIII HW *can* actually do 700MB/s, it
> >> suggests that your HW is capable of considerably more than 900MB/s -
> >> giv
Mark Kirkwood wrote:
Pieter de Goeje wrote:
It would be more interesting to see how random access to a (cached)
file performs in Linux vs FreeBSD, which seems a more logical pattern
for a database.
Agreed, and good point, I'll knock up a simple program to do random
and/or sequential acce
A few more tests with a slightly improved version of the program
(attached): We (i.e FreeBSD) do noticeably better with bigger block sizes.
Cheers
Mark
Gentoo - 2.6.18-gentoo-r3:
---
$ ./readtest /data0/dump/file 8192 0
random reads: 10 of: 8192 bytes elapsed: 1.2698s
In response to Mark Kirkwood <[EMAIL PROTECTED]>:
> JoaoBR wrote:
>
> > I am not convinced that this kind of test is of any value for comparing
> > systems at all because there are too much factors involved - unless the
> > competitors are installed on identical hardware. On the other side I thi
Mark Kirkwood wrote:
> Exactly, that's why I did the comparison - I think you missed the part
> where I mentioned the 2 systems were *identical* with respect to cpus,
> memory, mobo - in fact even the power supplies are identical too!
So I assume your benchmark measured the performance of the
On Wednesday 20 December 2006 07:38, Mark Kirkwood wrote:
> I was however trying to point out that as your machine is different from
> mine (opteron and ddr*400* as opposed to PIII and pc133), the fact that
> it is faster is not telling us anything about whether releng_6
> performance on cached fil
Pieter de Goeje wrote:
On Wednesday 20 December 2006 11:38, Mark Kirkwood wrote:
In fact if you note that the PIII HW *can* actually do 700MB/s, it
suggests that your HW is capable of considerably more than 900MB/s -
given that opteron's have excellent cpu to memory bandwidth, and the
speed of y
JoaoBR wrote:
I am not convinced that this kind of test is of any value for comparing
systems at all because there are too much factors involved - unless the
competitors are installed on identical hardware. On the other side I think it
is usefull to compare tweaked settings on a particular m
On Wednesday 20 December 2006 11:38, Mark Kirkwood wrote:
> In fact if you note that the PIII HW *can* actually do 700MB/s, it
> suggests that your HW is capable of considerably more than 900MB/s -
> given that opteron's have excellent cpu to memory bandwidth, and the
> speed of your memory!
Indeed
JoaoBR wrote:
On Tuesday 19 December 2006 22:05, Mark Kirkwood wrote:
In the process of investigating performance in another area I happened
to be measuring sequential cached reads (in a fairly basic manner):
$ dd if=/dev/zero of=/tmp/file bs=8k count=10 # create file
81920 bytes t
JoaoBR wrote:
On Wednesday 20 December 2006 07:37, Mark Kirkwood wrote:
JoaoBR wrote:
On Tuesday 19 December 2006 22:05, Mark Kirkwood wrote:
$ dd of=/dev/null if=/tmp/file bs=32k # read it
81920 bytes transferred in 1.801944 secs (454620117 bytes/sec)
hum, look my releng
On Wednesday 20 December 2006 07:37, Mark Kirkwood wrote:
> JoaoBR wrote:
> > On Tuesday 19 December 2006 22:05, Mark Kirkwood wrote:
> >> $ dd of=/dev/null if=/tmp/file bs=32k # read it
> >> 81920 bytes transferred in 1.801944 secs (454620117 bytes/sec)
> >
> > hum, look my re
JoaoBR wrote:
On Tuesday 19 December 2006 22:05, Mark Kirkwood wrote:
$ dd of=/dev/null if=/tmp/file bs=32k # read it
81920 bytes transferred in 1.801944 secs (454620117 bytes/sec)
hum, look my releng_6:
# dd of=/dev/null if=/c/c1/file bs=32k
81920 bytes transfe
JoaoBR wrote:
> hum, look my releng_6:
>
> # dd of=/dev/null if=/c/c1/file bs=8k
> 10+0 records in
> 10+0 records out
> 81920 bytes transferred in 1.017492 secs (805116851 bytes/sec)
> # dd of=/dev/null if=/c/c1/file bs=8k
> 10+0 records in
> 10+0 records out
> 81920 bytes
On Tuesday 19 December 2006 22:05, Mark Kirkwood wrote:
> In the process of investigating performance in another area I happened
> to be measuring sequential cached reads (in a fairly basic manner):
>
> $ dd if=/dev/zero of=/tmp/file bs=8k count=10 # create file
> 81920 bytes transferr
What does the memory-related stats from "top" show you? Did you have any
other memory intensive applications running at the time? A random
example from one of my systems (1GB RAM):
Thanks, good point - but no - absolutely nothing (machine is freshly
booted, and the only thing running is th
On 20/12/2006 12:05 PM, Mark Kirkwood wrote:
In the process of investigating performance in another area I happened
to be measuring sequential cached reads (in a fairly basic manner):
$ dd if=/dev/zero of=/tmp/file bs=8k count=10 # create file
81920 bytes transferred in 4.849394 se
In the process of investigating performance in another area I happened
to be measuring sequential cached reads (in a fairly basic manner):
$ dd if=/dev/zero of=/tmp/file bs=8k count=10 # create file
81920 bytes transferred in 4.849394 secs (168928321 bytes/sec)
$ dd of=/dev/null if
25 matches
Mail list logo
