Bridge Testing Fiasco

[bhoar]

Re: Bridge Testing Fiasco

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

<< celebration! >>

-brendan

[Spoon-]

Re: Bridge Testing Fiasco

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

[bhoar]

Re: Bridge Testing Fiasco

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

[bhoar]

Re: Bridge Testing Fiasco

Spoon,

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

-brendan

[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

[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 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 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.

[EliC]

Re: Bridge Testing Fiasco

Here is the type of enclosure I am refering to:

http://cgi.ebay.com/Plextor-PlexWrit...QQcmdZViewItem

[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.

[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

Have you tested the USB bridge inside the Plextor enclosures?

[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

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

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