Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Floppy via USB slow
120 views
Skip to first unread message
James Harris
Mar 23, 2020, 7:07:35 AM3/23/20
to
I recently had occasion to run some floppy code which prints a dot for
every sector it reads. That made it quite apparent that some machines
were fast. The dots zipped across the screen.
But some machines were quite a bit slower. In their case the dots came
out at a plodding pace.
I think what made the difference was that the slow machines had their
floppy drives connected via USB whereas the fast ones were generally the
older machines which had floppy drives built in.
Just out of interest during the lockdown ... does it sound right to you
guys that floppy access over USB could be a lot slower?
--
James Harris
every sector it reads. That made it quite apparent that some machines
were fast. The dots zipped across the screen.
But some machines were quite a bit slower. In their case the dots came
out at a plodding pace.
I think what made the difference was that the slow machines had their
floppy drives connected via USB whereas the fast ones were generally the
older machines which had floppy drives built in.
Just out of interest during the lockdown ... does it sound right to you
guys that floppy access over USB could be a lot slower?
--
James Harris
peter....@gmail.com
Mar 23, 2020, 7:59:45 AM3/23/20
to
James Harris wrote:
> Just out of interest during the lockdown ... does it sound right to you
> guys that floppy access over USB could be a lot slower?
>
Yes. I'm only guessing. But I think it might be that the BIOS and the hardware doesn't communicate very effectively. There's floppy BIOS, USB and the floppy motors/head. And USB might produce some breaks/delays in the communications. In other words: The communication between the floppy BIOS and the drive is more indirect.
> Just out of interest during the lockdown ... does it sound right to you
> guys that floppy access over USB could be a lot slower?
>
Greetings
Peter
T. Ment
Mar 23, 2020, 11:58:57 AM3/23/20
to
On Mon, 23 Mar 2020 11:07:32 +0000, James Harris wrote:
> out of interest during the lockdown ...
Where I live, schools are closed and restaurants are limited to take out
> out of interest during the lockdown ...
service, but life goes on.
Helps when you don't live on poop street in a liberal atheist city.
James Harris
Mar 24, 2020, 7:16:36 AM3/24/20
to
a delay in floppy IO which is small but still large enough that by the
time of the subsequent sector read the target sector has gone past the
head. So USB reads at the rate of one sector per revolution instead of
the 9 or 18 or whatever the number of sectors per track is that direct
floppy control reads at.
--
James Harris
Kerr-Mudd,John
Mar 27, 2020, 8:15:39 AM3/27/20
to
On Mon, 23 Mar 2020 15:58:55 GMT, T. Ment <t.m...@protocol.invalid>
wrote:
KF
--
Bah, and indeed, Humbug.
wrote:
--
Bah, and indeed, Humbug.
Rod Pemberton
Apr 3, 2020, 5:55:20 AM4/3/20
to
On Mon, 23 Mar 2020 11:07:32 +0000
Info collected from some websites:
(not from ATA/ATAPI specifications)
Teac 1.44MB floppy - 62.5Kbps
Sony 3.5" floppy EIDE - 12Mbps
IDE - 8.3Mbps
EIDE - 3.3Mbps to 16.6Mbps
USB 1.0 - 1.5Mbps
USB 1.1 - 12Mbps
USB 2.0 - 480Mbps
USB 3.0 - 5Gbps
USB 3.1 - 10Gbps
If you're used to a fast EIDE floppy and using slow USE 1.0, maybe ...
I think the Teac was typical, so it seems unlikely USB is the problem.
Rod Pemberton
--
"You wanted in and now you're here, driven by hate, consumed by fear."
James Harris
Apr 4, 2020, 4:11:29 AM4/4/20
to
I've just tried to time how long it took to read about 80 sectors (a
line's worth of dots) on two machines, one via USB and one direct.
On a 1.8GHz PC via USB it took 15 seconds. I think that's about 2.5k per
second, well within the limits of you describe above.
By contrast, on an old 486 with its CPU running at just 0.1GHz the dots
zip across the screen too fast to be timed! If I say they take about a
second that would be a data rate of 40k per second.
My guess is that the reason the USB version is so slow is that USB
processing latency causes the delays.
I have a vague memory that USB works or worked by picking up tasks at
1ms intervals. As the code under test reads one sector at a time the
extra latency between one sector and the next could be enough that by
the time the floppy controller receives the next command the requested
sector has already passed the read head. Hence it would read only one
sector per rotation.
--
James Harris
James Harris
Apr 4, 2020, 5:51:27 AM4/4/20
to
On 04/04/2020 09:11, James Harris wrote:
...
> On a 1.8GHz PC via USB it took 15 seconds.
...
> Hence it would read only one sector per rotation.
Just checking the maths of that, floppy rotation rate 300 RPM is 5
revolutions per second meaning 200ms per revolution. Then 80 revolutions
would take 80 * 0.2s = 16 seconds ... which matches the timing above. I
think that confirms a latency problem.
There are some interesting findings here.
The good news is that a floppy bootloader could load an OS as simply as
possible, i.e. a sector at a time, and still get maximum load speed.
But the bad news is that where there's a chance that the floppy could be
connected via USB a machine could be turgidly slow.
How slow? Scaling the above up let's say the image which has to be
loaded is 400k in size or 800 sectors. Loading it would take 160 seconds
or more than two minutes. :-(
So a floppy bootloader would really need to read a track at a time. And
if the boot sector at 512 bytes doesn't have enough space to do that
then it would have to load another program which in turn would load the
OS image.
As a well-behaved loader will follow the FAT chain the consecutive
sectors of the image may not be in consecutive sectors on the diskette.
So there is really a caching function being carried out. In particular,
once a track has been loaded it's best to keep it in memory in case a
later sector is on that track.
And the challenges increase in that in real mode the memory available
for caching will decrease as the image is loaded!
But maybe there is an even wider point that goes beyond the initial
load. Since any floppy could be connected via USB a running OS should
probably nearly always read floppies a track at a time. The only
exception might be if there's a need to read just one sector and/or if a
certain track has a damaged sector on it.
Challenges aplenty!
--
James Harris
...
> On a 1.8GHz PC via USB it took 15 seconds.
> Hence it would read only one sector per rotation.
revolutions per second meaning 200ms per revolution. Then 80 revolutions
would take 80 * 0.2s = 16 seconds ... which matches the timing above. I
think that confirms a latency problem.
There are some interesting findings here.
The good news is that a floppy bootloader could load an OS as simply as
possible, i.e. a sector at a time, and still get maximum load speed.
But the bad news is that where there's a chance that the floppy could be
connected via USB a machine could be turgidly slow.
How slow? Scaling the above up let's say the image which has to be
loaded is 400k in size or 800 sectors. Loading it would take 160 seconds
or more than two minutes. :-(
So a floppy bootloader would really need to read a track at a time. And
if the boot sector at 512 bytes doesn't have enough space to do that
then it would have to load another program which in turn would load the
OS image.
As a well-behaved loader will follow the FAT chain the consecutive
sectors of the image may not be in consecutive sectors on the diskette.
So there is really a caching function being carried out. In particular,
once a track has been loaded it's best to keep it in memory in case a
later sector is on that track.
And the challenges increase in that in real mode the memory available
for caching will decrease as the image is loaded!
But maybe there is an even wider point that goes beyond the initial
load. Since any floppy could be connected via USB a running OS should
probably nearly always read floppies a track at a time. The only
exception might be if there's a need to read just one sector and/or if a
certain track has a damaged sector on it.
Challenges aplenty!
--
James Harris
David Cooper
Apr 4, 2020, 1:28:34 PM4/4/20
to
It's worth looking at the sector order on a track. I have some disks which have been formatted in an interleaved way such a way that it takes two rotations to read them all in the right order: they come in the order 1, 10, 2, 11, 3, 12, 4, 13, 5, 14, 6, 15, 7, 16, 8, 17, 9, 18. With those disks, USB may load them twice as fast as normal by spinning the disk twice as fast and still having time to set up the next sector load each time while skipping the one in between, but if the disk is formatted with sectors in consecutive order, it's likely that setting up the USB stuff for each track is too slow, as you (JH) said above, leading to one rotation for each sector read.
There's also a long gap after the final sector so that 18 tracks will still fit on a disk even if it's formatted by a drive with a motor that's running a few percent faster than average, so that may eliminate any extra lap needed between reading opposite sides for the same track.
My code for using a USB floppy via the BIOS (both for reading and writing) avoids the problem by using commands to load multiple sectors whenever data from consecutive sector numbers is wanted, but missing out any in between that aren't needed - this avoids the need to load entire tracks and then pick sections out of them afterwards, but I don't think it makes a lot of difference which way you do it as you're going to have a buffer big enough to hold an entire track anyway, so it doesn't cost you any space.
[I haven't used a USB floppy drive for a few years though because I switched to flash drives (still using the BIOS for loading and saving), but I have a special kind of partition on each of those which is divided up into lots of 1.5MB subpartitions, each of which can hold a floppy disk image, and they can all be booted too (each can serve as a bootloader for any other). This allows me to keep hundreds (or potentially thousands) of old versions of my OS on a flash drive and to boot up any one of them, but I can also copy any of them back onto an actual floppy disk and boot it from there - the VBR can handle both CHS and LBA loading and simply checks the drive number to know which to use. My MBR on the flash drives can boot the FAT 32 partition if it's marked as bootable, but it also allows me to select the first or most recent disk image in my multi-floppy partition, so if the latest version is faulty and won't boot, I can boot the first one instead and then boot the second most recent before using that to fix the broken one. This is much better than going on grinding floppy drives and it's well worth going to the trouble of setting up such a system so that you can make a transition away from working on equipment that belongs in a museum. Importantly though, when saving to flash drives in this way, the BIOS can cause extreme wear, so I always save 64 sectors at a time and align them carefully - to save a 1/2 megabyte block takes 16 writes as the entire block is written 16 times due to the way the drive itself can't write less than that to its flash memory in one go, so that's a lot of wear, but it would be many times that if you were to write a sector here, a sector there, etc. - indeed, if you were to write every second sector in a block, each with its own BIOS call, that would write the entire half megabyte block five hundred times, which would be highly damaging to any flash memory device. Therefore, when writing to a subpartition, I load the entire subpartition into a buffer, then save sectors to that instead, and then I write back to the flash drive only the 64K subblocks that have been altered during that process, although in most cases I actually just write the whole buffer to an empty subpartition as there are plenty of them, and usually on a different flash drive to guard against losing too much if one of them fails, and that means I always have backups of the previous version of everything. Good brands (e.g. Sandisk: I use the tiny ones that only stick a few millimetres out from the machine) have no trouble with 16 consecutive writes to the same block, and I've reused some of the same spaces a few times, leading to some subpartitions being written to 48 or 64 times in total, although it may be that the drive is switching different memory blocks in once a block's been written to too many times, but I'm sure that it can cope with a good bit more than sixteen writes to every block on the drive on average if it has to. I never use the BIOS to write to the FAT 32 partition though because that would lead to excessive wear - that will have to wait until I have reliable USB drivers of my own and can save anything with only one write to each half megabyte block. I don't miss having that box on a cable hanging off the side of my machine - flash drives are the way to go.]
There's also a long gap after the final sector so that 18 tracks will still fit on a disk even if it's formatted by a drive with a motor that's running a few percent faster than average, so that may eliminate any extra lap needed between reading opposite sides for the same track.
My code for using a USB floppy via the BIOS (both for reading and writing) avoids the problem by using commands to load multiple sectors whenever data from consecutive sector numbers is wanted, but missing out any in between that aren't needed - this avoids the need to load entire tracks and then pick sections out of them afterwards, but I don't think it makes a lot of difference which way you do it as you're going to have a buffer big enough to hold an entire track anyway, so it doesn't cost you any space.
[I haven't used a USB floppy drive for a few years though because I switched to flash drives (still using the BIOS for loading and saving), but I have a special kind of partition on each of those which is divided up into lots of 1.5MB subpartitions, each of which can hold a floppy disk image, and they can all be booted too (each can serve as a bootloader for any other). This allows me to keep hundreds (or potentially thousands) of old versions of my OS on a flash drive and to boot up any one of them, but I can also copy any of them back onto an actual floppy disk and boot it from there - the VBR can handle both CHS and LBA loading and simply checks the drive number to know which to use. My MBR on the flash drives can boot the FAT 32 partition if it's marked as bootable, but it also allows me to select the first or most recent disk image in my multi-floppy partition, so if the latest version is faulty and won't boot, I can boot the first one instead and then boot the second most recent before using that to fix the broken one. This is much better than going on grinding floppy drives and it's well worth going to the trouble of setting up such a system so that you can make a transition away from working on equipment that belongs in a museum. Importantly though, when saving to flash drives in this way, the BIOS can cause extreme wear, so I always save 64 sectors at a time and align them carefully - to save a 1/2 megabyte block takes 16 writes as the entire block is written 16 times due to the way the drive itself can't write less than that to its flash memory in one go, so that's a lot of wear, but it would be many times that if you were to write a sector here, a sector there, etc. - indeed, if you were to write every second sector in a block, each with its own BIOS call, that would write the entire half megabyte block five hundred times, which would be highly damaging to any flash memory device. Therefore, when writing to a subpartition, I load the entire subpartition into a buffer, then save sectors to that instead, and then I write back to the flash drive only the 64K subblocks that have been altered during that process, although in most cases I actually just write the whole buffer to an empty subpartition as there are plenty of them, and usually on a different flash drive to guard against losing too much if one of them fails, and that means I always have backups of the previous version of everything. Good brands (e.g. Sandisk: I use the tiny ones that only stick a few millimetres out from the machine) have no trouble with 16 consecutive writes to the same block, and I've reused some of the same spaces a few times, leading to some subpartitions being written to 48 or 64 times in total, although it may be that the drive is switching different memory blocks in once a block's been written to too many times, but I'm sure that it can cope with a good bit more than sixteen writes to every block on the drive on average if it has to. I never use the BIOS to write to the FAT 32 partition though because that would lead to excessive wear - that will have to wait until I have reliable USB drivers of my own and can save anything with only one write to each half megabyte block. I don't miss having that box on a cable hanging off the side of my machine - flash drives are the way to go.]
0 new messages