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.