-
Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.
SE/30 booting off CF success
- Thread starter IamSpartacus
- Start date
AFAIK, none that is advertised. If you're getting 600KB/s with polled transfers, you've got a relatively slow card, as a SanDisk UltraII with the Apple HD SC Setup's driver can exceed that with 4KB blocks, increasing to twice that speed with 128KB and greater transfer sizes. Even if your card is fast enough for most writes, you may find that when wear leveling kicks in, the card's transfer speeds drop way down for a short period of time causing blind transfers to go sideways.
For SCSI controllers that don't support hardware handshaking, you'll not just experience issues with reads causing hangs and general instability, but data on the CF card will probably be corrupted. When doing a blind write, when the controller isn't ready and the driver writes to it, those bits are lost. They never make it to the SCSI bus and subsequently the card, but the driver thinks they did, reporting success to the higher levels. Same thing with reads, when doing blind reads, if the bits aren't ready and you do the read, you're reading garbage.
So, you could be reading garbage because the SCSI controller wasn't ready, or it could be because garbage was written to the card and the read was successful.
Even though your microdrive CF card seems to be doing OK, it's only a matter of time before corruption and instability creep in. For these older SCSI controllers, it's not really a good idea to be doing blind transfers with data that matters. Or at the very least, it needs to be verified, the overhead of which usually nullifies the performance advantage of using blind transfers.
For SCSI controllers that don't support hardware handshaking, you'll not just experience issues with reads causing hangs and general instability, but data on the CF card will probably be corrupted. When doing a blind write, when the controller isn't ready and the driver writes to it, those bits are lost. They never make it to the SCSI bus and subsequently the card, but the driver thinks they did, reporting success to the higher levels. Same thing with reads, when doing blind reads, if the bits aren't ready and you do the read, you're reading garbage.
So, you could be reading garbage because the SCSI controller wasn't ready, or it could be because garbage was written to the card and the read was successful.
Even though your microdrive CF card seems to be doing OK, it's only a matter of time before corruption and instability creep in. For these older SCSI controllers, it's not really a good idea to be doing blind transfers with data that matters. Or at the very least, it needs to be verified, the overhead of which usually nullifies the performance advantage of using blind transfers.
tt
Well-known member
Maybe I should elaborate on instability. It is what iamspartacus saw where the write benchmarking will not proceed due to an unexplained error. Also, when copying files over to the CF drive, the finder will say there is a write error. So in a way there is some checking going on for the system to know. It's not like I copy a file over and then try to open it and it is unreadable. I copied over a whole system folder over to the microdrive with blind writes enabled and have been able to boot with it several times.
The other card I am using is a maxell 8GB 400X UDMA CF card, which at least on paper should be equivalent to a SanDisk Extreme (60MB/s). You would think most current mid-grade cards would be able to max out the SE/30 SCSI bus (read and write) in benchmarking without messing around with the drivers, but it seems like no one has been successful so far.
I did do a boot comparison (OS 7.1) between the microdrive and maxell and the maxell won at 27.6 vs 32.2 seconds.
The other card I am using is a maxell 8GB 400X UDMA CF card, which at least on paper should be equivalent to a SanDisk Extreme (60MB/s). You would think most current mid-grade cards would be able to max out the SE/30 SCSI bus (read and write) in benchmarking without messing around with the drivers, but it seems like no one has been successful so far.
I did do a boot comparison (OS 7.1) between the microdrive and maxell and the maxell won at 27.6 vs 32.2 seconds.
There's a driver Verify operation that the Finder uses to verify the write. Interestingly, this verify operation is independent of read & write at the driver level, in case a device has the ability to verify data contents more efficiently than simply reading the data back off the media and doing a compare. Imagine all those Finder copies to bad floppies where it was able to write the data to the floppy, but since the floppy is bad, the data is actually garbage.
So, that's why you're seeing errors reported. However, not all reads & writes are verified. And not all reads & writes will fail, it's the luck of the draw, that's what makes it such a terrible idea to be using blind transfers on these old SCSI controllers. Eventually, something will do a write without verify and the write will fail and you've got corruption. It's possible this is happening even with the error being detected, since creating a new file alters the filesystem metadata, requiring writes which AFAIK are not verified. Finder writes the data to the file, which is verified and catches an error. Then, if the Finder deletes the file, that requires more filesystem metadata changes, again unverified AFAIK. Each write on the system is an opportunity for failure when using blind transfers.
On newer SCSI controllers, it's great! You take advantage of hardware handshaking, it's faster, reliable, and it reduces the CPU utilization required to poll the SCSI controller for availability.
Once you've managed to copy a System to the drive successfully, actually booting doesn't really do much in the way of writes, so I'd expect booting to be fine, at least initially. Through eventual use, it's possible you'll get filesystem metadata corruption that would prevent booting, or, depending on what failed when & where, you may develop other symptoms. Who knows? That's the nature of intermittent failures, and why intermittent failures are so much worse than consistent failures IMO.
For your CF card, one thing I've noticed between "fast" consumer grade cards, and the more expensive "extreme" or professional grade cards is with wear leveling. Frequently the "fast" consumer grade cards might really be fast some or even most of the time, but with sustained writes, wear leveling will kick in and while the card is rearranging its self, operations are suddenly slow. When it's done, things pick up again. Wear leveling can kick in with any write operation, I just notice it more with sustained writes more than shorter writes. When using these cards as primary storage on faster, more modern systems it's more pronounced, and you'll notice the entire system hiccup from time to time when this happens. The higher end cards seem to have better controllers capable of doing wear leveling in the background with minimal effect on sustained transfers. I can't say this is your problem, it is merely one behavior I have observed, and in my experience it is a common behavior. YMMV, of course.
So, that's why you're seeing errors reported. However, not all reads & writes are verified. And not all reads & writes will fail, it's the luck of the draw, that's what makes it such a terrible idea to be using blind transfers on these old SCSI controllers. Eventually, something will do a write without verify and the write will fail and you've got corruption. It's possible this is happening even with the error being detected, since creating a new file alters the filesystem metadata, requiring writes which AFAIK are not verified. Finder writes the data to the file, which is verified and catches an error. Then, if the Finder deletes the file, that requires more filesystem metadata changes, again unverified AFAIK. Each write on the system is an opportunity for failure when using blind transfers.
On newer SCSI controllers, it's great! You take advantage of hardware handshaking, it's faster, reliable, and it reduces the CPU utilization required to poll the SCSI controller for availability.
Once you've managed to copy a System to the drive successfully, actually booting doesn't really do much in the way of writes, so I'd expect booting to be fine, at least initially. Through eventual use, it's possible you'll get filesystem metadata corruption that would prevent booting, or, depending on what failed when & where, you may develop other symptoms. Who knows? That's the nature of intermittent failures, and why intermittent failures are so much worse than consistent failures IMO.
For your CF card, one thing I've noticed between "fast" consumer grade cards, and the more expensive "extreme" or professional grade cards is with wear leveling. Frequently the "fast" consumer grade cards might really be fast some or even most of the time, but with sustained writes, wear leveling will kick in and while the card is rearranging its self, operations are suddenly slow. When it's done, things pick up again. Wear leveling can kick in with any write operation, I just notice it more with sustained writes more than shorter writes. When using these cards as primary storage on faster, more modern systems it's more pronounced, and you'll notice the entire system hiccup from time to time when this happens. The higher end cards seem to have better controllers capable of doing wear leveling in the background with minimal effect on sustained transfers. I can't say this is your problem, it is merely one behavior I have observed, and in my experience it is a common behavior. YMMV, of course.
tt
Well-known member
Here is another update to performance tweaking. I did a format with Intech Speed Tools and was able to get stable fast read speeds, but write speeds are still slow. The results I am guessing are similar to Iamspartacus' results. I have not seen anything in the way of further under the hood tweaking for the program. The only options are the ones I find here:
The options available don't have any appreciable impact on the benchmark. Here it is:
I guess this is the best compromise so far for performance. I am thinking either the drivers for this application need to be further tuned, or faster CF cards are needed to brute-force speed gains for writes.
The options available don't have any appreciable impact on the benchmark. Here it is:
I guess this is the best compromise so far for performance. I am thinking either the drivers for this application need to be further tuned, or faster CF cards are needed to brute-force speed gains for writes.
brayne
Well-known member
Hi all, I'm new to this forum, and have just started reading this thread and am fascinated by it. I would love to try this myself.
Are these I-O DATA R-IDSC SCSI to IDE adapters readily available? Looking at their site, it looks like they are discontinued. Does anyone have any idea where one can be obtained from?
I did see one on ebay, but it was going for $280 USD (buy it now). That seems a little... um... steep. Is that what I can expect to have to pay for one of these?
My apologies if this has been covered elsewhere in the topic/forum.
Thanks,
brayne
Are these I-O DATA R-IDSC SCSI to IDE adapters readily available? Looking at their site, it looks like they are discontinued. Does anyone have any idea where one can be obtained from?
I did see one on ebay, but it was going for $280 USD (buy it now). That seems a little... um... steep. Is that what I can expect to have to pay for one of these?
My apologies if this has been covered elsewhere in the topic/forum.
Thanks,
brayne
johnklos
Well-known member
brayne,
I-O DATA adapters aren't easy to come by, but Acard adapters are still made, plus the price for new adapters really isn't all that bad. Check them out:
http://www.acard.com/
I use many in all sorts of different machines such as VAXen, Amigas, m68k Macs and PowerMacs. I've never had a problem with any of them once they're up and running.
I-O DATA adapters aren't easy to come by, but Acard adapters are still made, plus the price for new adapters really isn't all that bad. Check them out:
http://www.acard.com/
I use many in all sorts of different machines such as VAXen, Amigas, m68k Macs and PowerMacs. I've never had a problem with any of them once they're up and running.
tt
Well-known member
bbruan, I think you are onto something here. I have been looking into industrial flash cards and SLC based flash CF cards and they seem to be better performers [~1.6MB read and ~.5MB/s write], but only an incremental improvement. Being designed for embedded systems, they might be paying attention to more OS-like use than dumping data to and from the card like a camera would. I would like to try out some obscure ones, but the $/GB is not very favorable.
I/O benchmarks: http://www.tomshardware.com/reviews/compactflash-600x-memory-card,2562-9.html
tt
Well-known member
bbruan, I think you are onto something here. I have been looking into industrial flash cards and SLC based flash CF cards and they seem to be better performers [~1.6MB read and ~.5MB/s write], but only an incremental improvement. Being designed for embedded systems, they might be paying attention to more OS-like use than dumping data to and from the card like a camera would. I would like to try out some obscure ones, but the $/GB is not very favorable.
I/O benchmarks: http://www.tomshardware.com/reviews/compactflash-600x-memory-card,2562-9.html
I take most benchmarks with a grain of salt. They can be useful for comparing things, but if a system "feels" faster but benchmarks lower, what really matters? The benchmark numbers or how the system feels? A more real world benchmark for disk performance can be done manually with a stopwatch. Time a few cold boots, copy a large file, load a few disk intensive applications. Time the sort of stuff you actually *do* regularly when you use the computer. The result is more meaningful than a synthetic benchmark.
Similar threads
