keithToday I’ve worked on optimizing the performance of the AFP reader
and have made great strides.
My original track times were nearly 475ms. This was 300ms reading the actual disk, 125ms transferring, and process times of around 50ms. This put the total disk time, not including overhead of saving the ADF which adds a half a dozen seconds, to about 76s. That’s a 1:16. Not horrible, but not great.
I’ve done a couple things:
- Reduced the number of bytes read off the disk from 15232 (14 tracks) to 14055(11 tracks + one byte short of a full sector (worst case) 1087 + 1000 byte gap(slightly bigger than I need)
- This in turn reduced the time needed to actual read the disk, from a “forced-wait”(ie my code used to just do a Thread.sleep() pause, from 300ms to 220ms (actual disk time, now)
- Less data read means less transferred, and this moved my transferred bytes from ~15238 to ~11,977. Smaller transfer is now between 94ms-110ms depending on USB scheduling.
SO this means that I’m now running actual times of about 370ms total. This is 220ms (diskread) + 102ms (average usb xfer time) + ~50ms PC processing time. A 370ms track read translates to 59.2 seconds full disk read!!
With the overhead of the floppy disk drive warming up, and saving the final ADF to the HD, this translates to an actual time of approximately 65 seconds.
My target speed for this has always been 1 minute per disk(Jan 07 post).
While there are at least a few other ways to optimize, most of them either make the code too complex, or do things in such a non-standard way that implementing them would just make maintaining and growing this code harder in the future.
The bulk of the time right now is made up by the untouchable base of 220ms. This time will never be reduced, and makes up about 60% of time I’m spending. On certain fast reads, it makes up nearly 67% of the time I’m seeing. So between 3/5 and 2/3 of the time can’t be touched.
I’m happy with this performance and won’t be addressing it again for some time. I have to move on to improving the user interface, fixing the terminal mode so it works again(after jd2xx change), reporting with and dealing with errors within the user interface (instead of standard output, where everything goes right now), and adding some odds and ends.
Good news.
More work again last night and today.
Terminal mode now works again with JD2XX. Really minor changes were necessary. Simple “Listener” style interface was compatible with what I was doing. It also works right now —- there was a problem with RXTX opening and closing the port a few times.
I now display status messages, including a line which includes transfer checksum ok, header and data checksum ok (for all sectors), and track ok. I use some abbreviations to make everything fit on one line. But this really should give people the warm and fuzzy that everything is progressing normally. Error conditions spit out a fair bit of information, and retries are automatic. I eliminated the number of retries setting — but in the future I’ll add the ability to only retry a certain number of times before going on.
This software/hardware combination is actually quite usable now. I’m pretty happy with recent progress.
hi
just for the record, with my atmel amiga floppy disk reader I need 43 seconds to read a disk. I transfer the mfm bytes in four pairs of two bits like 01 is “10”, 10 is “100” and 11 is “1000”. so four pairs of these are than transferred as a byte with 1MBit while reading.
Iam also using the MFM code from AFR. I cleaned it up alot.
denis