What's the fix for getting 1394b Firewire to work on XP SP3, it's SLOWER than 1394a!!

computer

Platinum Member
Nov 5, 2000
2,735
2
0
I just installed a 1394b PCI card and hooked up an external 1394b HD enclosure.

I ran benchmarks on it, and it's only "a little" faster than the exact tests I ran on the same HD in a 1394a enclosure. Not anywhere near twice as fast and I didn't think it would be, but I still thought it would be faster than this, but it IS significantly faster.

So I then started with the timed file transfer tests which is simply copying of large folders with all kinds of files in them. 1394b is SEVERAL TIMES SLOWER! :eek: How can this be possible? How can the benchmarks be faster, yet it takes over TWENTY MINUTES to copy a file that took 90 SECONDS with 1394a??????????????????? (It said it would take 24 minutes and I just disgustingly canceled it).

I started checking into this to see what could be the problem, and to my utter horror, I came across this. Look at the bottom of the page. WTF????? :eek:

Wow, so much information flying at me in the same day, evidently with Microsoft Windows XP SP2, they will be "killing" 1394B, any 1394b products connected will operate at 100Mbps (slower than 1394A). WTF. They are doing this because they dont want FireWire cutting back into USB's market-space. Feel the control of Microsoft. Maybe they will feel the consumer control when everybody stays with XP SP1.

So I then found this "fix" at the M$ site. But the freakin' patch is only for SP2! It won't install on SP3!

I do have the path it mentions:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\PCI\

....but I do not have that info "1394_hc_hw_id" that it mentions at the end of that path anywhere. I guess because I can't install the patch. ???

I also don't have that file "cstupd1394sidspeed.dll" anywhere on my PC, but I do have the other file Ohci1394.sys. These files are in the unpacked patch but it doesn't say where cstupd1394sidspeed.dll should go. I don't even know if manually adding that file to the "correct" location would work.

The first thing that's beyond my comprehension, is HOW ALL of the many benchmarks I ran can be FASTER for 1394b, but when dragging and copying files it's a 15-20 times slower than 1394a?!?!?!?!?!?!?

The next thing that's beyond my comprehension, is how these retards at M$ can not only pull a stunt like that, but, also how can anyone SELL ANY 1394b hardware for XP (after SP1) when it DOESN'T WORK?!??!?!?!?!?!?!?!?

Then finally, how can I incorporate that fix above to work on SP3? Just add those registry keys? Or does SP3 not even need the fix? If SP3 does not need the fix, then why is it so slow?

I can't be the only person that's trying to use 1394b on XP SP2 or SP3.

Thanks.
-Clint
 
Last edited:

computer

Platinum Member
Nov 5, 2000
2,735
2
0
Did you run the same benchmarks using the 1394a port on your new enclosure?
Thanks for replying. What would that tell me?

I actually found the alleged fix for SP3 here, got the Hotfix from the M$ site, installed it, and it "destroyed" my PC.

Here are the damages:

First, the freakin' 1394b is now EVEN SLOWER! Now the benchmarks are even much slower than 1394a!!!

Next, I can no longer search any folders!! I right click any drive or folder and try to "Search", and it's go*damn black screen!!

Next, the anti-spam toolbar for Kaspersky Internet Security, has VANISHED from OE!!!

These a$$holes at M$ need to be SHOT.

F**k it. I'm just going to have to uninstall the spawn-of-satan patch, remove all this bullschitt, and do an ERUNT restore and go back to the way things were 8 f**king hours ago. That's ~150 bucks wasted and 8 hours wasted. Thanks M$. Freakin' JERKS.
-Clint
 

RebateMonger

Elite Member
Dec 24, 2005
11,586
0
0
My recollection of XP/2003 and FireWire 800 was that there were political issues that resulted in FireWire 800 never working quite right on those OSes. At least not after XP SP1 and with the built-in Windows drivers. The usual symptom was FireWire 800 being slower than FireWire 400.

