Bridge Testing Fiasco

[bhoar]

I set up eight optical drives in a specialty hot-swap tower for testing bridge board + drive combinations for what features worked and which combinations were stable.

Well, the tower was shipped configured for 240V instead of 120V.

So, half of my bridge boards just died. Sadly, I'd put in the ones that were most likely to work, so now I've got a pile of dead bridge boards and known incompatible bridge boards.

Sniffle.

-brendan

[bhoar]

Re: Bridge Testing Fiasco

For now, I'm updating the bridge testing results here:

http://hyperdiscs.pbwiki.com/Hardware%20--%20Bridges

-brendan

[bhoar]

Re: Bridge Testing Fiasco

For now, I'm updating the bridge testing results here:

http://hyperdiscs.pbwiki.com/Hardware%20--%20Bridges

-brendan

Just an update.

I have an initial set of success/fail tests on at the page listed above, of course.

Summary - I couldn't get the two different firewire chipset bridges to work with C2 at all, but had some good luck with the ALi and NEC chipset USB bridges.

Big Bonus(?):

My frustration on this led to a bit of detective work on my part over the past week and a half, which may have uncovered the source of the C2 problems over firewire. The initial evidence I collected:

- EAC has no problems with C2 over firewire with the bridges
- Nero Disc Speed has no problems either.

So, really, this doesn't seem to be a hardware issue, at least, not an external hardware issue.

I then dug deeper, with some help:

- Spoon emailed a couple of short code snippets that show how the difference on how his C2-enabled and C2-disabled read requests are handled
- I researched documentation and discussions of IOCTL_SCSI_PASS_THROUGH vs. IOCTL_SCSI_PASS_THROUGH_DIRECT from microsoft.com and in microsoft-related forums.
- I performed traces using Bushound (with some very helpful input from Paul at Perisoft)
- I performed experiments using plscsi's -X spt, -X sptd, and --align options (specifically -X sptd --align x02 vs. -X sptd --align x04)
- I BSOD'd my work machine twice (oops).
- I annoyed the stuffing out of spoon via email (well, I only guess I did, he seems fine about it...so far).

According to Spoon, cdgrab.exe uses the IOCTL_SCSI_PASS_THROUGH_DIRECT function, which, from what I have read, passes the user buffer pointer directly down the stack instead of double or bounce buffering data. This can be faster for large IO transfers.

There's some controversy about using the _DIRECT call vs. the one that doesn't have _DIRECT at the end, but I'll skip over that for now.

When the number of frames that cdgrab.exe wants exceeds a certain threshold (for some other hardware compatibility reasons?) the code breaks the read into two smaller reads, the first with a pointer to the beginning of the buffer, and more importantly, the second with a pointer to next available address in the buffer not used by the results of the first read.

I believe it is not the firewire bridge chipsets at issue or even firewire itself, but rather a sneaky pointer-alignment requirement that wasn't being met by the pointer passed down the driver stack from dbpoweramp in that second read. With regular CD-DA data, each frame of data return 2352 bytes, which happens to be easily divisible by either four or eight. With CD-DA data plus C2, we add 294 bytes for a total of 2646 bytes which is no longer easily divisible by either four or eight (just two). If the first read of the pair was for an odd number of frames, then on the second read of the pair, the pointer is only 2-byte aligned.

Other interfaces didn't care, but it appears that firewire and/or the SBP-2 layer does care and wants at least quad-aligned pointers.

This gives me hope that Spoon will be able to make some adjustments to the ripping and C2-testing engines in the near future (perhaps 4-8 weeks, if we clap really hard?) and that such changes may finally allow us to perform secure, C2-enhanced ripping over firewire with dbpoweramp.

-brendan

[pls1]

Re: Bridge Testing Fiasco

Other interfaces didn't care, but it appears that firewire and/or the SBP-2 layer does care and wants at least quad-aligned pointers.

Thanks for this way down in the weeds work. It would be very desirable to get the Firewire interface working with DBpoweramp.

phil

[bhoar]

Re: Bridge Testing Fiasco

Thanks for this way down in the weeds work. It would be very desirable to get the Firewire interface working with DBpoweramp.

Yup...especially in the case of the big, multi-drive robotic units (my area of interest): almost all of those are shipped with drives connected via firewire bridges.

-brendan

[EliC]

Re: Bridge Testing Fiasco

Brendan,

