XEON gets a new cable which should improve disk speed

XEON gets a new cable which should improve disk speed

You might recall how I installed a different SCSI adapter and went from a
13 minute kernel build to a 9 minute kernel build.  That’s the The XEON lives! article.   Shortly after posting that
article, I received a message from a reader suggesting that I try an LVD cable.  That
should boost the disk speed.

I borrowed an LVD cable from the same person (llearch) that
had loaned me the cable I was already using.   That boosted the disks from this:

da1: 40.000MB/s transfers (20.000MHz, offset 31, 16bit), 
                                Tagged Queueing Enabled

to this:

da0: 80.000MB/s transfers (40.000MHz, offset 31, 16bit),
                                Tagged Queueing Enabled

So I order the cable from CablesDirect (http://www.cablesdirect.co.nz/).
  I placed the order on Friday, expecting the goods to turn up the next business day
(Wednesday).  I was quite surprised, and of mixed feelings, when the courier knocked
on the door Saturday morning at 7:30 AM.

When I initially tried the cable, I was disappointed to see 40/20 and not 80/40 as I
expected.  After some testing, I concluded it was because one of the drives was
terminated (via a jumper on the drive).  I removed that and reconnected everything.
  The drives then ran at 80/40.

kernel building changes

After doing that, I expected a change in kernel building speed.  I
saw none.  It was exactly the same time (9 minutes, I wasn’t counting the seconds).

Someone
mentioned that kernel building is mostly CPU bound.  So they suggested a test.  
I tried this one:

[dan@xeon:~] $ dd if=/dev/zero of=~/dead.file bs=1024k count=1000
1000+0 records in
1000+0 records out
1048576000 bytes transferred in 50.741196 secs (20665181 bytes/sec)

That’s 20MB per second.

Then I swapped back to the old cable and tried that.  I got

1048576000 bytes transferred in 53.954358 secs (19434501 bytes/sec)
10485760000 bytes transferred in 553.498003 secs (18944531 bytes/sec)

What?  The same speed?  Hmm.  Then I looked at dmesg and found that both
drives were at 80/40.  Under the old cable?

Of course!  The drive termination.  It’s changed. I removed it.  That’s
why the old non-LVD cable ran at 40/20. Just like the LVD cable first did.

Well, I needed to buy a cable anyway.  The one I had was borrowed and needed to be
returned.  I just wish I’d know this before.  I would have bought a slight
cheaper one.  I think the LVD was overkill.

Fast roads, slow cars

As a sharp eyed reader said:  having a road built to handle cars
traveling 200mph doesn’t matter if YOUR car is only capable of traveling 100mph.

My disks
are rated at 29.4MB/second.  That explains why the faster cable didn’t make any
difference.  But it may make a difference if I’m using both drives very heavily.

Steve Wingate <steve@gte.net>

I decided I better elaborate, in case you use this info to update the article.  
That 80MB/s cable allows the SCSI chain to reach a TOTAL bandwdith, or transfer rate, of
80MB/s.  Example, you have two SCSI disks…let’s assume each disk is capable of
transferring 25MB/s.  If you were to transfer data on both disks simultaneously they
could combine to reach a transfer rate of 50MB/s.  If you had three similiar disks
they could combine for a top rate of 75MB/s. If you were to have those two (or three)
disks on the 40MB/s cable for a RAID set for example, you’d be limited to a top rate of
40MB/s, since the cable becomes the bottleneck.  In THAT case the 80MB/s cable DOES
help you, because the three disks combining to reach a theoretical 75MB/s is still less
than the 80MB/s the cable is capable of.  So, two disks capable of transferring
20MB/s will do fine on a 40MB/s cable.  Two disks capable of 30MB/s each (combining
to reach 60MB/s exceed the 40MB/s cable and therefore require one of two things.  An
80MB/s U2 cable as you have bought OR a dual channel SCSI card with each drive on it’s own
channel.  That way each drive individually would have it’s own cable allowing it to
use the full 40MB/s bandwidth for itself.   This is where dual channel SCSI cards
come into play.

I fully realize this is an abbreviated description of the issue, but it’ll suffice for
a laymen’s terms explanation.

Leave a Comment

Scroll to Top