There were, apparently, also problems in Vista. It sounds like MS may have finally gotten FireWire 800 to work properly in Windows 7.
 

computer

Platinum Member
Nov 5, 2000
2,735
2
0
OrangeWare Corp claims their drivers will give you true S800 1394b speeds, but that's what's bundled with the controller card! Unibrain also claims this, and I tried their drivers yesterday...same crap! What they claim is also BS.
-Clint
 

computer

Platinum Member
Nov 5, 2000
2,735
2
0
Blain, I got to thinking about what you said, to see if I could find out if it were maybe the enclosure, or the PCI card. So I hooked up the enclosure's 1394a port to my mobo, and the tests were about the same (actually a bit better in some, slightly worse in others, essentially the same). So I then hooked up the enclosure's 1394a port to the 1394a port on the controller card, and, the tests sucked, significantly slower!

So this points to the controller card "having something wrong" with it. But the question there is; is it its drivers causing it, or the hardware? Or, is it the PCI slot/bus? I'm more inclined to believe it's not the PCI bus because it's more than fast enough for FW800. OR, is it the 1394b drivers and issues with XP with it??? I have no way of knowing if this problem would still exist with a different PCI card, or even with a mobo with integrated 1394b.

Is anyone using 1394b with XP and getting 1394b speeds?
 

computer

Platinum Member
Nov 5, 2000
2,735
2
0
My recollection of XP/2003 and FireWire 800 was that there were political issues that resulted in FireWire 800 never working quite right on those OSes. At least not after XP SP1 and with the built-in Windows drivers. The usual symptom was FireWire 800 being slower than FireWire 400.

There were, apparently, also problems in Vista. It sounds like MS may have finally gotten FireWire 800 to work properly in Windows 7.
Would you have any idea of exactly how it was fixed in Win7? Like which drivers were replaced (sbp2port.sys, or others) that may have fixed it?
-Clint
 

RebateMonger

Elite Member
Dec 24, 2005
11,586
0
0
Would you have any idea of exactly how it was fixed in Win7? Like which drivers were replaced (sbp2port.sys, or others) that may have fixed it?
-Clint
Here's what Microsoft released about Win7 1394 support:

Windows 7 will also contain a new FireWire (IEEE 1394) stack that fully supports IEEE 1394b with S800, S1600 and S3200 data rates:

http://en.wikipedia.org/wiki/Features_new_to_Windows_7

Microsoft windows 1394 Roadmap:

http://www.1394ta.org/developers/Seminars/2008_MS1394b.pdf

The New 1384 Bus Driver in Windows 7:

http://www.microsoft.com/whdc/connect/1394_Windows7.mspx
 

alexruiz

Platinum Member
Sep 21, 2001
2,836
556
126
Did you go into device manager -> hard drives and selected the firewire drive? You MUST enable "optimize for speed" and "enable write cache"....
 

computer

Platinum Member
Nov 5, 2000
2,735
2
0
Here's what Microsoft released about Win7 1394 support:

Windows 7 will also contain a new FireWire (IEEE 1394) stack that fully supports IEEE 1394b with S800, S1600 and S3200 data rates:

http://en.wikipedia.org/wiki/Features_new_to_Windows_7

Microsoft windows 1394 Roadmap:

http://www.1394ta.org/developers/Seminars/2008_MS1394b.pdf

The New 1384 Bus Driver in Windows 7:

http://www.microsoft.com/whdc/connect/1394_Windows7.mspx

Thanks, I'll check those out. ;)
-Clint
 
Last edited:

computer

Platinum Member
Nov 5, 2000
2,735
2
0
Did you go into device manager -> hard drives and selected the firewire drive? You MUST enable "optimize for speed" and "enable write cache"....
(Ah there we go. ;))

