RE: 2.6.10-rc4 tape slow after switch Fusion MPT to Megaraid
On Wed, 2005-03-02 at 13:21 -0500, Ju, Seokmann wrote: > On Wednesday, March 02, 2005 6:42 AM, Gerhard wrote: > > It's a megaraid issue (not a tape issue..) > > We are looking at this issue and will post here for details. > What version of megaraid driver and which megaraid controller are you using? > > Thanks, > > Seokmann > LSI Logic Corporation. > A very stupid question to everybody.. Could it be that it's not a tape issue but a scheduler issue? It seems that when using tar on a 2.4 kernel tar is getting much more CPU time. Either the scheduler is much better or it's slowing down tape I/O.. Is the combination of different disk and tape drivers able to trigger different IO Scheduler problems? GS -- Gerhard Schneider Institute of Lightweight Design and e-Mail:[EMAIL PROTECTED] Structural Biomechanics (E317) Tel.: +43 1 58801 31716 Vienna University of Technology / AustriaFax:+43 1 58801 31799 A-1040 Wien, Gusshausstrasse 27-29http://www.ilsb.tuwien.ac.at/~gs/ signature.asc Description: This is a digitally signed message part
RE: 2.6.10-rc4 tape slow after switch Fusion MPT to Megaraid
On Wednesday, March 02, 2005 6:42 AM, Gerhard wrote: > It's a megaraid issue (not a tape issue..) We are looking at this issue and will post here for details. What version of megaraid driver and which megaraid controller are you using? Thanks, Seokmann LSI Logic Corporation. - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: 2.6.10-rc4 tape slow after switch Fusion MPT to Megaraid
On Wed, 2005-03-02 at 10:49 -0500, Guy wrote: > You did: > dd if=/dev/zero of=/dev/nst0 bs=1M and different mt setblk > > Since tape drives can compress data, /dev/zero is a bad source of data, > since it compresses real good. /dev/urandom is a better source. > > You would like IBM's LTO-2 tape drive. It does 35M/s! They claim the LTO-3 > does 70M/s! > > Guy > I did want the tape to do NOTHING. It's a test of the SCSI transfer speed, handshake etc. When compression is on the tape has to write file marks and very little information. So you get the real transfer performance. Not the performance of the tape. GS -- Gerhard Schneider Institute of Lightweight Design and e-Mail:[EMAIL PROTECTED] Structural Biomechanics (E317) Tel.: +43 1 58801 31716 Vienna University of Technology / AustriaFax:+43 1 58801 31799 A-1040 Wien, Gusshausstrasse 27-29http://www.ilsb.tuwien.ac.at/~gs/ signature.asc Description: This is a digitally signed message part
RE: 2.6.10-rc4 tape slow after switch Fusion MPT to Megaraid
You did: dd if=/dev/zero of=/dev/nst0 bs=1M and different mt setblk Since tape drives can compress data, /dev/zero is a bad source of data, since it compresses real good. /dev/urandom is a better source. You would like IBM's LTO-2 tape drive. It does 35M/s! They claim the LTO-3 does 70M/s! Guy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gerhard Schneider Sent: Wednesday, March 02, 2005 5:30 AM To: Kai Makisara Cc: scsi Subject: Re: 2.6.10-rc4 tape slow after switch Fusion MPT to Megaraid On Sun, 2005-02-27 at 22:46 +0200, Kai Makisara wrote: > > This shows that your application is not using very large block size (3 > pages, 10 kB?). You might get better throughput with larger block size (32 > kB or 64 kB is usually large enough). If the Megaraid command processing > speed is not fast enough, this might explain the problem (not probable but > I can't see any probable problems ;-) > After different tries (I had problems w/ my backup schedule - ever tried to back up 600 GB with 2.6MB/s? :-) Tape block sizes between 10k and a few MB don't make any difference For better understanding I did the tests with dd if=/dev/zero of=/dev/nst0 bs=1M and different mt setblk No chance to go above 2.6 MB/s Gerhard Schneider -- Gerhard Schneider Institute of Lightweight Design and e-Mail:[EMAIL PROTECTED] Structural Biomechanics (E317) Tel.: +43 1 58801 31716 Vienna University of Technology / AustriaFax:+43 1 58801 31799 A-1040 Wien, Gusshausstrasse 27-29http://www.ilsb.tuwien.ac.at/~gs/ - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.10-rc4 tape slow after switch Fusion MPT to Megaraid
On Wed, 2005-03-02 at 11:30 +0100, Gerhard Schneider wrote: > On Sun, 2005-02-27 at 22:46 +0200, Kai Makisara wrote: > > > > > This shows that your application is not using very large block size (3 > > pages, 10 kB?). You might get better throughput with larger block size (32 > > kB or 64 kB is usually large enough). If the Megaraid command processing > > speed is not fast enough, this might explain the problem (not probable but > > I can't see any probable problems ;-) > > > > After different tries (I had problems w/ my backup schedule - ever tried > to back up 600 GB with 2.6MB/s? :-) > > Tape block sizes between 10k and a few MB don't make any difference > > For better understanding I did the tests with > > dd if=/dev/zero of=/dev/nst0 bs=1M and different mt setblk > > No chance to go above 2.6 MB/s > Moved the tape drive to another machine w/Fusion chipset, but w/o Megaraid controller. Absolutely the same software. dd if=/dev/zero of=/dev/nst0 bs=1M count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 24.597061 seconds (42630134 bytes/sec) That's the transfer rate the tape drive is able when receiving bullshit (/dev/zero). It's a megaraid issue (not a tape issue..) GS changing all backup scripts to the new machine -- Gerhard Schneider Institute of Lightweight Design and e-Mail:[EMAIL PROTECTED] Structural Biomechanics (E317) Tel.: +43 1 58801 31716 Vienna University of Technology / AustriaFax:+43 1 58801 31799 A-1040 Wien, Gusshausstrasse 27-29http://www.ilsb.tuwien.ac.at/~gs/ signature.asc Description: This is a digitally signed message part
Re: 2.6.10-rc4 tape slow after switch Fusion MPT to Megaraid
On Sun, 2005-02-27 at 22:46 +0200, Kai Makisara wrote: > > This shows that your application is not using very large block size (3 > pages, 10 kB?). You might get better throughput with larger block size (32 > kB or 64 kB is usually large enough). If the Megaraid command processing > speed is not fast enough, this might explain the problem (not probable but > I can't see any probable problems ;-) > After different tries (I had problems w/ my backup schedule - ever tried to back up 600 GB with 2.6MB/s? :-) Tape block sizes between 10k and a few MB don't make any difference For better understanding I did the tests with dd if=/dev/zero of=/dev/nst0 bs=1M and different mt setblk No chance to go above 2.6 MB/s Gerhard Schneider -- Gerhard Schneider Institute of Lightweight Design and e-Mail:[EMAIL PROTECTED] Structural Biomechanics (E317) Tel.: +43 1 58801 31716 Vienna University of Technology / AustriaFax:+43 1 58801 31799 A-1040 Wien, Gusshausstrasse 27-29http://www.ilsb.tuwien.ac.at/~gs/ signature.asc Description: This is a digitally signed message part
Re: 2.6.10-rc4 tape slow after switch Fusion MPT to Megaraid
On Fri, 25 Feb 2005, Gerhard Schneider wrote: > On Thu, 2005-02-24 at 23:00 +0200, Kai Makisara wrote: > > > > > > Sounds strange but the following things come into my mind: > > - Check from the dmesg output and/or system logs what SCSI transfer > > settings the tape drive and the SCSI adapter negotiate. The speed should > > not change when you add the Megaraid controller. If you don't find the > > value before adding it, you can check that the current value is at least > > 40 MB/s (probably more). > Not so easy. The megaraid driver doesn't tell you that > I hope Seokmann can give you some information about this. ... > > - Enable debugging in the st driver (change DEBUG to 1 in st.c, recompile, > > reload the module). In the normal case st should not print many debugging > > message (some when the device is opened at some when it is closed). > > Now the full story: > > st: Version 20050213, fixed bufsize 32768, s/g segs 256 > Attached scsi tape st0 at scsi0, channel 0, id 6, lun 0 normal output cut > st0: Number of r/w requests 127685, dio used in 127685, pages 383055 This shows that your application is not using very large block size (3 pages, 10 kB?). You might get better throughput with larger block size (32 kB or 64 kB is usually large enough). If the Megaraid command processing speed is not fast enough, this might explain the problem (not probable but I can't see any probable problems ;-) The messages look OK. There is nothing that should not be there. -- Kai - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.10-rc4 tape slow after switch Fusion MPT to Megaraid
On Thu, 2005-02-24 at 23:00 +0200, Kai Makisara wrote: > > > Sounds strange but the following things come into my mind: > - Check from the dmesg output and/or system logs what SCSI transfer > settings the tape drive and the SCSI adapter negotiate. The speed should > not change when you add the Megaraid controller. If you don't find the > value before adding it, you can check that the current value is at least > 40 MB/s (probably more). Not so easy. The megaraid driver doesn't tell you that cat /sys/bus/scsi/devices/0:0:6:0/scsi_level 4 (to be SCSI_3 in scsi.h) > - Enable debugging in the st driver (change DEBUG to 1 in st.c, recompile, > reload the module). In the normal case st should not print many debugging > message (some when the device is opened at some when it is closed). Now the full story: st: Version 20050213, fixed bufsize 32768, s/g segs 256 Attached scsi tape st0 at scsi0, channel 0, id 6, lun 0 st0: try direct i/o: yes (alignment 512 B), max page reachable by HBA 4294967295 program stinit is using a deprecated SCSI ioctl, please convert it to SG_IO st0: Block limits 1 - 16777215 bytes. st: Unloaded. st: Version 20050213, fixed bufsize 32768, s/g segs 256 Attached scsi tape st0 at scsi0, channel 0, id 6, lun 0 st0: try direct i/o: yes (alignment 512 B), max page reachable by HBA 4294967295 st0: Block limits 1 - 16777215 bytes. st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8 st0: Density 0, tape length: 0, drv buffer: 1 st0: Block size: 0, buffer size: 4096 (1 blocks). program stinit is using a deprecated SCSI ioctl, please convert it to SG_IO st0: Block limits 1 - 16777215 bytes. st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8 st0: Density 0, tape length: 0, drv buffer: 1 st0: Block size: 0, buffer size: 4096 (1 blocks). st0: Drive buffer default set to 1 st0: Setting drive buffer code to 1. st0: Mode 0 options: buffer writes: 1, async writes: 1, read ahead: 1 st0:can bsr: 1, two FMs: 0, fast mteom: 0, auto lock: 1, st0:defs for wr: 0, no block limits: 0, partitions: 0, s2 log: 1 st0:sysv: 0 nowait: 0 st0:debugging: 1 st0: Default block size set to 0 bytes. st0: Density default set to 0 st0: Block limits 1 - 16777215 bytes. st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8 st0: Density 0, tape length: 0, drv buffer: 1 st0: Block size: 0, buffer size: 4096 (1 blocks). st0: Block limits 1 - 16777215 bytes. st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8 st0: Density 0, tape length: 0, drv buffer: 1 st0: Block size: 0, buffer size: 4096 (1 blocks). st0: Rewinding tape. st0: Block limits 1 - 16777215 bytes. st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8 st0: Density 0, tape length: 0, drv buffer: 1 st0: Block size: 0, buffer size: 4096 (1 blocks). st0: Block limits 1 - 16777215 bytes. st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8 st0: Density 0, tape length: 0, drv buffer: 1 st0: Block size: 0, buffer size: 4096 (1 blocks). st0: Locking drive door. st0: Number of r/w requests 127685, dio used in 127685, pages 383055 (0). st0: File length 0 bytes. st0: Async write waits 0, finished 0. st0: Buffer flushed, 1 EOF(s) written st0: Unlocking drive door. > - Back out the tape patches and see if that improves the situation (these > patches should not have any effect on speed and they did not in my tests > but changes may contain bugs that show up in other environments ...) > It was BEFORE adding the patches - I tried to incorporate existing patches.. Nothing strange for me.. A question that seems to be for Sekomann : Can there be a hidden Write Policy setting in the megaraid tape driver? For the disks the megaraid adapter is setting Write back per default, not Write thru. The OS (Linux) doesn't know about it. But read performance is not better, so I seem to be wrong.. Gerhard Schneider -- Gerhard Schneider Institute of Lightweight Design and e-Mail:[EMAIL PROTECTED] Structural Biomechanics (E317) Tel.: +43 1 58801 31716 Vienna University of Technology / AustriaFax:+43 1 58801 31799 A-1040 Wien, Gusshausstrasse 27-29http://www.ilsb.tuwien.ac.at/~gs/ signature.asc Description: This is a digitally signed message part
RE: 2.6.10-rc4 tape slow after switch Fusion MPT to Megaraid
On Thu, 2005-02-24 at 16:45 -0500, Ju, Seokmann wrote: > On Wednesday, February 23, 2005 6:45 AM, Gerhard wrote: > > To: linux-scsi@vger.kernel.org > > Subject: 2.6.10-rc4 tape slow after switch Fusion MPT to Megaraid > > > > > > Kernel: 2.6.10-rc4 w/ 3 tape patches from Kai Makisara > I'm not sure, but have you tried without those patches? > > > > > SCSI: 53C1030 controller, tape drive is on one channel of the > > controller. > > > > Tape: Overland Changer w/ Seagate LTO-1 drive > > Typical transfer speed: 12MB/s > > > > After adding a Megaraid Zero Channel Raid Controller to that > > computer the transfer speed of the tape changed to 2.6 MB/s > What is driver version that you are using? > > Thanks, > Seokmann > LSI Logic Corporation. Linux driver: Release Date: Thu Feb 03 12:27:22 EST 2005 - Seokmann Ju <[EMAIL PROTECTED]> Current Version : 2.20.4.5 (scsi module), 2.20.2.5 (cmm module) Megaraid firmware: 1Z37 Both channels limited to Ultra-160 Thank you in advance! Gerhard Schneider -- Gerhard Schneider Institute of Lightweight Design and e-Mail:[EMAIL PROTECTED] Structural Biomechanics (E317) Tel.: +43 1 58801 31716 Vienna University of Technology / AustriaFax:+43 1 58801 31799 A-1040 Wien, Gusshausstrasse 27-29http://www.ilsb.tuwien.ac.at/~gs/ signature.asc Description: This is a digitally signed message part
RE: 2.6.10-rc4 tape slow after switch Fusion MPT to Megaraid
On Wednesday, February 23, 2005 6:45 AM, Gerhard wrote: > To: linux-scsi@vger.kernel.org > Subject: 2.6.10-rc4 tape slow after switch Fusion MPT to Megaraid > > > Kernel: 2.6.10-rc4 w/ 3 tape patches from Kai Makisara I'm not sure, but have you tried without those patches? > > SCSI: 53C1030 controller, tape drive is on one channel of the > controller. > > Tape: Overland Changer w/ Seagate LTO-1 drive > Typical transfer speed: 12MB/s > > After adding a Megaraid Zero Channel Raid Controller to that > computer the transfer speed of the tape changed to 2.6 MB/s What is driver version that you are using? Thanks, Seokmann LSI Logic Corporation. - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.10-rc4 tape slow after switch Fusion MPT to Megaraid
On Wed, 23 Feb 2005, Gerhard Schneider wrote: > > Kernel: 2.6.10-rc4 w/ 3 tape patches from Kai Makisara > > SCSI: 53C1030 controller, tape drive is on one channel of the > controller. > > Tape: Overland Changer w/ Seagate LTO-1 drive > Typical transfer speed: 12MB/s > > After adding a Megaraid Zero Channel Raid Controller to that > computer the transfer speed of the tape changed to 2.6 MB/s > > Disks on the other channel of the 53C1030 are NOT affected > (disk performance OK). > > stinit.def has NOT been changed. > > No error messages. > I didn't find any changable parameters for the Megaraid adapter > for TAPE drives. > > What did I do wrong? How to provide you with additional data? > Sounds strange but the following things come into my mind: - Check from the dmesg output and/or system logs what SCSI transfer settings the tape drive and the SCSI adapter negotiate. The speed should not change when you add the Megaraid controller. If you don't find the value before adding it, you can check that the current value is at least 40 MB/s (probably more). - Enable debugging in the st driver (change DEBUG to 1 in st.c, recompile, reload the module). In the normal case st should not print many debugging message (some when the device is opened at some when it is closed). - Back out the tape patches and see if that improves the situation (these patches should not have any effect on speed and they did not in my tests but changes may contain bugs that show up in other environments ...) -- Kai - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
2.6.10-rc4 tape slow after switch Fusion MPT to Megaraid
Kernel: 2.6.10-rc4 w/ 3 tape patches from Kai Makisara SCSI: 53C1030 controller, tape drive is on one channel of the controller. Tape: Overland Changer w/ Seagate LTO-1 drive Typical transfer speed: 12MB/s After adding a Megaraid Zero Channel Raid Controller to that computer the transfer speed of the tape changed to 2.6 MB/s Disks on the other channel of the 53C1030 are NOT affected (disk performance OK). stinit.def has NOT been changed. No error messages. I didn't find any changable parameters for the Megaraid adapter for TAPE drives. What did I do wrong? How to provide you with additional data? Thank you in advance! Gerhard Schneider -- Gerhard Schneider Institute of Lightweight Design and e-Mail:[EMAIL PROTECTED] Structural Biomechanics (E317) Tel.: +43 1 58801 31716 Vienna University of Technology / AustriaFax:+43 1 58801 31799 A-1040 Wien, Gusshausstrasse 27-29http://www.ilsb.tuwien.ac.at/~gs/ signature.asc Description: This is a digitally signed message part
