Tweet
This is addressed to Spoon and others with parallell ripping expertise. I have noticed some odd behaviors when ripping in parallel:
- fast ripping on only 2 or 3 out of the 6 drives connected at a time using new/clean CDs, with the other drives slowed considerably but no correlation between drives letters and the 2 or 3 that rip fast. The fastness of drives moves around during the session and doesn't seem to be correlated with the CDs in them.
- a damaged disc slowing down one drive sometimes appears to cause all other drives to slow down for a time.
- disc inserts not being recognized in a timely fashion when more than one CD is already being ripped concurrently.
I don't know how many of these issues are software related (batch/cd ripper; microsoft's filesystem, i/o, mass storage, usb drivers), hardware related (chipset; usb 2.0 bandwidth/latency/overhead/transactions per second maximums) or some mix (timing issues under load). I have seen some evidence that the problems above exist if I'm using SATA or firewire, so I don't think it's bandwidth related, and probably exists somewhere in microsoft's software stack. But it seems more touchy under USB.
That being said, I know spoon has made some recommendations about number of drives supported based on cpu cores and memory. Are there other recommendations?
In particular, I've noticed that some machines with multiple USB ports have the USB ports connected to the same USB Root Hub, while other machines have only one or two external USB ports per USB Root Hub. Sharing the same USB Root Hub is equivalent to using an external USB hub and hanging two or more drives off of it.
Whether this means that machines which have a low external ports to USB Root Hubs ratio means there's higher I/O capability in the back-end, I don't know.
Should I assume that the more USB Root Hubs you distribute your drives against, the less likely you are to encounter contention issues?
- fast ripping on only 2 or 3 out of the 6 drives connected at a time using new/clean CDs, with the other drives slowed considerably but no correlation between drives letters and the 2 or 3 that rip fast. The fastness of drives moves around during the session and doesn't seem to be correlated with the CDs in them.
- a damaged disc slowing down one drive sometimes appears to cause all other drives to slow down for a time.
- disc inserts not being recognized in a timely fashion when more than one CD is already being ripped concurrently.
I don't know how many of these issues are software related (batch/cd ripper; microsoft's filesystem, i/o, mass storage, usb drivers), hardware related (chipset; usb 2.0 bandwidth/latency/overhead/transactions per second maximums) or some mix (timing issues under load). I have seen some evidence that the problems above exist if I'm using SATA or firewire, so I don't think it's bandwidth related, and probably exists somewhere in microsoft's software stack. But it seems more touchy under USB.
That being said, I know spoon has made some recommendations about number of drives supported based on cpu cores and memory. Are there other recommendations?
In particular, I've noticed that some machines with multiple USB ports have the USB ports connected to the same USB Root Hub, while other machines have only one or two external USB ports per USB Root Hub. Sharing the same USB Root Hub is equivalent to using an external USB hub and hanging two or more drives off of it.
Whether this means that machines which have a low external ports to USB Root Hubs ratio means there's higher I/O capability in the back-end, I don't know.
Should I assume that the more USB Root Hubs you distribute your drives against, the less likely you are to encounter contention issues?
Comment