Yep, and oddly enough it didn't change anything! :eek: I've noticed that the first time you hook up a new "external" device, the option to "Optimize for quick removal" is selected by default and you have to change that to "optimize for performance". So when I noticed it was selected for optimize for removal, I was happy to see that and I changed it. No change in performance. :\ :confused:
-Clint
 

alexruiz

Platinum Member
Sep 21, 2001
2,836
556
126
(Ah there we go. ;))

Yep, and oddly enough it didn't change anything! :eek: I've noticed that the first time you hook up a new "external" device, the option to "Optimize for quick removal" is selected by default and you have to change that to "optimize for performance". So when I noticed it was selected for optimize for removal, I was happy to see that and I changed it. No change in performance. :\ :confused:
-Clint

Try a reboot, and after the machine comes back to life, check again the disk in device manager to make sure stayed as "optimize for performance".... If that doesn't work I have no idea :(
 

computer

Platinum Member
Nov 5, 2000
2,735
2
0
Try a reboot, and after the machine comes back to life, check again the disk in device manager to make sure stayed as "optimize for performance".... If that doesn't work I have no idea :(

Yeah it stayed checked. But thanks anyway for trying. ;)
-Clint
 

computer

Platinum Member
Nov 5, 2000
2,735
2
0
i wonder if a windows 7 vm would do it.

From what I've heard, and from the info that "RebateMonger" posted says, Win7 has no problem with 1394b. But unfortunately I'm not using Win7 nor do I plan to.

I gather by "vm" you mean "virtual machine".....is there a way to do that on XP?
-Clint
 

computer

Platinum Member
Nov 5, 2000
2,735
2
0
I emailed Koutech yesterday to flat-out ask them does their FireWire cards REALLY WORK at 1394b speeds on XP SP3, since two of their cards were two I was considering. Get this, he told me all of their 1394b controller cards require a 64-bit PCI slot in order to achieve full 1394b FW800 speeds! He also went on to say ALL 1394b cards are that way! WTF??

First I have to say, if that is the case, then why are there so many of the cards that are only for 32-bit PCI slots? Why do these cards mention nothing about this? Why do no 1394b enclosures mention anything about this?

Furthermore, I've been reading all of the user reviews at NE for all of the PCI cards they have, and not a single person mentioned anything about needing a 64-bit slot to get 800 speeds. In fact, I was familiar with some of the mobo's they mentioned and they did not have 64-bit PCI slots! (I also read where many of them said they had to use the Unibrain drivers to get FW800).
 

mfenn

Elite Member
Jan 17, 2010
22,400
5
71
www.mfenn.com
I emailed Koutech yesterday to flat-out ask them does their FireWire cards REALLY WORK at 1394b speeds on XP SP3, since two of their cards were two I was considering. Get this, he told me all of their 1394b controller cards require a 64-bit PCI slot in order to achieve full 1394b FW800 speeds! He also went on to say ALL 1394b cards are that way! WTF??

First I have to say, if that is the case, then why are there so many of the cards that are only for 32-bit PCI slots? Why do these cards mention nothing about this? Why do no 1394b enclosures mention anything about this?

Furthermore, I've been reading all of the user reviews at NE for all of the PCI cards they have, and not a single person mentioned anything about needing a 64-bit slot to get 800 speeds. In fact, I was familiar with some of the mobo's they mentioned and they did not have 64-bit PCI slots! (I also read where many of them said they had to use the Unibrain drivers to get FW800).

You also have to remember that the PCI bus has a total aggregate bandwidth of 133MB/s. If you're using an older computer (please post specs), then the disk controllers and such may also be on the PCI bus, even if you don't physically have a controller card in a PCI slot. Does your motherboard support PCI Express? If so, I would suggest returning the PCI 1394b card and getting a PCIe one. Even a version 1.0 PCIe x1 slot would have more than enough bandwidth for your 1394b card.

You mentioned having an image-based backup solution. Why don't you make an image of XP, install Windows 7 (no product key needed for first 30 days), and see what happens?
 
