Re: Low AAC performance but only when tested through the file system

On Sun 30 Nov 2003 at 15:07:33 -0800, Bill Studenmund wrote:
> What's your stripe depth? For optimal performance, you want it to be 16k.  
> The file system will do 64k i/o's. With 4 data drives & a 16k stripe
> depth, a 64k i/o (on a 64k boundary) will hit all 4 drives at once.

It's the default 64k. In the previous hardware I tried 16k also but it
made no difference, so I never tried it on this one.

> Bill
-Olaf.
--

-- 
___ Olaf 'Rhialto' Seibert - rhialto <at>        -- "What good is a Ring of Power
\X/ polderland.nl            -- if you're unable...to Speak." - Agent Elrond

Re: configuration for PCI-Cardbus bridge

From: KIYOHARA Takashi <kiyohara <at> kk.iij4u.or.jp>
Date: Sun, 30 Nov 2003 01:25:27 +0900 (JST)

> Why doesn't PCI-Cardbus bridge Base address register setup at pciconf.c
> (sys/dev/pci/pciconf.c). A setup PCI-Cardbus base address register is
> omitted although PCI device & PCI-PCI bridge setup at pci_do_device_query().

no reason?

evbppc (OPENBLOCKS266) used pci_configure_bus() & had PCI-Cardbus bridge.
I wrote configuration patch at PCI-Cardbus bridge. I (& OPENBLOCKS266
user) wish to commit this code.

thanks
--
kiyohara

Index: pciconf.c
===================================================================
RCS file: /cvsroot/src/sys/dev/pci/pciconf.c,v
retrieving revision 1.21
diff -c -r1.21 pciconf.c
*** pciconf.c	2003/03/31 21:04:40	1.21
--- pciconf.c	2003/12/01 15:46:38
***************
*** 78,83 ****
--- 78,84 ----

Re: Low AAC performance but only when tested through the file system

I have installed a FreeBSD test installation on part of the disk, and it
seems to suffer the same fate as NetBSD. In systat iostat it also does
not get more than about 60 write xfers/second, and an associated
transfer speed of 4M/sec. So this tends to point to hardware again,
since FreeBSD's AAC driver seems much further developed than NetBSD's.

How that RawIO benchmark managed to get its much better results is still
a mystery to me.

I am more and more thinking in the direction of a partial hardware
failure of the card. Maybe some kind of interrupt that is not coming
through. The card could keep working if another interrupt is generated
that makes it poll the card anyway. Or something like that.

-Olaf.
--

-- 
___ Olaf 'Rhialto' Seibert - rhialto <at>        -- "What good is a Ring of Power
\X/ polderland.nl            -- if you're unable...to Speak." - Agent Elrond

Re: linux emulation not working

In article <20031127182753.GA7228 <at> grouper.salmi.ch>,
Jukka Salmi <jukka-netbsd <at> 2003.salmi.ch> wrote:
>Hi,
>
>Executing a recent runtime linker from Debian on a stable NetBSD
>(1.6.2_RC2) i386 system fails:
>
>$ ktrace /emul/linux/lib/ld-2.3.2.so 
>Bad system call (core dumped)
>$ kdump 
>   720 ktrace   EMUL  "netbsd"
>   720 ktrace   CALL  execve(0xbfbfd7c7,0xbfbfd71c,0xbfbfd724)
>   720 ktrace   NAMI  "/emul/linux/lib/ld-2.3.2.so"
>   720 ld-2.3.2.so EMUL  "svr4"
>[...]
>
>And after removing SVR4 compatibility from the kernel:
>
>$ ktrace /emul/linux/lib/ld-2.3.2.so; kdump 
>Bad system call (core dumped)
>   474 ktrace   EMUL  "netbsd"
>   474 ktrace   CALL  execve(0xbfbfd80a,0xbfbfd754,0xbfbfd75c)
>   474 ktrace   NAMI  "/emul/linux/lib/ld-2.3.2.so"
>   474 ld-2.3.2.so EMUL  "netbsd"
>[...]
>
>What's wrong with Linux emulation?
>
>BTW, executing the linker from pkgsrc/emulators/suse_base works fine...

Can I configure the i386 kernel to allow either serial or video console?

On my alpha, I have the kernel configured to support video if keyboard 
is plugged in, and serial if it is not plugged in.
Can I do the same thing with i386 1.6.1???
tks
bob

Re: Low AAC performance but only when tested through the file system

