That's areca fix is a really interesting fix for us. I applied it to our
rrd graph machine which constantly becomes unresponsive currently under
high IO load for periods at a time.

I can confirm that we also now get Command Queuing Enabled and that
camcontrol tags da0 is reporting more that is expected.
(pass0:arcmsr0:0:0:0): device openings: 255

I cant say for sure if this has helped as our testing is quite
subjective for the most part i.e. does my ssh session stop responding.

I can however say the machine is still locking on a regular basis
apparently due to the IO load as its doing very little else.

Our test here is to run a very simple piece of C:
[code]
#include <stdio.h>
#include <stdlib.h>
#include <time.h>

int main( char **argv, int argc )
{
       time_t last = time( NULL );
       while ( 1 )
       {
               time_t now = time( NULL );
               time_t diff = now - last;
               if ( diff >= 2 )
               {
                       fprintf( stderr, "stalled for %d seconds\n", diff );
               }
               fprintf( stderr, ctime( &now ) );
               last = now;
               sleep ( 1 );
       }
exit( 0 );
}
[/code]

[log]
Wed Mar  4 00:31:36 2009
Wed Mar  4 00:31:37 2009
stalled for 4 seconds
Wed Mar  4 00:31:41 2009
Wed Mar  4 00:31:42 2009
Wed Mar  4 00:31:43 2009
Wed Mar  4 00:31:44 2009
Wed Mar  4 00:31:45 2009
stalled for 5 seconds
Wed Mar  4 00:31:50 2009
Wed Mar  4 00:31:51 2009
stalled for 4 seconds
Wed Mar  4 00:31:55 2009
Wed Mar  4 00:31:56 2009
stalled for 2 seconds
Wed Mar  4 00:31:58 2009
Wed Mar  4 00:31:59 2009
[/log]

As you can see above there a several multi second pauses where above exe
was stalled.

At the points of stall the process using serious IO are bufdaemon and
or syncer.

Anyway off thread, thanks for alot for fix to the areca driver Scott, I'm
sure it will even if it doesnt totally solve our performance issue here.

   Regards
   Steve

----- Original Message ----- From: "Mike Tancsa" <m...@sentex.net>


At 11:56 AM 3/3/2009, Barry Pederson wrote:

I can report a "metoo" on a 7.0-RELEASE-p3 machine with an Areca ARC-1212 card and SATA drives. "camcontrol tags da0" reports:

        (pass0:arcmsr0:0:0:0): device openings: 1

The machine is just a dog sometimes.  Haven't tried the patch though.


RELENG_7 has all the fixes in. There seem to be quite a few cam fixes plus the one areca fix. With the patches, post reboot I now see

da1: Command Queueing Enabled

raw throughput seems to be the same (which is should). It when there are multiple reads/writes that the biggest difference should show up.

---Mike
_______________________________________________
freebsd-curr...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.
In the event of misdirection, illegible or incomplete transmission please 
telephone +44 845 868 1337
or return the E.mail to postmas...@multiplay.co.uk.

_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Reply via email to