Re: Daisy Chain vs. FW 800-to-400 Cable

Nick Naym <nicknaym@[remove_this].gmail.com> wrote:

Well, based on your tutorial, I'd vote for a variation of #2: When FireWire
400 and FireWire 800 devices are mixed on a FireWire 400 bus, all transfer
rates revert to the original FireWire 400 speed; when on a FireWire 800 bus,
all transfer rates *beyond the first FireWire 400 device* revert to the
FireWire 400 speed."

BTW: I set up the Seaquest, and am currently having TM create a backup on it
(it's going *extremely* slow). I did daisy-chain the LaCie off of the
Seaquest, mostly (for now) just to see if it would work. Not surprisingly,
it does.

I'd like to somehow determine what effect, if any, the LaCie has on the TM
backup speed. Based on what you explained, it should have no effect. But
I've been running TM for about an hour now, and less than 2 GB has been
copied. Given that I'm not *actively* doing anything else, I'm wondering if
just the presence of the LaCie is somehow "loading down" the FW bus.
(Although, having just ejected the LaCie a few minutes ago, and not noticing
a change, I guess not.)

You can at least use System Profiler to check that the "Current Speed"
is reported at 800 Mb/sec for the drive in the Icy Cube enclosure.

Time Machine is known to be somewhat sluggish (especially when copying
lots of small files), so I wouldn't put the slow speed down to the
presence of the LaCie.

In any event, I'd still like to get a handle on the speeds, and in your
previous post you stated:

My test consisted of copying a large file from the hard drive (using the
'dd' command line tool and directing output to /dev/null, so it isn't
influenced by the speed of the computer's internal drive). dd reports
the transfer rate, which is a handy way of doing an accurate
measurement.

Since I've yet to delve into OS X's Unix underpinnings, can you explain this
in a way that a non-command-line-tool user might understand? ;)

Benchmarking software would be an easier way to achieve this. I just
didn't have any handy and happen to know how to use 'dd' for some tasks,
so I did that instead. I wouldn't recommend this as the best method, and
it is somewhat complex to describe, but here goes.

To summarise what I did:

I have a existing clone backup on one of my external drives. I had a
look through that to find a file which is at least a few hundred
megabytes (a real single file, not a package or folder). The one I
happened to pick was an old Virtual PC virtual disk image, which was
about 260 MB.

In Terminal, I then used the following sequence to execute the command
to copy the file.

1. Type in the following (don't press return yet)

dd of=/dev/null bs=1m if=

2. Drag the icon for the big file on the external drive into the
Terminal window. This appends the path to the file to the command. In my
case, I had the following:

dd of=/dev/null bs=1m if=/Volumes/DAE\ Backup/Documents/Virtual\
PC/Windows\ 95\ \(260MB\)

The "of" and "if" arguments specify the output file and input file. The
"bs" specifies the block size - this is saying to read the data in
blocks of 1 MB, rather than the default 512 bytes (which would have too
much overhead and not be a reliable test of the peak throughput).

3. Confirm that there is no space after "if=" and before the path. If
there is, navigate back to that point in the command line and edit it to
delete the extra space. The easiest way to do with with most shells is
to press Ctrl-A (which goes back to the start of the line) then use the
right arrow key to get to the correct position, then press the Delete
key to get rid of the space.

4. Press return.

dd will read the file from the external drive, copying it nowhere
(/dev/null is a virtual device which throws away all data written to it,
so it has no impact on I/O throughput compared to copying to another
hard drive). When it finishes, dd shows something like this:

300+1 records in
300+1 records out
315334656 bytes transferred in 5.237962 secs (60201784 bytes/sec)

The figure at the end is the interesting one. If it exceeds about
48000000 bytes/sec then your Firewire bus is running faster than FW400
can possibly achieve. (I've never seen a FW400 bus doing better than
about 45 MB/s.)

You need to wait until the external drive is relatively idle, otherwise
the speed of the transfer will be reduced by other activity going on at
the same time.

It also helps to read a file which is physically located near the start
of the drive, as that portion of the drive has the highest transfer
rate. This could be tricky if you don't know which order files were
copied on there.

I'm sure there are more advanced ways you could run this test without
running into the caching issue or needing a large file, e.g. reading a
large chunk blocks from the start of the partition, ignoring the file
system completely. This will require some extra steps to identify the
appropriate device name, and requires the use of 'sudo' to get root
privileges.

There is one catch with this test: repeating it may produce a
meaningless result, because if you have lots of free memory, Mac OS X
will cache the data when it reads it. This means a repeat of the dd
command will run significantly faster (I got a 1.6 GB/sec transfer
rate).

I found that waiting tens of seconds or ejecting and reconnecting the
drive was sufficient to flush the cache. There is probably a command to
do it quickly but nothing came up from a quick browse.

It is also somewhat tricky to use this method to test the write speed of
a single drive in isolation. You want a source which can supply lots of
data without performance limitations, and write a specified amount of
data to a new file. Ideally the target drive should be mostly empty so
the write can go near the beginning for maximum speed.

As I said, using benchmarking software would be much easier.
--
David Empson
dempson@xxxxxxxxxxxxx
.

Relevant Pages

  • Re: Daisy Chain vs. FW 800-to-400 Cable
    ... 400 and FireWire 800 devices are mixed on a FireWire 400 bus, ... rates revert to the original FireWire 400 speed; when on a FireWire 800 bus, ... I have a existing clone backup on one of my external drives. ... I then used the following sequence to execute the command ...
    (comp.sys.mac.system)
  • Re: Hard drive choice for audio/video
    ... I just heard that drives from Samsung are considered the most silent ... two Firewire devices at once. ... the Firewire 400 and 800 connectors on the Powerbook G4 actually share ... AFAIK, no Mac has more than one FireWire bus, so all connected devices ...
    (comp.sys.mac.hardware.storage)
  • Re: Lacie Mobile Porsche FW HD
    ... It's supposed to be powered by teh FW bus, but I've read of reports that that doesn't work properly. ... I can't comment on that particular drive, but I have a number of supposedly bus-powered Firewire/USB2 drives that I use for work. ... One drive case in particular has a dinky feature of having a USB plug that is used for power only and can be used alongside the Firewire cable so that the drive functions without an external PSU. ...
    (uk.comp.sys.mac)
  • Re: Firewire 800 Daisy Chaining experience?
    ... happens to the bus; will the 400 degrade to 400 for the entire bus? ... chain must have two Firewire ports. ... Firewire devices without problems. ... multiple FW 400 drives or FW 800 drives, ...
    (comp.sys.mac.system)
  • Re: [SLE] Firewire Hard Drive
    ... > I have a problem with my firewire-connected removable hard drives. ... > I haven't been able to figure out how to use the mount command to mount ... After rebooting, open a shell session and type in the command "fdisk -l", ... Firewire) recognised by the operating system. ...
    (SuSE)