On Mon, Dec 01, 2003 at 02:50:52AM +0100, Olaf Seibert wrote:
> On Sun 30 Nov 2003 at 15:07:33 -0800, Bill Studenmund wrote:
> > What's your stripe depth? For optimal performance, you want it to be 16k.  
> > The file system will do 64k i/o's. With 4 data drives & a 16k stripe
> > depth, a 64k i/o (on a 64k boundary) will hit all 4 drives at once.
> 
> It's the default 64k. In the previous hardware I tried 16k also but it
> made no difference, so I never tried it on this one.

With a stripe depth of 64k (stripe width of 256k) and 64k i/os you will   
get poor performance. If you are performing random i/o, each of those 64k 
writes means READING 3 * 64k = 192k then writing 128k.

Assuming the stripe depth really is 64k, each write by the OS will turn 
into a read/modify/write operation in the RAID card. You'll be getting 
worse performance than if you just used one drive.

I think you want to try playing with RAID tuning.

Take care,

Bill

Re: pkg/23571: Possible bug in audio drivers - request help with debugging

Andreas Gustafsson [Tue, Nov 25, 2003 at 08:46:36PM -0800]:
> This behavior has always struck me as odd, but I'm not entirely sure
> whether it's a bug or just the correct implementation of a confusing
> and insufficiently documented design.

I've read audio(4) some more, I've read sys/ sources. This is neither a bug,
nor a non-documented feature, it seems standard... but it's quite itchy. How
does Linux deal with full duplex cards?

--

-- 
Michal Pasternak :: http://pasternak.w.lub.pl

Re: Low AAC performance but only when tested through the file system

On Dec 1, 2003, at 8:41 AM, Olaf Seibert wrote:

> I have installed a FreeBSD test installation on part of the disk, and 
> it
> seems to suffer the same fate as NetBSD. In systat iostat it also does
> not get more than about 60 write xfers/second, and an associated
> transfer speed of 4M/sec. So this tends to point to hardware again,
> since FreeBSD's AAC driver seems much further developed than NetBSD's.
>
> How that RawIO benchmark managed to get its much better results is 
> still
> a mystery to me.

What's probably happening is that the RawIO benchmark performs I/O in 
such a way that it is able to make good use of the card's on-board 
stripe cache.  Presumably RawIO is doing large sequential writes, which 
are broken up into 64k chunks, but possibly in a way that the card is 
able to optimize (i.e. hold other stripe chunks in its stripe cache 
until the entire stripe is present and eliminate the r/m/w cycle on the 
disks).

On the other hand, the file system is issuing 64k I/Os, but not 
necessarily all of them adjacent, so the card is probably having a 
harder time optimizing the I/O with the stripe cache.

You could probably get some improvement by tweaking your stripe depth 
on the card.  You really want to be writing an entire stripe at a time, 
so setting your stripe depth to (64k / ndisks-1) for RAID-5 should do 
the trick (64k because that is the maximum I/O size the NetBSD kernel 

How to use FAST-IPSEC and kernfs to avoid PF_KEY problem (modes-to-large SA database)

Dear all, 

  After reading lots of messages in the mailling-list, I still have two problems.

  1. If I install a crypto accelerator in NetBSD-current and want to use FAST-IPSEC, 
      what kind of kernel configuration I should have. I tried one case which comment out
      "options IPSEC" and "options ESP", but uncomment "options FAST_IPSEC". In this case, 
      I can NOT use "setkey -f  XXX" to load SA and SP linto kernel like before, since "setkey -D"
      and "setkey -DP" show  message "sysctl: operation not support". 

      Can anyone tell me how to use FAST-IPSEC ?

 2. I encountered the PF_KEY problem about six month ago. It's really exciting that lots people 
     are trying to figure it out. Sorry that I didn't post this bug immediately.
     Now I hear one solution using kernfs. So, I can use "setkey -f XXX" to load large SAs now?
     just like the way I used in NetBSD-1.5.2 ?

Johnnie Chen

Re: How to use FAST-IPSEC and kernfs to avoid PF_KEY problem (modes-to-large SA database)

On Tuesday 02 December 2003 8:41 am, Johnnie Chen wrote:

>   1. If I install a crypto accelerator in NetBSD-current and want to
> use FAST-IPSEC, what kind of kernel configuration I should have. I
> tried one case which comment out "options IPSEC" and "options ESP",
> but uncomment "options FAST_IPSEC". In this case, I can NOT use
> "setkey -f  XXX" to load SA and SP linto kernel like before, since
> "setkey -D" and "setkey -DP" show  message "sysctl: operation not
> support".

The fast-ipsec code is missing the necessary support needed by those two 
setkey options. I'm about to submit a patch to our fast-ipsec 
maintainers.

If you want a copy of the patch, let me know.

Cheers, Steve