Last edited:

computer

Platinum Member
Nov 5, 2000
2,735
2
0
You also have to remember that the PCI bus has a total aggregate bandwidth of 133MB/s. If you're using an older computer (please post specs), then the disk controllers and such may also be on the PCI bus, even if you don't physically have a controller card in a PCI slot.
I thought I had posted the specs, but I see that was on another thread. They're here. I don't remember what all is on the PCI bus, but I do know the LAN is not, it's a CSA LAN. The 3rd-party Promise SATA controller is on the PCI bus, but it's disabled. I would also "guess" the Native 1394a FW400 is on the PCI bus, but it's not being used, nothing was connected to it when I was using the 1394b PCI card.

There's one Native IDE connector (which I guess is on the PCI bus), to which is an optical drive, of course it's not being used during 1394b tests. There's two Native Intel ICH5 SATA connectors (being used) and I don't think those are on the PCI bus.


Does your motherboard support PCI Express? If so, I would suggest returning the PCI 1394b card and getting a PCIe one. Even a version 1.0 PCIe x1 slot would have more than enough bandwidth for your 1394b card.
No it doesn't have PCI-e.


You mentioned having an image-based backup solution. Why don't you make an image of XP, install Windows 7 (no product key needed for first 30 days), and see what happens?
I did?? I think you may be talking about "restore" that I mentioned. ? That was just an ERUNT restore. But I do have Ghost which can create an image.

Even if Win7 was faster, I still can't use it due to all of my software, programs, and drivers only being for XP.

