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]

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

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

-brendan

[bhoar]

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]

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]

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]

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]

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]

Have you tested the USB bridge inside the Plextor enclosures?

[bhoar]

Have you tested the USB bridge inside the Plextor enclosures?

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

-brendan

[EliC]

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]

Here is the type of enclosure I am refering to:

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

http://i1.ebayimg.com/08/i/000/c9/8b/12c3_2.JPG

[EliC]

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]

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]

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]

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

[bhoar]

Spoon,

Any updates on the IO re-rigging to stop triggering the failed firewire transactions when C2 is enabled?

-brendan

[bhoar]

I suspect if you just make sure that, when you split a large read request into two, the first half of the split read is an even number of sectors, the current code base will start working with just that simple modification.

e.g. instead of request for 26 sectors being split into a read 13 + a read 13, you make the first read an even number, e.g. "a read 14 + a read 12". The second half can be an odd number if necessary. It's a one or two line change (every place in the code you have to split) to force quad-byte alignment, which is probably good enough for most interfaces.

Even if your long term plan is to "4k page align" all buffers and no longer send mid-buffer pointers down the call stack, the idea above is a good stop-gap if you're concerned about substantial infrastructure breakage.

Again, this alignment issue only comes up when C2 is used, since the number of bytes returned per request is no longer "naturally" quad aligned. And it's only a problem for firewire (and perhaps some SATA controllers) because those controllers have stricter alignment requirements and/or use the pointer as passed after translation (i.e. the virtual address for the user process is translated directly into a physical address passed to the hardware because the call stack does not double buffer).

-brendan

[Spoon]

I will be working on the 4KB align next week.

[bhoar]

I will be working on the 4KB align next week.

<< celebration! >>

-brendan