keithThe theoretical limit, assuming 300rpm drives, is 200ms per track. Or 400ms per cylinder, or 32 seconds per disk. Most attempts read slightly more than one track. I read 16,384 bytes, or 262ms worth.
Right now, if I continue to use the SX/B UART code, which maxes out at 230,400 bps. That puts my PC xfer code at 711 ms per track.
So that’s 262ms + 711ms = 973ms or about 1 second per track. 160 tracks or 2:40 minutes per disk. Not bad, but I’d much rather be closer to 1 minute.
I also have overhead in the PC->SX communication, and I’m currently turning the motor ON and then OFF for each track. I’ve gotta fix that. Plus, I have to wait 500ms for the drive to spin up on each attempt. Leaving the motor on all the time raises some issues, but I’ll get that in time.
ok, I hate to admit my current transfer times. But this is the worst case scenario — it will never be worse than this.
It’s currently taking me 7:36 to transfer a disk to ADF. Way way too slow.
Transdisk does the same disk in 0:45 seconds which is smoking. The theoretical max is like 0:32 seconds, so this really kicks butt.
I’m going to use Transdisk as the Gold Standard (TM) however, as you saw from the math in the post, I don’t expect to get under 2:40 per disk until I change out my UART code. I haven’t figured how I’m going to do that yet.
Realistically, I want to run my transfer code at around 2mbps, if possible, which puts the transfer at 81ms + 262ms = 343ms per track = 55 seconds total for all tracks. That’s pretty good.
Even if I run it at 1mbps, that adds another 81ms, so 162+262 = 424 ms per track = 68 seconds, which isn’t horrible.
There is going to be some additional overhead with commands, so I think I’m going to set my current goal to 2:40 + 15% = 3:04 seconds. If I can do a disk in 3 minutes, I’ll be happy in the short term.
So, short term goal is 3 minutes. Let’s see what I can do.
By leaving the motor on all the time, and shortening and removing delays throughout the code, I’m at 4:40 per disk. That’s a 3-minute improvement from earlier.
So if I subtract the disk-read time and the track transfer time, I’m still dealing with 2 extra minutes of overhead. This works out to be 750ms extra per track. Let’s figure out where that’s at!
OK I’m at 3:06 per disk.
That’s real close to my short term goal, and I think that any more serious reduction to the overall time is going to come with improving the UART transfer speed.
I can explain 2:36 of this total in reading+transferring, so that leaves 30 seconds unaccounted for. Divide that across 160 tracks, and that’s a mere 188ms per track of overhead(16%).
I have a delay of 300ms between issuing the read command and starting to receive, because if I start too early my read routine will timeout. Sure I could increase the timeout value, but then, if there was a slightly short read, I might end up running longer.
I would be willing to bet that 300 is slightly overkill. Real number is 262ms, but I wanted to add extra time to process the R command, setup, and so forth.
Even so, I’m pretty happy about a 3 minute time frame right now. I will improve upon this.
I didn’t want to have to revisit the UART stuff so soon, because its a pain in the ass, but if I want to get these times down I have no choice.
My long term goal is under 1 minute. If I transfer at 2mbps, I should be able to achieve this.
[…] My target speed for this has always been 1 minute per disk(Jan 07 post). […]