Any potential updates on firewire improvements or USB bridge suggestions. It looks like I am going to invest in a new motherboard for the composer max to see if it fixes the problem - not cheap at $200, but the other option is to send the unit to them and the shipping alone will probably run nearly that!

Anyway, the drives are on firewire bridges, but the bridges are completely separate from the motherboard and there is no reason they cannot be switched out for any bridge I want, including USB, though I will have to mod the case.

[bhoar]

Re: Bridge Testing Fiasco

Any potential updates on firewire improvements or USB bridge suggestions. It looks like I am going to invest in a new motherboard for the composer max to see if it fixes the problem - not cheap at $200, but the other option is to send the unit to them and the shipping alone will probably run nearly that!

Anyway, the drives are on firewire bridges, but the bridges are completely separate from the motherboard and there is no reason they cannot be switched out for any bridge I want, including USB, though I will have to mod the case.

Spoon says he's looking into my notes regarding firewire driver behavior and ways to make it work better, perhaps making changes for R13.1.

No rock-solid USB bridge recommendations yet, though the ALi bridge I tested wasn't too bad. That said, I haven't done a serious investigation into reliability over time.

An alternate approach would be to position an open-case PC at the back of the composer max and use the mainboard IDE or PCI card IDE connectors.

And yes...as I've said before the drives and the robot do not interact at all they are really separate devices. All the robot/drive coordination comes from the duplicator driver software (or in my case the ULCLI).

I've got a composer max unit on the way here, with the caveat that they now want an additional $300 to ship it freight after DHL balked...trying to get that worked out now...

-brendan

[EliC]

Re: Bridge Testing Fiasco

Have you tested the USB bridge inside the Plextor enclosures?

[bhoar]

Re: Bridge Testing Fiasco

Have you tested the USB bridge inside the Plextor enclosures?

If it's not on the wiki, i haven't tested it.

-brendan

[EliC]

Re: Bridge Testing Fiasco

The older silver metal Plextor USB cases have a chip that reads:

in-system
|SD300A1
0219KU009

and one that reads:

1CY103
SHARP
12 P7

These bridges seem to pass all C2 errors and FUA commands without any problems. I believe the 1st is the USB chipset, but dont know.

[EliC]

Re: Bridge Testing Fiasco

Here is the type of enclosure I am refering to:

http://cgi.ebay.com/Plextor-PlexWriter-PX-W4824TU-CD-RW-USB-2-0-DRIVE_W0QQitemZ280180401797QQihZ018QQcategoryZ96914QQrdZ1QQssPageNameZWD1VQQcmdZViewItem

[EliC]

Re: Bridge Testing Fiasco

I tested the above enclosure with R13 and C2 is a no go. I have used them before with PlexTools, which depends on C2, so I assumed the bridge supports C2. I don't have plextools installed at the moment to test with so I don't know for sure.

[bhoar]

Re: Bridge Testing Fiasco

I tested the above enclosure with R13 and C2 is a no go. I have used them before with PlexTools, which depends on C2, so I assumed the bridge supports C2. I don't have plextools installed at the moment to test with so I don't know for sure.

Eli,

We don't know how Plextools handles reporting C2 compatibility, so I wouldn't assume anything.

I'm waiting for R13.1, which hopefully will improve compatibility with some bridges before proceeding with more testing. You may want to try to test the enclosure against EAC and/or itunes (w/ error correction turned on). If EAC detects C2 pointers and/or itunes gives no trouble with error correction turned on, then R13.1 *may* help. If not, it is very unlikely to help.

I thought of ordering some of these to test, but I'm overloaded with equipment at the moment. If you want to try some plscsi tests, email me, I can send some suggestions.

-brendan

[EliC]

Re: Bridge Testing Fiasco

I can do some testing on it.

Also, what about eSATA and IDE to SATA bridges? This should offer the convenience of Firewire/USB with full functionality, right?

[bhoar]

Re: Bridge Testing Fiasco

I can do some testing on it.

Also, what about eSATA and IDE to SATA bridges? This should offer the convenience of Firewire/USB with full functionality, right?

One would assume. But I always assumed firewire would work better than USB. And look where that got me. So, no assuming until someone tests a bunch of different SATA->IDE bridges out, OK?

I have non-specific positive reports from a ripping house that SATA to IDE is working (via motherboard SATA sockets), but no info about the motherboard chipset nor bridge chipset in use.

-brendan