Having a rather "obsessive" personality about certain things like this, and never wanting to give up, I decided to start all over again. Reading all the user reviews for 1394b cards at NE, and reading all the manuals for the 1394b cards, I learned a few things. It would seem most of these controller cards either come with the Unibrain drivers, or the manufacturer actually "suggests" downloading the Unibrain drivers (if they don't come with the card). In the case of them not coming with the card and they are linked at the manufacturers' websites, on some occasions they were even linked as "FireWire 800 drivers" or something like that.

And again, in reading the reviews I saw that many mentioned Unibrain drivers having to be used in order to get FW800 or "faster" speeds*. On one of the Syba cards, someone from Syba TS actually responded to one of the reviews saying, (to paraphrase), "3rd party drivers are available for FW800 from Unibrain".

I also saw in some of the manuals that the drivers should be installed first before the card is installed.

Like I said, I tried the Unibrain drivers and they didn't work any better, and the card's original drivers are by OrangeWare (which also claims FW800 speeds). BTW, my card is only a 32-bit card. Many of these cards say they work in both a 32 or 64-bit slot. So since some of the cards are indeed 32-bit, and claim FW800, it would seem a 64-bit slot isn't really required.*

So this all points to actual FW800 speeds being possible on XP (after SP1).

I'm going into details so that this may help others trying to do the same thing.

I uninstalled the card/drivers from the Device Manager (both the 1394 and LAN portions of it, LAN was "Disabled"), I uninstalled the Unibrain drivers, then did the restore.

Then I first installed the Unibrain drivers. They "complain" about not being able to find something via 2 yellow marks in the Device Manager for "Unibrain PC". I put the card in a different PCI slot (slot #5, is only shared with slot #1 which has never been used), the started the PC. The yellow marks were resolved.

Drag 'n copy timed tests were previously inconsistent, probably because the HD was about 60% full, and we all know that even after defrag'ing files can still be all over the place and actually vary from time-to-time. So I reformatted the HD and left it empty.

After installing the drivers, I checked all "1394" areas in the Device Manager and saw no mention whatsoever of "1394b" for any of the entries' Properties dialogs.

After installing the drivers, in the Program Files folder for Unibrain, there's a "Tools" folder and a "ubSwitch" app. Clicking that puts an icon in the System Tray which gives one the ability to actually immediately switch between M$ and Unibrain drivers on-the-fly via left or right click. It would appear that by default, M$ drivers are used for one of the entries. I had two for some reason; "OHCI compatible board" and "IEEE 1394b (FireWire 800) adapter". The latter defaults to the M$ drivers. I made both Unibrain, and then the DM showed "1394b" and "FireWire 800" as a description for one of the areas, "1394 bus host controller".

I then proceeded to do the (synthetic) benchmarks again with the 1394b tests of course being on the controller card, but with the 1394a tests being on my mobo's integrated 1394a controller. (I wanted to give 1394a an even better shot at being fast, see post #6 above for details). As before, 1394b was significantly faster than 1394a. So I then did the "real world" right click drag 'n "copy" and drag and "move" timed tests. I also did the right click and drag 'n copy tests on the drive itself, so the target HD would be doing both the reading and writing at the same time (a good torture test for a HD since those times are usually slower).

This time, unlike before, the 1394b tests were a good bit faster. I haven't done all the math yet, but it would appear the timed tests are anywhere from 30 to 50% faster for 1394b, depending on the type of test. For one example (same for 3 tries), dragging a 2.91gb folder of .rar files from my HD103SJ to the FW HD (write) took 110 secs for 1394a and 71 secs for 1394b. That's about 26.45MB/sec Vs. 41MB/sec, and those are pretty impressive for write times. Right click, drag, and "Move"(ing) the folder back to the HD103SJ was 97 secs for 1394a and 88 secs for 1394b.

Where 1394b really shined, was copying the folder onto itself; right click, drag, and "copy here" in the same root directory. 1394a took 5:12 & 5:17, 1394b took 3:34 and 3:25. That's a pretty big difference.

I then did the time tests with a more difficult 1.35gb folder consisting of all kinds of file types (116 folders, 564 files, of .txt, .html, .mht, .jpg, .gif, .bmp, .doc, .rtf, .reg, .zip, .exe, etc., etc.). Dragging and copying that folder from the HD103SJ to FW on 1394a took 52 secs (26MB/sec). 1394b took 36 secs (37.5MB/sec). (Both avg over 3 tries, all within 1 sec of each other). Then doing the right click and "copy here" for that folder (using the 1st one dragged over), 1394a was 2:24-2:30, 1394b was 1:46-1:43.

I also ran the FC-Test tests (post #12, 3rd paragraph on this thread for FC-Test explanation). This was confusing, 1394b was still faster, but not by as large of an amount like the other tests.

Previously I had not run PCMark for the FW tests, but this time I did:

PCmark04

Results shown as 1394b / 1394a (In MB/sec)

Total score: 4435 / 4053
XP startup: 8.031 / 7.635
App loading: 6.906 / 6.422
File copying: 25.315 / 19.716
General HDD usage: 5.733 / 5.392


PCmark05

Results shown as 1394b / 1394a (In MB/sec)

Total score: 4447 / 3602
XP startup: 8.068 / 7.67
App loading: 6.869 / 6.472
General HDD usage: 5.748 / 5.387
Virus scan: 47.652 / 31.870
HDD file write: 47.141 / 29.289

For those that aren't familiar with PCMark tests, tenths actually make a much larger difference on their tests than is normally the case with other benchmarks. A drive that is actually literally twice as fast as another, will not get twice as high scores.

*So the question remains, are the "faster speeds" actually really 1394b FW800 speeds, or something just in between?? In keeping with the theoretically "twice as fast speeds" going from one protocol to a newer one not ever being actually twice as fast, FW800 should not actually be twice as fast as FW400. Because SATA300 isn't anywhere near twice as fast as SATA150 and SATA6 isn't anywhere near twice as fast as SATA300. UDMA66 was not twice as fast as UDMA33, and UMDA133 is not twice as fast as UDMA66. Etc. So I might "guess" that FW800 may actually in reality maybe be only 40-50% faster than FW400, and maybe I am getting true FW800 speeds??

I'm still wondering if a different controller card (or 64-bit card) would be faster (again, see post #6 as to why), or if doing some XP driver file hacks would make it even faster. I've seen some that replaced some XP 1394 driver files with some from Vista, and got better results. I've also replaced some XP SP3 files with SP2 files to get back certain features that the M$ morons removed from SP3. So that's why I had asked about possible 1394 file changes in Win7, wondering if I could find out that list and possibly get those files and try them on XP. More so because from what I've heard the 1394b issue is still a bit of an issue on Vista.

But at least now at this point, I am getting significantly better performance with 1394b over that of 1394a on all tests. I don't know if it was due to not installing the card-supplied drivers and using the Unibrain drivers, or installing the Unibrain drivers first before installing the card, or using a different PCI slot, or a combo of all of the above. I'm more inclined to believe it was due to only using the Unibrain drivers and installing them first. (And again, be sure you put the "ubSwitch" icon in the System Tray and the Unibrain drivers are loaded).
-Clint
 

mfenn

Elite Member
Jan 17, 2010
22,400
5
71
www.mfenn.com
I thought I had posted the specs, but I see that was on another thread. They're here. I don't remember what all is on the PCI bus, but I do know the LAN is not, it's a CSA LAN. The 3rd-party Promise SATA controller is on the PCI bus, but it's disabled. I would also "guess" the Native 1394a FW400 is on the PCI bus, but it's not being used, nothing was connected to it when I was using the 1394b PCI card.

There's one Native IDE connector (which I guess is on the PCI bus), to which is an optical drive, of course it's not being used during 1394b tests. There's two Native Intel ICH5 SATA connectors (being used) and I don't think those are on the PCI bus.

No it doesn't have PCI-e.

I did?? I think you may be talking about "restore" that I mentioned. ? That was just an ERUNT restore. But I do have Ghost which can create an image.

Even if Win7 was faster, I still can't use it due to all of my software, programs, and drivers only being for XP.

<snip>wall o' text</snip>
-Clint

I was suggesting Win7 as a way to diagnose a software problem vs. a hardware limitation. It seems like you've figured out the software bit though.

You won't be able to get a 64-bit PCI card with that motherboard since it's a physically different slot.

You don't mention the specs of the drive that's in your external enclosure, so I'm going to assume that it is the WD1600JB you mention in your link. That drive probably has 80GB platters (depends on the exact model and manuf. date), in which case 41MB/s is about the best you can hope for out of the physical drive. So, congrats, problem solved! Be aware that if you upgrade to a faster drive in the enclosure, you're going to run into the PCI bus limitations that I mentioned.
 

computer

Platinum Member
Nov 5, 2000
2,735
2
0
You won't be able to get a 64-bit PCI card with that motherboard since it's a physically different slot.
The named "32-bit/64-bit" controller cards say they are for both 32 and 64-bit PCI slots. It could be they are just "confused" and are confusing that with 33mhz and 66mhz slots, or, the cards are actually 32-bit cards that can also work in a 64-bit slot. :confused: If latter is the case, then that would mean what I was told about a card having to be 64-bit card and must be used in a 64-bit slot is not true. (And apparently I've determined that's not true since 1394b is "working" for me, but again I don't know if what I'm getting is actually true 1394b speeds).


You don't mention the specs of the drive that's in your external enclosure, so I'm going to assume that it is the WD1600JB you mention in your link.
Yeah that's the one that's in the enclosure now.....

That drive probably has 80GB platters (depends on the exact model and manuf. date), in which case 41MB/s is about the best you can hope for out of the physical drive. So, congrats, problem solved! Be aware that if you upgrade to a faster drive in the enclosure, you're going to run into the PCI bus limitations that I mentioned.
...but I don't follow you there. (Areal density not withstanding) HD speed should have no bearing on this since a HD's speed is being limited, "choked", by the slower FW interface. FW (800) is limited to X MB/sec, and any relatively new HD is going to exceed that X number. That WD1600JB of course gets faster benchmarks when it's not in the enclosure. (X=100MB theoretical, 50-60% less than that actual).

The enclosure is only for IDE HD's, (I wanted to find a use for all of my IDE HD's), so the massive areal density SATA drives could not be used........unless an adapter was used....hmmm.

BTW, on PCWizard the enclosure using FW800 got 68.31MB buffered read. 75.4 burst on HDTach (48.5 avg), and 51.3 max 44.6 avg on HDTune.

Now I need to find out how to use RAID 1 on this enclosure. I didn't realize it when I ordered it, but the RAID functions for the enclosure are only for MAC!! D: That's one of the reasons I got it because I wanted to mirror two backup HD's in the enclosure. It's an Oxford 912 chipset and so far all I see is RAID info for Oxford 911 chipsets.
-Clint
 

mfenn

Elite Member
Jan 17, 2010
22,400
5
71
www.mfenn.com
The named "32-bit/64-bit" controller cards say they are for both 32 and 64-bit PCI slots. It could be they are just "confused" and are confusing that with 33mhz and 66mhz slots, or, the cards are actually 32-bit cards that can also work in a 64-bit slot. :confused: If latter is the case, then that would mean what I was told about a card having to be 64-bit card and must be used in a 64-bit slot is not true. (And apparently I've determined that's not true since 1394b is "working" for me, but again I don't know if what I'm getting is actually true 1394b speeds).



Yeah that's the one that's in the enclosure now.....


...but I don't follow you there. (Areal density not withstanding) HD speed should have no bearing on this since a HD's speed is being limited, "choked", by the slower FW interface. FW (800) is limited to X MB/sec, and any relatively new HD is going to exceed that X number. That WD1600JB of course gets faster benchmarks when it's not in the enclosure. (X=100MB theoretical, 50-60&#37; less than that actual).

The enclosure is only for IDE HD's, (I wanted to find a use for all of my IDE HD's), so the massive areal density SATA drives could not be used........unless an adapter was used....hmmm.

BTW, on PCWizard the enclosure using FW800 got 68.31MB buffered read. 75.4 burst on HDTach (48.5 avg), and 51.3 max 44.6 avg on HDTune.

Now I need to find out how to use RAID 1 on this enclosure. I didn't realize it when I ordered it, but the RAID functions for the enclosure are only for MAC!! D: That's one of the reasons I got it because I wanted to mirror two backup HD's in the enclosure. It's an Oxford 912 chipset and so far all I see is RAID info for Oxford 911 chipsets.
-Clint

Throughput in Enclosure = min(PCI bus max throughput, Firewire max throughput, HDD speed * (1 - ATA<->FW overhead))

41 MB/s is a reasonable result for the WD1600JB in an enclosure. "Thankfully though, the WD1600JB's average sequential transfer rate was the second fastest we saw - only the Hitachi 7K250 was faster. It turned in a respectable 48.6MB/sec and managed 55.5MB/sec in its outer zones." [http://www.bit-tech.net/custompc/labs/50179/western-digital-wd1600jb.html].

You only mentioned doing filesystem-level benchmarks, ergo you don't know where on the disk you took your sample from. Try out HDTune or HDTach and look at the performance characteristics across the entire LBA space.
 
Last edited:

computer

Platinum Member
Nov 5, 2000
2,735
2
0
You only mentioned doing filesystem-level benchmarks, ergo you don't know where on the disk you took your sample from. Try out HDTune or HDTach and look at the performance characteristics across the entire LBA space.
I did, I mentioned those in my post above. ;) Also PCMark in post #19.
-Clint
 
Last edited:
Nov 26, 2005
15,188
401
126
My guess is your 1394a wasn't bottlenecking your through-put. What is the native connectors to the hard-drive? And which hard-drive are you using?