 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Mac Forum / General / General / September 2008Daisy Chain vs. FW 800-to-400 Cable
Hello. I¹ve been using my 750 GB LaCie d2 Quadra (the mechanism is (allegedly) a Samsung HD753) as my Time Machine backup drive. I decided to also buy a 750 GB Seagate 7200.11 along with an Icy Dock enclosure, to use as a ³clone² backup (via SuperDuper! Or Carbon Copy Cloner); it arrived last night. My plan was to use the Seagate as my Time Machine drive once it arrived, and switch the LaCie over to use as my clone drive. My reasoning was that the Icy Dock is strictly a FW 800 enclosure (something I had forgotten when I set up the LaCie), while the LaCie has ports and cables for both FW 800 and 400. So, if I want to continue to run Time Machine backups at FW 800 speeds (which seems preferred, as it¹s backing up hourly) via the LaCie drive, I¹d have to get a FW 800-to-400 cable to connect the Seagate to my iMac, and I¹d rather not do that. On the other hand, were I to use the Seagate with Time Machine, I could run the LaCie at FW 400 speeds, without being too concerned about the speed loss, inasmuch as I¹d be using it to perform clone backups perhaps only once a day. My question then is this: Should I daisy chain the two drives together to run off the iMac¹s single FW 800 port? Or would I be better off reformatting the LaCie for the clone backups, and start all over again with Time Machine, using the Seagate?  SignatureiMac (24", 2.8 GHz Intel Core 2 Duo, 2GB RAM, 320 GB HDD) OS X (10.5.4) > I've been using my 750 GB LaCie d2 Quadra (the mechanism is (allegedly) a > Samsung HD753) as my Time Machine backup drive. I decided to also buy a 750 [quoted text clipped - 19 lines] > the LaCie for the clone backups, and start all over again with Time Machine, > using the Seagate? In terms of speed, it makes no difference whether the drives are daisy chained or connected to separate Firewire ports on the computer. The FW400 and FW800 ports in an iMac are on the same Firewire bus. Does the Icy Dock have two FW800 ports? If so, you might be able to reverse the order of the drives: iMac to Icy Dock (FW800), then Icy Dock to LaCie (FW800). That would allow best possible speed to both drives. The only catch with daisy chaining is whehter the drive passes through the Firewire signal while it is switched off. The drive in the midle might have to be on all the time, so it would make more sense for it to be your Time Machine backup drive. SignatureDavid Empson dempson@actrix.gen.nz >> I've been using my 750 GB LaCie d2 Quadra (the mechanism is (allegedly) a >> Samsung HD753) as my Time Machine backup drive. I decided to also buy a 750 [quoted text clipped - 23 lines] > chained or connected to separate Firewire ports on the computer. The > FW400 and FW800 ports in an iMac are on the same Firewire bus. That's what I thought (though, not initially). However, when I put the question to a LaCie tech, I was told: "The disadvantage to daisy-chain is that you are spitting up your bandwidth in addition, if you happen to add a FW400 then your entire chain drops to FW400 speeds." So, that's why I decided to ask here (albeit, in a round about way). > Does the Icy Dock have two FW800 ports? Yes it does. If so, you might be able to > reverse the order of the drives: iMac to Icy Dock (FW800), then Icy Dock > to LaCie (FW800). That would allow best possible speed to both drives. Now I'm again confused: If daisy chaining doesn't introduce any speed penalty, why should the connection order make a difference? > The only catch with daisy chaining is whehter the drive passes through > the Firewire signal while it is switched off. The drive in the midle > might have to be on all the time, so it would make more sense for it to > be your Time Machine backup drive. SignatureiMac (24", 2.8 GHz Intel Core 2 Duo, 2GB RAM, 320 GB HDD) OS X (10.5.4) > > In terms of speed, it makes no difference whether the drives are daisy > > chained or connected to separate Firewire ports on the computer. The > > FW400 and FW800 ports in an iMac are on the same Firewire bus. > > That's what I thought (though, not initially). However, when I put the > question to a LaCie tech, I was told: (Quick summary of my detailed explanation below: the LaCie tech is mistaken, or their Firewire devices have a really bad design.) > "The disadvantage to daisy-chain is that you are spitting up your bandwidth Exactly the same as if you plug into separate ports on the computer, as they are on the same Firewire bus. Some Mac models (probably only high-end ones like a Mac Pro) might have separate Firewire buses for different ports, but an iMac certainly doesn't (I checked the developer note for the latest model). You are only "splitting up your bandwidth" in the sense that if you were trying to transfer data to/from/between both Firewire drives at the same time, each one would only be able to use about half the Firewire bandwidth on average. If only one drive is active, the inactive one has no impact on Firewire throughput. Firewire daisy chaining also has almost no delay on data travelling through to the daisy chained port. This is completely different to USB, where the addition of a hub will slow down the communication due to the hub having to buffer and retransmit entire USB packets. The only real disadvantage of daisy chaining Firewire is if the device in the middle is switched off and it doesn't power its Firewire interface hardware from the bus. In this case, switching off the "mid chain" device will cut off the signal to the "end chain" device. > - in addition, if you happen to add a FW400 then your entire chain drops to > FW400 speeds." I haven't seen any evidence of this, and I've just done a test with two of my Firewire devices to disprove it. 1. An Ice Cube hard drive enclosure, which has 2xFW800 and 1xFW400 ports. It contains a 500 GB Seagate Barracuda. 2. A Hot Buttered 5.25" enclosure, which has 2xFW400 ports. It contains a Pioneer DVD writer. Both devices have an Oxford chipset. My computer is a MacBook Pro (August 2007 model), which has FW800 and FW400 ports which are on the same bus (same architecture as an iMac). 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. If I connect the hard drive to a FW800 port it reads at 60 MB/s. If I connect the hard drive to a FW400 port it reads at 40 MB/s. With the hard drive on the FW800 port, if I also connect the DVD writer at the same time, it has no effect on the speed of file transfers from the hard drive, whether I plug it into the FW400 port or daisy chain it from the hard drive. The only situation where the hard drive speed is affected is if I connect the DVD writer (FW400) to the computer and daisy chain the hard drive from the DVD writer. This limits the speed of the hard drive to FW400. Summary: mixing FW400 and FW800 devices only limits the speed of the FW800 devices if the data has to travel through a device or cable which uses FW400, at least for well designed Firewire devices. In your situation: if you connect the LaCie first (via FW800), and the Icy Dock second (via FW400 using a FW400 to FW800 cable), your LaCie should operate at FW800 speeds, but your Icy Dock will operate at FW400 speeds. If you connect the Icy Dock first (via FW800) and the LaCie second (also via FW800) then both devices should operate at FW800 speeds. You can check in System Profiler under the Firewire section to see the speed for each device. If the device supports FW800 then the "Maximum Speed" should be 800 Mb/sec, but if the connection arrangement is limiting its speed, then the "Current Speed" will be 400 Mb/sec. > > Does the Icy Dock have two FW800 ports? > [quoted text clipped - 6 lines] > Now I'm again confused: If daisy chaining doesn't introduce any speed > penalty, why should the connection order make a difference? Because if you put the LaCie first, then you have to use its FW400 port to connect the Icy Dock. This limits the Icy Dock to FW400 speed. If you put the Icy Dock first, you can connect everything with FW800 cables and both drives should run at FW800 speeds. (I'm assuming the LaCie doesn't have a bad design such that it is always operating at FW400 because one of its ports is FW400, or it slows down to FW400 if anything is connected to the FW400 port.) SignatureDavid Empson dempson@actrix.gen.nz >>> In terms of speed, it makes no difference whether the drives are daisy >>> chained or connected to separate Firewire ports on the computer. The [quoted text clipped - 109 lines] > operating at FW400 because one of its ports is FW400, or it slows down > to FW400 if anything is connected to the FW400 port.) There must¹ve been some sort of miscommunication between the tech-support guy and me. He is someone I¹ve dealt with before, and certainly appears to know his stuff (he¹s not the kind of guy who likes to hear himself talk, nor to offer incorrect advice when, in fact, he doesn¹t know the answer). My original question was: ³... is there any disadvantage to daisy-chaining the Quadra with another, FW 800-only external HD?² To which he responded: ³The disadvantage to daisy-chain is that you are spitting up your bandwidth in addition, if you happen to add a FW400 then your entire chain drops to FW400 speeds.² Your more-detailed explanation makes a lot of sense. It certainly clarifies what he probably meant re: splitting the bandwidth. But the part of his statement regarding the slowdown to FW 400 speeds still puzzles me, notwithstanding your very clear explanation (further verified by your actual testing). The reason I¹m still puzzled is that his claim is (seemingly) consistent with a LaCie ³white paper² I found last night, entitled ³FireWire 800 Technology Brief² (www.lacie.com/download/more/WhitePaper_FireWire_800.pdf), which includes (on the second page) the following paragraph: ³Legacy and Beta Devices Working Together The new standard was designed to be backwards compatible, meaning that FireWire 800 devices will still operate via the original FireWire 400 port. To connect a FireWire 800 device to a FireWire 400 port, a specific adapter cable must be used. There are two types of FireWire 400 ports: 6-pin and 4-pin. For FireWire 800 devices to work, they must be connected by placing the 9-pin end of the FireWire cable into the FireWire 800 port of the device, and the opposite 6-pin or 4-pin end into the FireWire 400 port. The same holds true for FireWire 400 devices being connected to a FireWire 800 host port. The 4-pin or 6-pin end of the FireWire cable must be connected to the FireWire 400 port of the device, and the 9-pin end must be connected to the FireWire 800 port. When FireWire 400 and FireWire 800 devices are mixed, all transfer rates revert to the original FireWire 400 speed.² This last sentence is the source of my remaining ³puzzlement,² as it does not temper the claim with any qualifiers regarding the location of the FW 800 devices along the chain. SignatureiMac (24", 2.8 GHz Intel Core 2 Duo, 2GB RAM, 320 GB HDD) OS X (10.5.4) > The reason I'm still puzzled is that his claim is (seemingly) consistent > with a LaCie "white paper" I found last night, entitled "FireWire 800 - > Technology Brief" > (www.lacie.com/download/more/WhitePaper_FireWire_800.pdf), Now that you remind me, I already had a copy of it. > which includes (on the second page) the following paragraph: > [quoted text clipped - 19 lines] > not temper the claim with any qualifiers regarding the location of the FW > 800 devices along the chain. That last sentence appears to be wrong. It might be a badly worded attempt to describe either of these reasonably obvious rules: 1. Communication between a FW400-only device and FW800 device will operate at FW400 speeds. 2. Communication travelling through a FW400 port at any point in the bus will be limited to FW400 speeds. It is certainly not true (and my experiment proved it) that the mere presence of an independent FW400 device somewhere on the bus will limit the speed of the transfer between two FW800 devices (as long as neither of the above two situations apply). Perhaps such a limitation does exist with some Firewire chipsets. SignatureDavid Empson dempson@actrix.gen.nz >> The reason I'm still puzzled is that his claim is (seemingly) consistent >> with a LaCie "white paper" I found last night, entitled "FireWire 800 - [quoted text clipped - 44 lines] > > Perhaps such a limitation does exist with some Firewire chipsets. 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.) 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? ;) SignatureiMac (24", 2.8 GHz Intel Core 2 Duo, 2GB RAM, 320 GB HDD) OS X (10.5.4) > 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 [quoted text clipped - 14 lines] > (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: [quoted text clipped - 7 lines] > 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. SignatureDavid Empson dempson@actrix.gen.nz >> 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 [quoted text clipped - 17 lines] > 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. I already did that. It reports " Maximum Speed: Up to 800 Mb/sec and Connection Speed: Up to 800 Mb/sec." There is no "Current Speed" number...nor a line item to indicate such a number. (I just double checked.) > 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. Well, this is ridiculous....I had a similar experience with the LaCie (TM copied about 6 GB in 3 hours). But when I first erased and formatted the drive and prepared it for use with TM, I had a minor concern, which led me to quitting the "would you like to set this drive up for time machine" inquiry prematurely. When I did get the drive set up for TM, it was incredibly sluggish. So, after the first 3 hours, I quit, trashed the TM plist, reformatted the drive, trashed the plist again, and then set up TM again. It ran like a charm, copying everything (about 150 GB) in (I'm guessing) about 6 hours. Though unsure why I was experiencing a similar problem last night with the Seagate, I did note that the TM's "would you like to set this drive up for time machine" message never appeared, and I had to "manually" initiate the setup. That didn't particularly concern me, as the Seagate had thrown up a "this disk is unreadable by this computer" message when I first plugged it in (the LaCie came preformatted -- albeit not HFS+ journaled -- for the Mac). Nevertheless, I decided to try the same "plist remedy." However, this time, it didn't work: Since reformatting the drive and restarting TM, in 10 hours it's only copied 31 GB. And I'm really getting very irritated (!!), as the iMac is pretty much bogged done and not all that available. >> In any event, I'd still like to get a handle on the speeds, and in your >> previous post you stated: [quoted text clipped - 96 lines] > > As I said, using benchmarking software would be much easier. Actually, your instructions are very clear. The "difficulty," it seems to me, is that it appears to be a way of using Terminal to estimate the speed using a single test to determine a single "data point," rather than via a series of tests (designed to account for the variances caching, file size, file location, etc., would introduce) to determine many data points, as I imagine a benchmarking app might do. I assume, of course (otherwise you'd have mentioned it) you know of no such software available on the net -- besides, perhaps, commercial packages? SignatureiMac (24", 2.8 GHz Intel Core 2 Duo, 2GB RAM, 320 GB HDD) OS X (10.5.4) > > 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. > > I already did that. It reports " Maximum Speed: Up to 800 Mb/sec > and Connection Speed: Up to 800 Mb/sec." There is no "Current Speed" > number...nor a line item to indicate such a number. (I just double checked.) Sorry - I misremembered the name. I meant "Connection Speed". > > 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 [quoted text clipped - 13 lines] > Seagate, I did note that the TM's "would you like to set this drive up for > time machine" message never appeared That's probably because Time Machine had already been configured to use the LaCie. The system only asks if you want to use a new drive for Time Machine if Time Machine hasn't been assigned to a drive yet. It also remembers the ones you've declined, so it will only ask once for each newly appearing drive. > and I had to "manually" initiate the setup. That didn't particularly > concern me, as the Seagate had thrown up a "this disk is unreadable by [quoted text clipped - 4 lines] > only copied 31 GB. And I'm really getting very irritated (!!), as the iMac > is pretty much bogged done and not all that available. I don't have an immediate explanation for this slow performance. I'm sure it is nothing to do with Firewire, and entirely due to something extra that is going on. For example, Spotlight indexing in parallel with Time Machine backups, or something else which causes Time Machine to operate slowly. [Snipped details of my 'dd' method of measuring drive throughput] > > As I said, using benchmarking software would be much easier. > > Actually, your instructions are very clear. The "difficulty," it seems to > me, is that it appears to be a way of using Terminal to estimate the speed > using a single test to determine a single "data point," Correct. I'm not interested in optimal results, just enough to establish whether the drive is transferring data faster than FW400 speeds, so this test was sufficient. > rather than via a series of tests (designed to account for the variances > caching, file size, file location, etc., would introduce) to determine > many data points, as I imagine a benchmarking app might do. A benchmarking app would probably get accurate results by unmounting the drive, so nothing else is using it while the test are being performed, and doing something to disable the system's cache. > I assume, of course (otherwise you'd have mentioned it) you know of no such > software available on the net -- besides, perhaps, commercial packages? It is more a case that I haven't gone looking for any. I'm sure there are several, including some free ones. SignatureDavid Empson dempson@actrix.gen.nz >>> 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. [quoted text clipped - 4 lines] > > Sorry - I misremembered the name. I meant "Connection Speed". Those numbers don't indicate any *actual* speed, however, correct? If so, what do they indicate that I already didn't know from reading the drive's spec sheet? >>> 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 [quoted text clipped - 19 lines] > remembers the ones you've declined, so it will only ask once for each > newly appearing drive. OK. Makes sense. >> and I had to "manually" initiate the setup. That didn't particularly >> concern me, as the Seagate had thrown up a "this disk is unreadable by [quoted text clipped - 10 lines] > Time Machine backups, or something else which causes Time Machine to > operate slowly. Well, without going into *too* many details, while I was switching back and forth between the Seagate and LaCie in Time Machine's prefs panel, and then trying to determine what effect ejecting and re-mounting each would have on the other, the Seagate drive icon in the Sidebar's Devices section suddenly vanished, and a strange-named icon appeared in the "Shared" section; Disk Utility still indicated the presence of both drives, and Time Machine continued with its activities. Frustrated (because I didn't know what was going on) I then decided to reboot. Once I did that, the TM backup on the Seagate began to proceed "normally" (i.e., in a reasonably fast fashion). A few hours later, the backup was completed. (But, of course, I still don't understand what happened.) > [Snipped details of my 'dd' method of measuring drive throughput] > [quoted text clipped - 21 lines] > It is more a case that I haven't gone looking for any. I'm sure there > are several, including some free ones. Well, I found some (http://www.speedtools.com/TestSuite.html), but it's not free. SignatureiMac (24", 2.8 GHz Intel Core 2 Duo, 2GB RAM, 320 GB HDD) OS X (10.5.4) > >>> 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. [quoted text clipped - 9 lines] > what do they indicate that I already didn't know from reading the drive's > spec sheet? If you connect a FW800 drive after a FW400 one, then for the FW800 drive you will see "Maximum Speed" of 800 but "Connection Speed" of 400, indicating that the bus configuration is limiting the speed of the FW800 drive. If it says "Connection Speed" of 800 then the bus configuration is not limiting the speed of the FW800 drive. They only indicate theoretical maximum/connection speeds, assuming no other bus activity and no performance limitations from the devices involved. For example, I've never seen my FW800 drive get actual sustained throughput faster than about 60 MB/s (480 Mbps), but that is due to the performance of the hard drive. The FW800 bus is not a limiting factor. On the other hand, if I copy data between my laptop's internal drive and my FW800 drive, the best possible throughput drops to more like 30 MB/s, because that is the maximum speed my internal drive can sustain. In this situation, FW800 doesn't help at all - FW400 is easily fast enough (and USB 2.0 is just fast enough on this particular computer). An iMac's internal drive will be faster than a laptop one, so it does benefit from FW800 when doing backups of the internal drive. The main benefit of FW800 on a laptop is for connection of a fast external drive as a primary data storage device, e.g. for video editing or other high throughput tasks. SignatureDavid Empson dempson@actrix.gen.nz >>>>> 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. [quoted text clipped - 14 lines] > indicating that the bus configuration is limiting the speed of the FW800 > drive. I do recall you indicating as much previously (i.e., that the order in the chain would have a speed impact). However, in your last post you agreed with my "guess" that each drive is "transparent" to the data traveling to/from the other: "Correct. If a device is not directly involved in the communication, its Firewire hardware forwards the data between the two ports without any involvement of the CPU in that device. I expect the delay involved is in the order of magnitude of one bit time (e.g. around 2.5 ns for FW400)." The only way I can resolve this confusion (in my mind) is by assuming that even if a FW 400 device is NOT involved in the communication, its connecting cables *inherently* are, by virtue of the difference in their physical configuration (i.e., fewer wires to carry FW 800's additional (compared to FW 400) packet-control data, thereby effectively "blocking" that data from traveling further up/down the bus). In other words, I'm assuming (I haven't tried to look into it) that the "evolution" of FW 800 required adding physical changes to the existing FW 400 specification, which was accomplished by adding a new "layer" on top of the existing FW 400 physical design configuration (rather than creating a new design from scratch), to help ease the implementation of "backward compatibility." > If it says "Connection Speed" of 800 then the bus configuration is not > limiting the speed of the FW800 drive. [quoted text clipped - 18 lines] > external drive as a primary data storage device, e.g. for video editing > or other high throughput tasks. SignatureiMac (24", 2.8 GHz Intel Core 2 Duo, 2GB RAM, 320 GB HDD) OS X (10.5.4) > I do recall you indicating as much previously (i.e., that the order in the > chain would have a speed impact). However, in your last post you agreed with [quoted text clipped - 17 lines] > design configuration (rather than creating a new design from scratch), to > help ease the implementation of "backward compatibility." FW 800 does not use more wires to cary data. While it does use a 9 pin connector, the three additional pins are not used for data. One is not used at all and the other two are shields for the signaling wires. SignatureTom Stiller PGP fingerprint = 5108 DDB2 9761 EDE5 E7E3 7BDA 71ED 6496 99C0 C7CF >> I do recall you indicating as much previously (i.e., that the order in the >> chain would have a speed impact). However, in your last post you agreed with [quoted text clipped - 21 lines] > connector, the three additional pins are not used for data. One is not > used at all and the other two are shields for the signaling wires. In which case, I remain confused. :( SignatureiMac (24", 2.8 GHz Intel Core 2 Duo, 2GB RAM, 320 GB HDD) OS X (10.5.4) > >> I do recall you indicating as much previously (i.e., that the order in the > >> chain would have a speed impact). However, in your last post you agreed [quoted text clipped - 26 lines] > > In which case, I remain confused. :( The signaling protocol is bit serial using data strobe encoding. Even if an intermediate node cannot process FW 800 data itself, if it faithfully passes on the signals on to the next node in the chain, it will not slow down the transfer. SignatureTom Stiller PGP fingerprint = 5108 DDB2 9761 EDE5 E7E3 7BDA 71ED 6496 99C0 C7CF >>>> I do recall you indicating as much previously (i.e., that the order in the >>>> chain would have a speed impact). However, in your last post you agreed [quoted text clipped - 31 lines] > faithfully passes on the signals on to the next node in the chain, it > will not slow down the transfer. How does that square with what David explained (which did not contain any "qualifiers"): > If you connect a FW800 drive after a FW400 one, then for the FW800 drive > you will see "Maximum Speed" of 800 but "Connection Speed" of 400, > indicating that the bus configuration is limiting the speed of the FW800 > drive. SignatureiMac (24", 2.8 GHz Intel Core 2 Duo, 2GB RAM, 320 GB HDD) OS X (10.5.4) > > The signaling protocol is bit serial using data strobe encoding. Even > > if an intermediate node cannot process FW 800 data itself, if it [quoted text clipped - 3 lines] > How does that square with what David explained (which did not contain any > "qualifiers"): So? Just because a qualifier *could* be preset, doesn't mean that one *is* present. The bus master determines the capabilities of each device in the chain and sets the parameters for a transfer accordingly. SignatureTom Stiller PGP fingerprint = 5108 DDB2 9761 EDE5 E7E3 7BDA 71ED 6496 99C0 C7CF >>> The signaling protocol is bit serial using data strobe encoding. Even >>> if an intermediate node cannot process FW 800 data itself, if it [quoted text clipped - 7 lines] > *is* present. The bus master determines the capabilities of each device > in the chain and sets the parameters for a transfer accordingly. David's statements regarding daisy chaining FW drives appeared to be unequivocal -- stated without any "qualifiers" (i.e., no "conditions of exception"): (1) "If a device is not directly involved in the communication, its Firewire hardware forwards the data between the two ports without any involvement of the CPU in that device." The only situation where speeds would be effected would be if instead of drives, the devices were/contained some form of signal processors. (2) "...mixing FW400 and FW800 devices ... limits the speed of the FW800 devices if the data has to travel through a device or cable which uses FW400 ..." The only way I could imagine both statements being true was if the presence of the FW 400 cable along the chain somehow -- perhaps because it incorporated less signal-carrying cable pairs -- "blocked" a portion of the signaling used to maintain the FW 800 speed. But you pointed out that the only additional "wire" that FW 800 had compared to FW 400 was shielding, which carries no data. Hence, I remain confused as to why a daisy chain of mixed FW 800/400 drives will result in a slowdown after the first FW 400 is encountered. SignatureiMac (24", 2.8 GHz Intel Core 2 Duo, 2GB RAM, 320 GB HDD) OS X (10.5.4) > >>> The signaling protocol is bit serial using data strobe encoding. Even > >>> if an intermediate node cannot process FW 800 data itself, if it [quoted text clipped - 31 lines] > Hence, I remain confused as to why a daisy chain of mixed FW 800/400 drives > will result in a slowdown after the first FW 400 is encountered. David and I have a different understanding of how firewire encodes data. I can't pursue the issue further because I don't have enough first hand information to say one way or the other. I do intend to research the issue further, but I have to abandon it for now. SignatureTom Stiller PGP fingerprint = 5108 DDB2 9761 EDE5 E7E3 7BDA 71ED 6496 99C0 C7CF > David and I have a different understanding of how firewire encodes data. > I can't pursue the issue further because I don't have enough first hand > information to say one way or the other. I do intend to research the > issue further, but I have to abandon it for now. I've found an old but reasonably detailed technical article which covers IEEE 1394 (Firewire 400). <http://www.embedded.com/1999/9906/9906feat2.htm> This explains details like the Data Strobe encoding method used by Firewire 400 and goes into a fair amount of detail on things like bus configuration, addressing, negotiation, etc. While reading it I spotted an interesting paragraph which relates to the specific question of what happens when you mix Firewire device speeds in a daisy chain. A little background: IEEE 1394-1995 ("Firewire 400") also supports lower speed devices that operate at 100 Mbps or 200 Mbps. The article is referencing a sample Firewire bus which has five devices daisy chained in this order: Digital camera Set-top box Digital VCR PC DVD-RAM The Digital VCR also has another Firewire port connected to a printer. Here is the paragraph of interest: "Nodes can only transmit as fast as the slowest device between the transmitting node and the receiving node. For example, if the digital camera and the digital VCR are both capable of transmitting at 400Mbps, but the set-top box is only capable of transmitting at 100Mbps, the high-speed devices cannot use the maximum rate to communicate amongst themselves. The only way around this problem is for the end user to reconfigure the cabling so the low-speed set-top box is not physically between the two high-speed devices." This is presumably extended to Firewire 800 and higher speeds, so is a universal rule of Firewire. This page on the 1394 trade association site has some useful overview information. http://www.1394ta.org/Technology/About/1394b.htm In particular, the "Overview Presentation" confirms issues like the encoding method and how the transmit and receive signals are mapped to wires in 1394b. (It looks like FW800 actually does transmit at 800 Mbps over a single pair - ignore my earlier theory about the data being split in half.) Lots of information to absorb... I expect that to get much more technical detail it would be necessary to buy a copy of the 1394 standards, which won't exactly be cheap (looks like US$107 to US$161 for each of 1394, 1394a and 1394b as a PDF to non-members of IEEE; I might be able to get them through work at the member price, but I'm not _that_ interested). SignatureDavid Empson dempson@actrix.gen.nz > > David and I have a different understanding of how firewire encodes data. > > I can't pursue the issue further because I don't have enough first hand [quoted text clipped - 60 lines] > non-members of IEEE; I might be able to get them through work at the > member price, but I'm not _that_ interested). Thanks for the update. I had read the embedded.com article and one other regarding Data Strobe encoding, but I wasn't sure of their publication dates and standards evolution since. SignatureTom Stiller PGP fingerprint = 5108 DDB2 9761 EDE5 E7E3 7BDA 71ED 6496 99C0 C7CF >> David and I have a different understanding of how firewire encodes data. >> I can't pursue the issue further because I don't have enough first hand [quoted text clipped - 60 lines] > non-members of IEEE; I might be able to get them through work at the > member price, but I'm not _that_ interested). David- Apparently, I misunderstood your statement when you said that I was "correct" regarding "transparency." These docs look very promising, in terms of helping me to gain a basic understanding of Firewire. Many thanks. PS: My recollection (many, many years back) is that IEEE pricing was always high; being a member certainly was better, but IEEE pubs still were rather pricey. SignatureiMac (24", 2.8 GHz Intel Core 2 Duo, 2GB RAM, 320 GB HDD) OS X (10.5.4) Well, if it¹s not one thing, it¹s another... I¹ve never given a second thought to the manner in which I shut down/booted my Macs and disconnected/connected my external drives (as long as I made sure I dismounted them prior to disconnecting them), have you? According to the following (which I found at <http://www.hardmac.com/articles/16/>), maybe we should (at least for *some* Macs): ³The only really proven way to avoid burning up a FireWire port is to connect all devices and to turn them on PRIOR turning on the Mac. Likely, one must unplug them and turn them off AFTER the Mac has been turned off. If you need to connect another device, then you're on for a shutdown of your machine... It's a tad annoying but it guarantees that the FW ports won't be damaged. ³ It goes on to say: ³Be careful when using self powered devices such as webcams, iPods, hard drives or hubs, as they can destroy the port pretty easily. Another thing is to avoid daisy-chaining hard drives.² Comments? SignatureiMac (24", 2.8 GHz Intel Core 2 Duo, 2GB RAM, 320 GB HDD) OS X (10.5.4) > > If you connect a FW800 drive after a FW400 one, then for the FW800 drive > > you will see "Maximum Speed" of 800 but "Connection Speed" of 400, [quoted text clipped - 5 lines] > my "guess" that each drive is "transparent" to the data traveling to/from > the other: But only if the device in the middle of the chain supports the signal encoding that the devices at the end of the chain want to use. A device with FW400 connectors only supports FW400 signal encoding, so anything which travels through that device must be limited to FW400. FW800 signals cannot pass through a FW400-only device (or a FW400 port on a mixed device). Devices with FW800 connectors support both FW400 and FW800 signal encoding, so they can pass FW400 through transparently. This is determined at the point when the bus configuration is established. Each device negotiates with its neighbours to establish the supported communication methods, and this information is propagated to every device on the bus, so every device knows the best signalling method it can use to talk to every other device. Two FW800 devices connected via FW800 cables and ports and other FW800 devices will be able to use FW800 signalling. Two FW800 devices with any FW400 cables, ports or devices between them will be limited to FW400 signalling. > The only way I can resolve this confusion (in my mind) is by assuming that > even if a FW 400 device is NOT involved in the communication, its connecting > cables *inherently* are, by virtue of the difference in their physical > configuration (i.e., fewer wires to carry FW 800's additional (compared to > FW 400) packet-control data, thereby effectively "blocking" that data from > traveling further up/down the bus). The three extra pins on FW800 cables and connectors are not used to carry data. Two of them provide ground references (and/or shielding) for each of the two signal pairs, and the third one is unused. The ground reference allows more reliable transmission at higher speeds and for longer distances. FW800 achieves its higher speed by using a different signal encoding method and changing the way in which the existing signal lines are used. I haven't seen full details of this, so I can only speculate on exactly how it works, but from the evidence I've found and my background understanding of signal encoding and data transmission, it seems likely that the differences can be explained as follows. FW400 uses separate data and clock signals. Each of these is sent over a balanced pair of wires (four wires in total). FW800 uses an encoding method called 8b/10b which allows the clock to be encoded within the data stream. Speculation on my part: this encoding method would allow FW800 to make use of both signal pairs for data transmission, so it can split the data in half and send two 400 Mbps data streams which are each encoded using 8b/10b. There is some overhead for the 8b/10b signalling, so FW800 compensates by transmitting data at a slightly higher baud rate (raw rate of signal state changes on the individual wires) compared to FW400. The end result is that FW800 is able to transmit data twice as fast as FW400, by using a signal which only changes state about 25% faster than FW400. The FW800 data (combined with clock) travels over four wires, while the FW400 data only travels over two wires (with a clock on the other two wires). There is some general background on Wikipedia which summarises Firewire and describes the 8b/10b encoding method in general terms but not its specific use in Firewire 800. http://en.wikipedia.org/wiki/Firewire http://en.wikipedia.org/wiki/8B10B A FW400 device expects to get separate clock and data at a particular baud rate, so it can't correctly receive or understand FW800. As the interface hardware requires buffering and retransmitting the signal, it also can't pass FW800 through, because it only understands FW400 on both the receive and transmit sides. > In other words, I'm assuming (I haven't tried to look into it) that the > "evolution" of FW 800 required adding physical changes to the existing FW > 400 specification, which was accomplished by adding a new "layer" on top > of the existing FW 400 physical design configuration (rather than creating > a new design from scratch), to help ease the implementation of "backward > compatibility." A new mode of operation was added, with new devices able to operate in either the new or old mode, but they have to use the old mode when communicating with or through old devices. The negotiation protocol (used when the bus configuration is established) is compatible with all devices, presumably because it is based on FW400 signalling. FW800 signalling is only used after the negotiation phase, and only if all devices in the chain between the two communicating devices also support FW800 signalling (implied by their cable connectors). In theory, a mixed device with FW400 and FW800 connectors may be able to pass FW800 through the FW400 connector, but this is probably disallowed by the IEEE 1394b standard for reliability reasons. Things might get confusing once FW3200 is introduced. My understanding is that uses the same connectors and cables as FW800, and is backward compatible with FW800, but the same rule is likely to apply: a FW800 device in the middle of the chain will limit speed through that device to FW800. There won't be a visible external difference to tell that this is going to happen. SignatureDavid Empson dempson@actrix.gen.nz > That's what I thought (though, not initially). However, when I put the > question to a LaCie tech, I was told: > > "The disadvantage to daisy-chain is that you are spitting up your bandwidth > in addition, if you happen to add a FW400 then your entire chain drops to > FW400 speeds." Not correct. > Now I'm again confused: If daisy chaining doesn't introduce any speed > penalty, why should the connection order make a difference? You want to put the slower device(s) at the end of the chain, because the speed will be reduced to accomodate a particular device, and will not go up again for other things farther down the chain. For example, I have some gear that has FW400 ports on it, but only runs at 200mbps. It has be be at the end of a chain. Or, if you can, use a FW hub, and quit worrying about all the above. Billy Y.. >> That's what I thought (though, not initially). However, when I put the >> question to a LaCie tech, I was told: [quoted text clipped - 14 lines] > For example, I have some gear that has FW400 ports on it, but only runs > at 200mbps. It has be be at the end of a chain. Given what you (and David) have explained, then the answer to my original question: >> My question then is this: Should I daisy chain the two drives together to >> run off the iMac's single FW 800 port? Or would I be better off reformatting >> the LaCie for the clone backups, and start all over again with Time Machine, >> using the Seagate? appears to be that I should go through the aggravation of reformatting the LaCie for my clone backups, and putting it at the end of the chain, unless I'm willing to leave both drives on 24 X 7. (Make sense?) > Or, if you can, use a FW hub, and quit worrying about all the above. Since I have no plans to add anymore FW devices anytime soon, I's rather avoid spending $40 (or whatever they cost) on a FW hub. > Billy Y.. SignatureiMac (24", 2.8 GHz Intel Core 2 Duo, 2GB RAM, 320 GB HDD) ? OS X (10.5.4) > Given what you (and David) have explained, then the answer to my original > question: [quoted text clipped - 7 lines] > LaCie for my clone backups, and putting it at the end of the chain, unless > I'm willing to leave both drives on 24 X 7. (Make sense?) Yea, but I just looked at Apple's specs and they say there is also a FW400 port on the iMac. If that's the case, why not just use it? Billy Y.. >> Given what you (and David) have explained, then the answer to my original >> question: [quoted text clipped - 14 lines] > > Billy Y.. Speed. Since both drives can run at FW 800, why run the LaCie at FW 400? Originally, I figured that if I couldn't daisy-chain them, and *had* to use the LaCie as a FW 400 drive, I'd absolutely want to use the Seagate as my Time Machine drive, inasmuch as it would run so frequently each day, I'd need/want the higher speed; the LaCie would then be my "clone" drive, which I'd use perhaps once a day, so speed wouldn't be as critical. That seemed to make the most sense. But if I can run them both at FW 800, why not? The "downside" seems to be the initial aggravation I'll need to go through reformatting the LaCie, so that I can use it for "occasional" cloning, and thereby avoid the necessity of leaving the Seagate "on" all the time (which is what I'd apparently need to do were I to continue to use the LaCie as a FW 800 Time Machine drive daisy-chained to the Seagate). SignatureiMac (24", 2.8 GHz Intel Core 2 Duo, 2GB RAM, 320 GB HDD) OS X (10.5.4) > > Given what you (and David) have explained, then the answer to my original > > question: [quoted text clipped - 13 lines] > Yea, but I just looked at Apple's specs and they say there is also a FW400 > port on the iMac. If that's the case, why not just use it? It is the case and I, for one, use it in just that manner. SignatureTom Stiller PGP fingerprint = 5108 DDB2 9761 EDE5 E7E3 7BDA 71ED 6496 99C0 C7CF >>> Given what you (and David) have explained, then the answer to my original >>> question: [quoted text clipped - 15 lines] >> > It is the case and I, for one, use it in just that manner. Do you use it to make 24 daily backups via Time Machine? SignatureiMac (24", 2.8 GHz Intel Core 2 Duo, 2GB RAM, 320 GB HDD) OS X (10.5.4) > >>> Given what you (and David) have explained, then the answer to my original > >>> question: [quoted text clipped - 17 lines] > > Do you use it to make 24 daily backups via Time Machine? Yes, my TM drive is connected to the iMac's FW-800 port and an old FW-400 iPod chained off that drive's FW-400 port. A FW-400 utility drive is connected to the iMac's FW-400 port, which is chained to a third drive, and then to a Canopus video digitizer. SignatureTom Stiller PGP fingerprint = 5108 DDB2 9761 EDE5 E7E3 7BDA 71ED 6496 99C0 C7CF >>>>> Given what you (and David) have explained, then the answer to my original >>>>> question: [quoted text clipped - 22 lines] > drive is connected to the iMac's FW-400 port, which is chained to a > third drive, and then to a Canopus video digitizer. It sounded like you were saying you used the FW 400 port for TM. My point was, based on what I've learned here, if I want to continue to run TM backups via FW 800, and *not* have to leave *both* drives on 24 X 7, I'd need to use the Seagate for the TM backups and the LaCie (at the end of the daisy chain, if I want to run it at FW 800) for the clone backups. SignatureiMac (24", 2.8 GHz Intel Core 2 Duo, 2GB RAM, 320 GB HDD) OS X (10.5.4) David- I'd like to revisit your statement regarding "speed" (below): >> I've been using my 750 GB LaCie d2 Quadra (the mechanism is (allegedly) a >> Samsung HD753) as my Time Machine backup drive. I decided to also buy a 750 [quoted text clipped - 23 lines] > chained or connected to separate Firewire ports on the computer. The > FW400 and FW800 ports in an iMac are on the same Firewire bus. This implies two things: (1) That the Mac somehow knows how to manage two different data streams, *running at different rates*, on a single bus. (2) That when daisy chained, the drives don't "get in each other's way" (i.e., each drive is "transparent" to the data traveling to/from the other). This suggests that there is some kind of "packet multiplexing" scheme inherent to firewire. Having said that, and having discussed the likelihood that the LaCie tech was in error, and the LaCie "white paper" was poorly worded....why do you suppose that when the question of mixing FW800 and FW400 devices on the same daisy chain is raised in most discussion forums (and elsewhere), the answer invariably comes back "it'll work...but everything will run at FW400 speed" (I discovered that today when I googled "Firewire daisy chain" looking for more info)? SignatureiMac (24", 2.8 GHz Intel Core 2 Duo, 2GB RAM, 320 GB HDD) OS X (10.5.4) > David- > [quoted text clipped - 13 lines] > (1) That the Mac somehow knows how to manage two different data streams, > *running at different rates*, on a single bus. Yes, for any number of data streams. The Mac knows the speed at which it can talk to each device, and adjusts the bus speed for each packet it sends or receives according to the "connection speed" it can achieve for that device. > (2) That when daisy chained, the drives don't "get in each other's way" > (i.e., each drive is "transparent" to the data traveling to/from the other). Correct. If a device is not directly involved in the communication, its Firewire hardware forwards the data between the two ports without any involvement of the CPU in that device. I expect the delay involved is in the order of magnitude of one bit time (e.g. around 2.5 ns for FW400). > This suggests that there is some kind of "packet multiplexing" scheme > inherent to firewire. Yes. All data over Firewire is broken up into packets. (I don't know how big they can get, but I'd expect them to be a few kilobytes at most.) If sending a lot of data (e.g. megabytes), multiple packets will be sent. > Having said that, and having discussed the likelihood that the LaCie tech > was in error, and the LaCie "white paper" was poorly worded....why do you [quoted text clipped - 3 lines] > (I discovered that today when I googled "Firewire daisy chain" looking for > more info)? My testing involved a Firewire bus which only had hard drives connected. It showed that the presence of an independent FW400 device does not limit the speed of communication between a computer and a FW800 drive, at least for my particular set of devices. There could be one situation I haven't addressed yet. Some devices (such as video cameras) operate by reserving a chunk of Firewire bandwidth for real time data transmission. The remaining bandwidth is available for other devices (such as hard drives). When this mode of operation is used, it might force the Firewire bus to operate at a particular speed, e.g. FW400. Another possibility which I've alluded to is that some FW400 devices or chipsets might be limited in some way which requires the entire bus to slow down to FW400 speeds if they are connected. If so, the specific FW400 devices I tested with do not have this limitation. I've made sure all my enclosures are good quality ones using Oxford chipsets. I don't have any cheap and nasty ones to test with. :-) SignatureDavid Empson dempson@actrix.gen.nz >> David- >> [quoted text clipped - 33 lines] > big they can get, but I'd expect them to be a few kilobytes at most.) If > sending a lot of data (e.g. megabytes), multiple packets will be sent. Can you point me to some very basic introductory material (not-too-too-technical, descriptive overview or "tutorial") on firewire? >> Having said that, and having discussed the likelihood that the LaCie tech >> was in error, and the LaCie "white paper" was poorly worded....why do you [quoted text clipped - 16 lines] > this mode of operation is used, it might force the Firewire bus to > operate at a particular speed, e.g. FW400. I did get the impression that there were *legitimate* reasons for not daisy chaining certain kinds of devices (such as cameras), and this explains why. But I still am puzzled why LaCie was pretty adamant about the speed impact of daisy chaining mixed drives (yes, I know we concluded that it might be a case of poor wording in their White Paper, as well as a mistaken tech-support person). And it's not just LaCie...I found a rather definitive statement from a UK vendor on a Q&A page at its site (http://www.pcbuyerbeware.co.uk/USBProblems.htm#daisy): "FireWire 400 and FireWire 800 can be daisy-chained by making use of an adapter cable. However, they will then all operate at FireWire 400 speeds." (It could, once again, simply be a matter of poor wording in the context of a broader discussion. If so, it's beginning to appear that good grammatical construction is hard to find in the firewire industry market sector. ;) ) > Another possibility which I've alluded to is that some FW400 devices or > chipsets might be limited in some way which requires the entire bus to [quoted text clipped - 3 lines] > I've made sure all my enclosures are good quality ones using Oxford > chipsets. I don't have any cheap and nasty ones to test with. :-) Now I understand why, when I was investigating which external HDs to buy, folks were advising me to be sure whatever I get uses an Oxford chipset. I was also told that the *preferred* chipset was either the Oxford 924 or 934. The Icy Dock folks told me that its enclosure uses the 924; LaCie told me the Quadra uses the 934. (Do you know what distinguishes the various Oxford models from each other?) I guess the lesser-known brands are less expensive, but also less capable in one or more ways. SignatureiMac (24", 2.8 GHz Intel Core 2 Duo, 2GB RAM, 320 GB HDD) OS X (10.5.4) > Can you point me to some very basic introductory material > (not-too-too-technical, descriptive overview or "tutorial") on firewire? I haven't found anything comprehensive. Wikipedia has a general overview but it is light on details. <http://en.wikipedia.org/wiki/Firewire> Apple have an overview here, which covers a few more details: <http://developer.apple.com/documentation/HardwareDrivers/Conceptual/HWT ech_FireWire/Articles/FireW_concepts.html> Most of what I know about Firewire comes from much older documentation which I read many years ago and don't recall where I saw it. I haven't seen detailed documentation on FW800, so my knowledge there is derived from hints in various references, and observation. The official documentation is available from IEEE but I haven't felt the need to spend money on it as I'm not actually making Firewire devices. > > Some devices (such as video cameras) operate by reserving a chunk of > > Firewire bandwidth for real time data transmission. The remaining [quoted text clipped - 4 lines] > I did get the impression that there were *legitimate* reasons for not daisy > chaining certain kinds of devices (such as cameras), and this explains why. DV only needs 25 Mbps, so it leaves 375 Mbps for other devices. This shouldn't cause problems apart from slowing them down a little. Some devices may be worse than others. For example, Apple's Firewire iSight camera appears to cause problems if daisy chained via a hard drive, perhaps due to reserving too much of the Firewire bus, or maybe because some hard drive enclosures don't understand or correctly implement the reservation protocol. > But I still am puzzled why LaCie was pretty adamant about the speed impact > of daisy chaining mixed drives (yes, I know we concluded that it might be a [quoted text clipped - 9 lines] > a broader discussion. If so, it's beginning to appear that good grammatical > construction is hard to find in the firewire industry market sector. ;) ) Yes, I'm similarly puzzled and so far can only speculate as to why my reality disagrees with these claims. > > Another possibility which I've alluded to is that some FW400 devices or > > chipsets might be limited in some way which requires the entire bus to [quoted text clipped - 10 lines] > the Quadra uses the 934. (Do you know what distinguishes the various Oxford > models from each other?) The different model numbers have different combinations of external interfaces/protocols, various extra features such as RAID modes for multiple drives, and have different internal drive connection methods. Here is a full list. <http://www.oxsemi.com/products/storage/das.html> For example, the Oxford 911 supports FW400 only, and a parallel ATA drive. The 912 supports FW800 only, and adds RAID 0. The 924 supports USB 2.0, FW400 and FW800, with a SATA drive, and a few more RAID modes. Some variants support eSATA or can attach to two SATA drives. The 934 seems to be a simpler variant of the 924. Some variants don't have FW800 support, and none have built-in RAID 1 support. The OXUFS936QSE is fun. Quad SATA interface, all external interface types, supports almost all RAID configurations and encryption. SignatureDavid Empson dempson@actrix.gen.nz |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.