Petri Helenius wrote:
I noticed that changing vfs.read_max from the default 8 to 16 has a
dramatic effect on sequential read performance. Increasing it further
did not have measurable effect.
Increasing MAXPHYS in sys/param.h from 128k to 1M increased sequential
read thruput on my MegaRAID 1600
Robert Watson wrote:
The next thing that would be quite nice to measure is the rate of I/O
transactions per second we can get to the disk using the disk device
directly, with a minimal transaction size. I have a vague
recollection that you have to be careful in Linux because their
character de
On 5/2/2005 4:56 PM, Jonathan Noack
Look at the difference in sys times for raw vs. filesystem reads. With
raw we're at 2.73s while reading from the filesystem requires 12.33s!
From my position of complete ignorance that seems like a lot...
Indeed thats why I hit on using time as well as just
On Sun, May 01, 2005 at 07:34:31PM -0400, Mike Tancsa wrote:
> I havent paid that much attention to the comparisons as they tend to be
> very windows based and games to boot. But surely its hard to compare
> across platforms. The CPUs require different chipsets, so some of the
> performance res
On Mon, May 02, 2005 at 10:22:03AM -0400, David Gilbert wrote:
> > "Mike" == Mike Tancsa <[EMAIL PROTECTED]> writes:
>
> Mike> Thanks! I was worried I was missing something obvious in all
> Mike> the 64bit excitement. For my apps where I cant balance across
> Mike> multiple machines or where
On 5/2/2005 4:56 PM, Steven Hartland wrote:
- Original Message - From: "Poul-Henning Kamp" <[EMAIL PROTECTED]>
On -current and 5.4 you don't have to make partitions if you
intend to use the entire disk (and provided you don't want
to boot from it). You can simply:
newfs /dev/da0
mount /dev
- Original Message - >
Raw read:
/usr/bin/time -h dd of=/dev/null if=/dev/da0 bs=64k count=10
10+0 records in
10+0 records out
655360 bytes transferred in 32.028544 secs (204617482 bytes/sec)
32.02s real 0.02s user 2.73s sys
Out of
--- Steven Hartland <[EMAIL PROTECTED]> wrote:
> - Original Message -
> From: "Poul-Henning Kamp" <[EMAIL PROTECTED]>
> > On -current and 5.4 you don't have to make partitions if you
> > intend to use the entire disk (and provided you don't want
> > to boot from it). You can simply:
> >
- Original Message -
From: "Poul-Henning Kamp" <[EMAIL PROTECTED]>
On -current and 5.4 you don't have to make partitions if you
intend to use the entire disk (and provided you don't want
to boot from it). You can simply:
newfs /dev/da0
mount /dev/da0 /where_ever
/dev/da0: 1526216.3MB (31
On 5/2/2005 3:43 PM, Steven Hartland wrote:
Nope thats 5.4-STABLE this should be at the very least
260Mb/s as thats what the controller has been measured on
linux at even through the FS.
Um... not quite. That was the number you listed for S/W RAID5. In that
case you're not benchmarking the contr
On 5/2/2005 3:43 PM, Steven Hartland wrote:
- Original Message - From: "Poul-Henning Kamp" <[EMAIL PROTECTED]>
To eliminate various parts of the subsystems I've just tested:
dd if=/dev/da0 of=/dev/null bs=64k count=10
Read: 220Mb/s
This is a very interesting number to measure, you'll ne
- Original Message -
From: "Robert Watson" <[EMAIL PROTECTED]>
I'm not sure if we've seen Linux and FreeBSD dmsg output yet, but
if nothing else it would be good to confirm if the drivers on both systems
negotiate the same level of throughput to each drive.
Both drivers ( FreeBSD and Li
In message <[EMAIL PROTECTED]>, Sten Spans w
rites:
>>> What about disk arrays that support RAID3?
>>
>> Would work for me, but most of them are dumbed down when they do RAID3:
>> they have to hard format the disks to 128 byte sector sizes and similar
>> madness in order to support 512 bytes secto
At 10:54 5/2/2005, Sten Daniel Sørsdal wrote:
Mike Tancsa wrote:
> A somewhat obvious question to some perhaps, but what server application
> mix on FreeBSD today sees an improvement using 64bit CPUs ? In my ISP
> centric world, my big apps are BIND, IMAP/POP3, httpd via apache, SMTP,
> AV and SPA
Mike Tancsa wrote:
> A somewhat obvious question to some perhaps, but what server application
> mix on FreeBSD today sees an improvement using 64bit CPUs ? In my ISP
> centric world, my big apps are BIND, IMAP/POP3, httpd via apache, SMTP,
> AV and SPAM scanning, and firewalls/routing. Apart from
On Mon, 2 May 2005, Poul-Henning Kamp wrote:
In message <[EMAIL PROTECTED]>, Eric Anderson writes:
In message <[EMAIL PROTECTED]>, Allen writes:
I just want to add: This is why I really would love for us to have
a real RAID3 implemetation.
RAID3 is not commercially viable because windows cannot us
On Mon, 2 May 2005, Poul-Henning Kamp wrote:
I'm quite willing to test and optimise things but so far no one has
had any concrete suggestions on that to try.
First thing I heard about this was a few hours ago. (Admittedly, my
email has been in a sucky state last week, so that is probably my own
- Original Message -
From: "Poul-Henning Kamp" <[EMAIL PROTECTED]>
0. Does the user know enough about what he is doing.
Im no expert but then again Im not beginner either :)
1. Write performance being nearly 3x that of read performance
2. Read performance only equalling that of single disk
In message <[EMAIL PROTECTED]>, "Steven Hartland"
writes:
>> As such that is a fair end-user benchmark, but unfortunately it
>> doesn't really tell us anything useful for the purpose of this
>> discussion.
>
>Yes but the end-user performance is really the only thing that matters.
>There are two
- Original Message -
From: "Poul-Henning Kamp" <[EMAIL PROTECTED]>
Ok from what your saying it sounds like RAID on FreeBSD is useless
apart to create large disks. Now to the damaging facts the results
from my two days worth of testing:
Now, cool down a moment and lets talk about what you
It may make sense to look at measured bandwidth as a
percentage of *guaranteed not to exceed* bandwidth of the
disk setup -- what is the theoretical max bandwidth writing
to a raw partition (and assuming zero cpu overhead, latency,
seek time)? This will help in figuring out how to maximize
end-to-
In message <[EMAIL PROTECTED]>, "Steven Hartland"
writes:
>Ok from what your saying it sounds like RAID on FreeBSD is useless
>apart to create large disks. Now to the damaging facts the results
>from my two days worth of testing:
Now, cool down a moment and lets talk about what you _really_ have
Poul-Henning Kamp wrote:
In message <[EMAIL PROTECTED]>, Petri Helenius writes:
My tests were using RAID10 and just striping. (RAID0 might be the right
name for it)
Same thing applies, and it depends on how the reqeust alignment/size and
stripe alignment/size interacts.
I'm using either
- Original Message -
From: "Poul-Henning Kamp" <[EMAIL PROTECTED]>
Interesting stuff so:
1. How to we test if this is happening?
Calculate by hand what the offset of the striped/raid part of the disk
is (ie: take slice+partition stats into account).
How's that done? An explained example w
At 10:38 5/2/2005, Arne "Wörner" wrote:
--- Allen <[EMAIL PROTECTED]> wrote:
> Scenario B, verified read enabled:
> 1. RAID card reads up ALL blocks in the stripe (5 reads).
> 2. RAID card pretends the block requested is on a "degraded"
> drive, and
> calculates it from the other 3 + the XOR stripe
--- Allen <[EMAIL PROTECTED]> wrote:
> Scenario B, verified read enabled:
> 1. RAID card reads up ALL blocks in the stripe (5 reads).
> 2. RAID card pretends the block requested is on a "degraded"
> drive, and
> calculates it from the other 3 + the XOR stripe.
> 3. RAID card reports the value back
In message <[EMAIL PROTECTED]>, Eric Anderson writes:
>> In message <[EMAIL PROTECTED]>, Allen writes:
>>
>> I just want to add: This is why I really would love for us to have
>> a real RAID3 implemetation.
>>
>> RAID3 is not commercially viable because windows cannot use non-512
>> byte sectors
At 10:14 5/2/2005, Arne "Wörner" wrote:
--- Allen <[EMAIL PROTECTED]> wrote:
> Also you should keep in mind, there could simply be some really
> goofy
> controller option enabled, that forces the RAID5 to behave in a
> "degraded"
> state for reads -- forcing it to read up all the other disks in
> t
Poul-Henning Kamp wrote:
In message <[EMAIL PROTECTED]>, Allen writes:
I just want to add: This is why I really would love for us to have
a real RAID3 implemetation.
RAID3 is not commercially viable because windows cannot use non-512
byte sectors.
We can.
RAID3 would scream for us.
What about disk
In message <[EMAIL PROTECTED]>, Allen writes:
I just want to add: This is why I really would love for us to have
a real RAID3 implemetation.
RAID3 is not commercially viable because windows cannot use non-512
byte sectors.
We can.
RAID3 would scream for us.
--
Poul-Henning Kamp | UNIX
> "Mike" == Mike Tancsa <[EMAIL PROTECTED]> writes:
Mike> Thanks! I was worried I was missing something obvious in all
Mike> the 64bit excitement. For my apps where I cant balance across
Mike> multiple machines or where space is an issue, dual core CPUs I
Mike> think might be more interestin
--- Allen <[EMAIL PROTECTED]> wrote:
> Also you should keep in mind, there could simply be some really
> goofy
> controller option enabled, that forces the RAID5 to behave in a
> "degraded"
> state for reads -- forcing it to read up all the other disks in
> the stripe
> and calculate the XOR aga
--- Eric Anderson <[EMAIL PROTECTED]> wrote:
> Arne Wörner wrote:
> > --- Robert Watson <[EMAIL PROTECTED]> wrote:
> >>On Sat, 30 Apr 2005, Arne Wörner wrote:
> >>
> >>>3. The man page geom(4) of R5.3 says "The GEOM framework
> >>> provides an infrastructure in which "classes" can per-
> >>> form
In message <[EMAIL PROTECTED]>, Eric Anderson writes:
>If I write a 10GB file to disk (RAID array has 1GB cache, system has 1GB
>memory), then I should definitely see better read performance reading
>that same file back to /dev/null than writing it, right?
Nope, quite the contrary: you will get
>Interesting stuff so:
>1. How to we test if this is happening?
Calculate by hand what the offset of the striped/raid part of the disk
is (ie: take slice+partition stats into account).
>2. How do we prevent it from happening?
Make sure that the first sector of a partition/slice is always the f
At 09:28 5/2/2005, Steven Hartland wrote:
- Original Message - From: "Poul-Henning Kamp" <[EMAIL PROTECTED]>
Wouldn't this be a problem for writes then too?
I presume you would only compare read to write performance on a RAID5
device which has battery backed cache.
Without a battery backed
In message <[EMAIL PROTECTED]>, Petri Helenius writes:
>>
>My tests were using RAID10 and just striping. (RAID0 might be the right
>name for it)
Same thing applies, and it depends on how the reqeust alignment/size and
stripe alignment/size interacts.
--
Poul-Henning Kamp | UNIX since Zil
- Original Message -
From: "Poul-Henning Kamp" <[EMAIL PROTECTED]>
Wouldn't this be a problem for writes then too?
I presume you would only compare read to write performance on a RAID5
device which has battery backed cache.
Without a battery backed cache (or pretending to have one) RAID5
w
Poul-Henning Kamp wrote:
In message <[EMAIL PROTECTED]>, Eric Anderson writes:
Poul-Henning Kamp wrote:
In message <[EMAIL PROTECTED]>, Eric Anderson writes:
Don't mean to be terse here, but I'm talking about the same test done an
two different RAID5 configurations, with different disks, and not
--- Poul-Henning Kamp <[EMAIL PROTECTED]> wrote:
> Uhm, if you are using RAID5 and your requests are not aligned
> and sized after the RAID5 you should *expect* read performance
> to be poor.
>
Wouldn't that affect both (read and write) in the same way?
> If the disk has bad sectors or other hardw
- Original Message -
From: "Poul-Henning Kamp" <[EMAIL PROTECTED]>
Don't mean to be terse here, but I'm talking about the same test done an
two different RAID5 configurations, with different disks, and not just
me - other users in this very thread see the same issue..
Uhm, if you are usi
Poul-Henning Kamp wrote:
In message <[EMAIL PROTECTED]>, Eric Anderson writes:
I'll be honest here, I don't care much if the speed difference between
4.X and 5.X is measureable, or whatever. What I find is a little
telling of an issue somewhere, is that READS are slower than WRITES!
This is
In message <[EMAIL PROTECTED]>, Eric Anderson writes:
>Poul-Henning Kamp wrote:
>> In message <[EMAIL PROTECTED]>, Eric Anderson writes:
>>
>>
>>>Don't mean to be terse here, but I'm talking about the same test done an
>>>two different RAID5 configurations, with different disks, and not just
>>
Poul-Henning Kamp wrote:
In message <[EMAIL PROTECTED]>, Eric Anderson writes:
Don't mean to be terse here, but I'm talking about the same test done an
two different RAID5 configurations, with different disks, and not just
me - other users in this very thread see the same issue..
Uhm, if
kama wrote:
dev-null is not the issue... my own written testprogram that only read up
data to a buffer in memory showed the same results as doing a dd to
dev-null.
And dd from zero to null does:
114541264896 bytes transferred in 27.716454 secs (4132608911 bytes/sec)
Pete
/Bjorn
__
Poul-Henning Kamp wrote:
In message <[EMAIL PROTECTED]>, Eric Anderson writes:
Don't mean to be terse here, but I'm talking about the same test done an
two different RAID5 configurations, with different disks, and not just
me - other users in this very thread see the same issue..
Uhm, if you ar
In message <[EMAIL PROTECTED]>, Eric Anderson writes:
>Don't mean to be terse here, but I'm talking about the same test done an
>two different RAID5 configurations, with different disks, and not just
>me - other users in this very thread see the same issue..
Uhm, if you are using RAID5 and your
Poul-Henning Kamp wrote:
In message <[EMAIL PROTECTED]>, Eric Anderson writes:
I'll be honest here, I don't care much if the speed difference between
4.X and 5.X is measureable, or whatever. What I find is a little
telling of an issue somewhere, is that READS are slower than WRITES!
This is tot
Its highly unlikely that the 4 people on different hardware that have tested
this all have disks with bad sectors.
I've just finished doing a full battery of tests across:
FreeBSD: 4.11-RELEASE, 5.4-STABLE, 6.0-CURRENT, Suse 9.1
I'll post the results soon but suffice to say the results for FreeBSD
In message <[EMAIL PROTECTED]>, Eric Anderson writes:
>
>I'll be honest here, I don't care much if the speed difference between
>4.X and 5.X is measureable, or whatever. What I find is a little
>telling of an issue somewhere, is that READS are slower than WRITES!
>This is totally bogus to me -
On Mon, 2 May 2005, Eric Anderson wrote:
> I'll be honest here, I don't care much if the speed difference between
> 4.X and 5.X is measureable, or whatever. What I find is a little
> telling of an issue somewhere, is that READS are slower than WRITES!
> This is totally bogus to me - dd'ing a fi
Mariusz Grad wrote:
Mike Tancsa:
A somewhat obvious question to some perhaps, but what server application
mix on FreeBSD today sees an improvement using 64bit CPUs ? In my ISP
centric world, my big apps are BIND, IMAP/POP3, httpd via apache, SMTP, AV
and SPAM scanning, and firewalls/routing. A
Now that the UMA changes to use critical sections instead of per-cpu mutexes
for per-cpu caches are merged, I'd like to move on to the next piece of the
memory allocation patch previous posted. The attached patch does a couple of
things:
- Introduce per-cpu malloc type statistics, protecting t
Arne Wörner wrote:
--- Robert Watson <[EMAIL PROTECTED]> wrote:
On Sat, 30 Apr 2005, Arne WXrner wrote:
3. The man page geom(4) of R5.3 says "The GEOM framework
provides an infrastructure in which "classes" can per-
form transformations on disk I/O requests on their path
from the upper kernel to
Mike Tancsa:
> A somewhat obvious question to some perhaps, but what server application
> mix on FreeBSD today sees an improvement using 64bit CPUs ? In my ISP
> centric world, my big apps are BIND, IMAP/POP3, httpd via apache, SMTP, AV
> and SPAM scanning, and firewalls/routing. Apart from la
55 matches
Mail list logo
