On Thu, Nov 27, 2014 at 07:37:48PM +0100, David Unric wrote:
Thanks for the quick answer !
Just following up on this.
I repeated your unpack experiment on my machine and I got a time of 0m47s,
and my fs is going through softraid crypto. I repeated on a different machine
and the time was 0m40s,
Hello,
I'd like to figure out what causes very low performance of disk operations
on my laptop.
I've tested it by unpacking gzipped tar archive (
http://ftp.heanet.ie/pub/OpenBSD/5.6/src.tar.gz) about 125 MiB big.
On the same machine, not cached, various results by operating system:
NetBSD
On 11/27/14 10:57, David Unric wrote:
Hello,
I'd like to figure out what causes very low performance of disk operations
on my laptop.
I've tested it by unpacking gzipped tar archive (
http://ftp.heanet.ie/pub/OpenBSD/5.6/src.tar.gz) about 125 MiB big.
On the same machine, not cached, various
Bellow are relevant rows of dmesg output:
snip
--
OpenBSD 5.6 (GENERIC.MP) #333: Fri Aug 8 00:20:21 MDT 2014
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
mpath0 at root
scsibus0 at mpath0:
On Thu, Nov 27, 2014 at 06:04:46PM +0100, David Unric wrote:
Bellow are relevant rows of dmesg output:
And here is the relevant part of a solution:
What do you think? Helpful, huh?
Next time please provide a complete dmesg. There is a reason he didn't
ask you to parse it yourself. There
Here is a full dmesg output if you think it would help:
OpenBSD 5.6 (GENERIC.MP) #333: Fri Aug 8 00:20:21 MDT 2014
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 6333923328 (6040MB)
avail mem = 6156533760 (5871MB)
mpath0 at root
scsibus0 at mpath0: 256
On Thu, Nov 27, 2014 at 06:41:17PM +0100, David Unric wrote:
Here is a full dmesg output if you think it would help:
Next steps I would try.
1. If you really wanted to verify this is a wd vs sd issue, you can usually
change the SATA controller mode in the BIOS to IDE instead of AHCI. As long
as
The obvious issue is that the computer lacks a CPU. Given that, I'd say those
numbers are pretty impressive.
/Alexander
On November 27, 2014 6:27:08 PM CET, Mike Larkin mlar...@azathoth.net wrote:
On Thu, Nov 27, 2014 at 06:04:46PM +0100, David Unric wrote:
Bellow are relevant rows of dmesg
Thanks for the quick answer !
ad 1) disabled AHCI in BIOS as the only available option
OpenBSD now boots with hdd attached as wd0 device, UDMA mode 6 and
it did a significant improvement - unpacking finishes in about 6 minutes,
but still magnitude worse then in NetBSD.
ad 2) Not slowed
On 27.11.2014 19:37, David Unric wrote:
Thanks for the quick answer !
ad 1) disabled AHCI in BIOS as the only available option
OpenBSD now boots with hdd attached as wd0 device, UDMA mode
6 and
it did a significant improvement - unpacking finishes in about 6
minutes,
but still
There are a few ideas that come to mind, here, roughly in order of
postings, are some suggested lines of investigation:
I ran the default bonnie++ test suite on a single disk (no RAID) then
again on a two-disk RAID0 for each
Were the RAID0 sets stable, that is, the raid controller reported
On 12/17/2013 05:05 PM, Adam Jensen wrote:
If this performance difference is simply due to OpenBSD's architecture
and implementation methods - if it's a well engineered file-system - and
maximum performance was a lower priority goal than robustness and
reliability, then the lower performance
Adam Jensen [han...@riseup.net] wrote:
In an attempt to understand the problem, I ran a similar set of tests on an
i386 machine. While the file-system characteristics of OpenBSD and FreeBSD
are different, I can comfortably assume that, in this case (i386), they are
both utilizing the
On 12/18/2013 07:38 PM, Chris Cappuccio wrote:
What if you try larger block sizes? like bs=1m ?
Do you mean bs=1m for the dd tests rather than anything concerning the
file-system (newfs) or RAID configuration?
{if dd} It would take some time to get precise data along those lines (I
On 12/11/2013 10:27 AM, Jan Lambertz wrote:
I found dd to be a very bad/misleading tool for this case.
Problems are caches in different layers of the system, filesystem
behaviour, sector sizing of drives and arrays, kernel configurations, input
data loading, real world scenarios and driver
I found dd to be a very bad/misleading tool for this case.
Problems are caches in different layers of the system, filesystem
behaviour, sector sizing of drives and arrays, kernel configurations, input
data loading, real world scenarios and driver implementation.
I had same issues on centos.
Not
On 12/11/2013 10:27 AM, Jan Lambertz wrote:
I found dd to be a very bad/misleading tool for this case.
Problems are caches in different layers of the system, filesystem
behaviour, sector sizing of drives and arrays, kernel configurations, input
data loading, real world scenarios and driver
On 12/09/2013 08:51 PM, Steve Shockley wrote:
On 12/9/2013 7:24 PM, Adam Jensen wrote:
Disk performance is *very* bad. For example:
Shot in the dark, but maybe try upgrading the 6404 firmware from 2.34 to
2.84, there are a variety of fixes that possibly could have been worked
around by the
This might not be terribly relevant but just in case, for posterity, the
ML370 G4 system messages (dmesg) with both versions of the Smart Array
6404 firmware are here:
OpenBSD5.4-amd64
[v2.34]: http://pastebin.com/Sxs801ef
[v2.84]: http://pastebin.com/RGUJ5pcS
FreeBSD9.2-amd64
[v2.34]:
I recently (last night) installed OpenBSD-5.4-amd64 on an HP-Proliant
ML370-G4 that has a Smart Array 6404 controller card in a 64-bit,
133-MHz PCI-X slot. It has two Ultra320 SCSI channels and 192MB of RAM
cache. One SCSI channel is connected to two 146GB U320 10kRPM drives
which are
On 12/9/2013 7:24 PM, Adam Jensen wrote:
Disk performance is *very* bad. For example:
Shot in the dark, but maybe try upgrading the 6404 firmware from 2.34 to
2.84, there are a variety of fixes that possibly could have been worked
around by the other OS' drivers.
21 matches
Mail list logo
