Why v5.0.x emergency floppies take so long to load ?
Radek Tomis
for root prompt to come up, but now when I'm testing several SCO machines in
a row for Y2K using TLS620 boot & root emergency floppy set, it takes at
least 18 minutes (two floppy boots) to test one machine, so the time is up
for question why it is so slow.
BTW, the Y2K test itself (/bin/check-rtc) I like, as opposed to many other
DOS/WIN Y2K test tools.
Here is one real test:
TLS620 boot + root load:
8'01" (from "Boot:" until kernel HW screen)
The same set of floppies read as "/dev/rfd0" from within TLS620 booted
kernel (v5.0.5), including disks swap and wait for floppy LED to turn off:
1'50"
The same set of floppies read as "/dev/rfd0" on SCO v5.0.0 booted
from HDD, including disks swap and wait for floppy LED to turn off:
1'55"
The same set of floppies as mounted file systems copied to ramdisk on SCO
v5.0.0 booted from HDD, including kernel and root-ramdisk decompressing,
disks swap and wait for floppy LED to turn off:
2'15"
Yes, the floppies were physically formatted with interleave 1 under DOS/WIN
(consecutive I/O: 30 KB/s) and not with default interleave 2 under SCO
(consecutive I/O: poor 18 KB/s). Here comes a side question: Why SCO uses
interleave 2 by default ? (yes, it can be changed, at least on SCO v5.0.x)
Do you think that this interleave 2, which is slower to read/write, causing
itself to be at least more reliable than interleave 1 in terms of "bad"
sectors possibly developed during the use of this floppy disk ?
Interestingly, the slow load doesn't apply for SCO v5.0.x installation boot
floppy disk (I've tried v5.0.2 boot disk only).
Does anyone know why is that ?
Perhaps because of some floppy drive compatibility issue that would cause
some machines not to load the emergency set at all ?
Thanks for any light on this.
Radek Tomis
r...@mediumsoft.cz
Bill Vermillion
<r...@mediumsoft.cz> wrote:
>Yes, the floppies were physically formatted with interleave 1 under
>DOS/WIN (consecutive I/O: 30 KB/s) and not with default interleave
>2 under SCO (consecutive I/O: poor 18 KB/s). Here comes a side
>question: Why SCO uses interleave 2 by default ? (yes, it can be
>changed, at least on SCO v5.0.x)
>Do you think that this interleave 2, which is slower to read/write,
>causing itself to be at least more reliable than interleave 1 in
>terms of "bad" sectors possibly developed during the use of this
>floppy disk ?
It all depends on the machine - and I haven't tested it recently -
however I formatted ALL my floppies under *ix and then dd'ed in a
DOS boot track, giving me disks that work on either OS. I use Unix
verify is typically stricter and will reject any disk with a bad
sector.
For those that may not be aware of the differences the DOS
disks will look for bad sectors and map them out. You'll see
this in the format reply. In Unix - most things expect to see
a flawless disk - and therefore all floppies must appear as
a perfect stream of blocks when writing to the device. (That is to
the >device<, and not a filesytem on that device.
The other reason I used Unix is that it uses a 2:1 interleave
while the factory formatted DOS disks use a 1:1 interleave.
Since MS is basically a synchronous OS (that means it does things
one at a time) it can use the CPU exclusively until it finishes
it's task.
On the test I've run on a V.3.2 system - a couple of years ago - I
found that a 1:1 interleave took about twice as long to write as it
did with a 2:1 interleave.
Using 2:1 in an MS machine means that you only blow one rev, while
using a 1:1 in _some_ Unix environment means you blow 18 revs
on each track.
>Interestingly, the slow load doesn't apply for SCO v5.0.x
>installation boot floppy disk (I've tried v5.0.2 boot disk only).
>Does anyone know why is that ?
I'd have thought by now the hardware/software had become fast
enough that everything would run 1:1 with no problems.
>Perhaps because of some floppy drive compatibility issue that would
>cause some machines not to load the emergency set at all ?
I don't think it would have anything to do with 'floppy drive
compatibility' as these are nothing more than magnetic recording
devices that are designed to a set of mechanical specs.
I'd suspect drivers and the HW Floppy interface
design/implementation on the motherboard before I'd say it was
a floppy. (However swapping floppies is often the quickest way
to verify this).
--
Bill Vermillion bv @ wjv.com
Radek Tomis
> Sent: Friday, July 16, 1999 4:18 PM
> In article <019f01becf62$30f21a30$8e0314ac@rtsnt>, Radek Tomis
> <r...@mediumsoft.cz> wrote:
>
> >Yes, the floppies were physically formatted with interleave 1 under
> >DOS/WIN (consecutive I/O: 30 KB/s) and not with default interleave
> >2 under SCO (consecutive I/O: poor 18 KB/s). Here comes a side
> >question: Why SCO uses interleave 2 by default ? (yes, it can be
> >changed, at least on SCO v5.0.x)
>
> >Do you think that this interleave 2, which is slower to read/write,
> >causing itself to be at least more reliable than interleave 1 in
> >terms of "bad" sectors possibly developed during the use of this
> >floppy disk ?
[...]
> The other reason I used Unix is that it uses a 2:1 interleave
> while the factory formatted DOS disks use a 1:1 interleave.
>
> Since MS is basically a synchronous OS (that means it does things
> one at a time) it can use the CPU exclusively until it finishes
> it's task.
>
> On the test I've run on a V.3.2 system - a couple of years ago - I
> found that a 1:1 interleave took about twice as long to write as it
> did with a 2:1 interleave.
>
> Using 2:1 in an MS machine means that you only blow one rev, while
> using a 1:1 in _some_ Unix environment means you blow 18 revs
> on each track.
I see. So it was/is used to prevent one entire revolution for each sector in
case of high system load. Thanks.
> >Interestingly, the slow load doesn't apply for SCO v5.0.x
> >installation boot floppy disk (I've tried v5.0.2 boot disk only).
>
> >Does anyone know why is that ?
> >Perhaps because of some floppy drive compatibility issue that would
> >cause some machines not to load the emergency set at all ?
> I'd suspect drivers and the HW Floppy interface
> design/implementation on the motherboard before I'd say it was
> a floppy. (However swapping floppies is often the quickest way
> to verify this).
I've tried 3 different machines with different motherboards, CPU and even
floppy drives. All exhibit the same problem.
I think it is SCO v5.0.x "/boot" code problem/feature.
Pity the `check-rtc` is ELF binary. Otherwise I would try to copy it to SCO
v4.2 emergency set....
So you have never experienced slow load of v5.0.x emergency set at all ?
Radek Tomis
r...@mediumsoft.cz
Bill Vermillion
Radek Tomis <r...@mediumsoft.cz> wrote:
>> From: Bill Vermillion <bi...@wjv.com.removeme>
>> Sent: Friday, July 16, 1999 4:18 PM
>> In article <019f01becf62$30f21a30$8e0314ac@rtsnt>, Radek Tomis
>> <r...@mediumsoft.cz> wrote:
>> >Yes, the floppies were physically formatted with interleave 1 under
>> >DOS/WIN (consecutive I/O: 30 KB/s) and not with default interleave
>> >2 under SCO (consecutive I/O: poor 18 KB/s). Here comes a side
>> >question: Why SCO uses interleave 2 by default ? (yes, it can be
>> >changed, at least on SCO v5.0.x)
>> >Do you think that this interleave 2, which is slower to read/write,
>> >causing itself to be at least more reliable than interleave 1 in
>> >terms of "bad" sectors possibly developed during the use of this
>> >floppy disk ?
>
>[...]
>> Using 2:1 in an MS machine means that you only blow one rev, while
>> using a 1:1 in _some_ Unix environment means you blow 18 revs
>> on each track.
>I see. So it was/is used to prevent one entire revolution for each
>sector in case of high system load. Thanks.
Depending on the speed of the machine even with no-system load,
because Unix - even the minimal versions - are running about 20
process at a time where in the MS world the only thing running
if format.
I go back to the days when the standard 5.25" HD (the old ST506)
when run on MSDOS systems ran with a 6:1 interleave. Over $1000
for a 5MB HD. I was running DSDD 8" floppies with a 1:1 interleave
and I was at 90% of the speed of the HD's. Now with all the high
speed performance, built in cache on board on the HD's none of this
means much to the end user.
>> I'd suspect drivers and the HW Floppy interface
>> design/implementation on the motherboard before I'd say it was
>> a floppy. (However swapping floppies is often the quickest way
>> to verify this).
>I've tried 3 different machines with different motherboards, CPU
>and even floppy drives. All exhibit the same problem.
>I think it is SCO v5.0.x "/boot" code problem/feature. Pity the
>`check-rtc` is ELF binary. Otherwise I would try to copy it to SCO
>v4.2 emergency set....
>So you have never experienced slow load of v5.0.x emergency set at
>all ?
Honestly? Never. Because I've always used the emergency boot
disks generate by BackupEdge, Lone-Tar, etc.
When I replied I was NOT thinking of the emergency boot disks
that SCO let's you generate.
I think the first supertar I used the ctar from Microlite - on
Xenix '286 machines with 5.25" floppies. About 1987/8.
Radek Tomis
> Sent: Monday, July 19, 1999 6:06 PM
> In article <006a01bed1c1$35509780$8e0314ac@rtsnt>,
> Radek Tomis <r...@mediumsoft.cz> wrote:
[...]
> >I think it is SCO v5.0.x "/boot" code problem/feature. Pity the
> >`check-rtc` is ELF binary. Otherwise I would try to copy it to SCO
> >v4.2 emergency set....
I've obtained COFF version of 'check-rtc' and it works fine from v4.2
emergency floppy set. Now it takes only 5 mins to test. Problem solved.
It's not a problem of v5.0.x "/boot" only. It's a problem of all versions of
"/boot". It doesn't read from EAFS file systems (used by `mkdev fd` for
v5.0.x emergency floppies) as quickly as possible. More details below.
> >So you have never experienced slow load of v5.0.x emergency set at
> >all ?
>
> Honestly? Never. Because I've always used the emergency boot
> disks generate by BackupEdge, Lone-Tar, etc.
Thanks for mentioning this. I've tried both (demos) on v5.0.0. RecoverEDGE
2.1.3 didn't help (same result), however System Crash Air-Bag 3.4.2
(Lone-Tar) knows where is the problem with slow v5.0.x emergency floppy load
!
It is mentioned in Air-Bag's readme and better yet in "/etc/airbag"
front-end script. The problem is with file system type used for both boot
and root floppy. If it is XENIX (used by `mkdev fd` in SCO v4.2) it is fast,
if it is EAFS (or AFS and probably also S51K) (used by `mkdev fd` in SCO
v5.0.x) it is slow.
AirBag uses XENIX file system so the AirBag's emergency set is four times
faster than standard EAFS v5.0.x set (2 vs 8 mins), however still twice as
slow as v4.2 emergency set (1'09" only).
Changing file system type from EAFS to XENIX makes the load roughly twice as
fast.
In addition, AirBag uses 1K rotational gap (high-level interleave) for XENIX
FS. I suppose this I/O slowdown is needed in order for slow decompressing
(used in "/boot") of v5.0.x compressed kernel and root file system image
could keep up with I/O flow and prevent extra revolutions. Wonder what it
would be like with physical 1:2 interleave and no user-level gap.
Changing rotational gap from 1 (no gap) (used by default for both SCO v4.2
and v5.0.x mergency set) to 2 (1K gap) makes the v5.0.x emergency set's load
roughly twice as fast. This gap change is contra-productive for v4.2 set,
because decompression isn't used, and the gap slows the loading a bit (20%).
I've found yet another trick how to short cut the time to load v5.0.x set.
Changing number of blocks per cylinder (when creating XENIX FS) from 18 (9K)
to 9 (4.5K) makes the load about 20% faster. I find this strange (3,1/2"
DSHD floppy has 9K optimal block size (track size)), but that's what I've
found.
Oh, perhaps XENIX uses 1K blocks for gap and cylinder size (as opposed to
512-byte blocks in EAFS, at least output from mkfs for EAFS claims so) and
then gap 1 means 1K (1:1 - no gap) and 18 means 18K (two 9K tracks =
cylinder for double sided floppies). That makes much better sense.
So here is the procedure to turn way too slow v5.0.x emergency set into fast
one:
for both boot and root floppy:
{
mount /dev/fd0 /mnt
(cd /mnt; find . -print | cpio -pdvmu /tmp/fd)
umount /mnt
# All three speed-ups made by 'mkfs' (FS type, gap, cylinder size):
mkfs -f XENIX /dev/fd0 2880 2 9
cp /etc/fd135ds18boot0 /dev/fd0 # only for boot floppy
mount /dev/fd0 /mnt
(cd /tmp/fd; find . -print | cpio -pdvmu /mnt)
umount /mnt
}
After this, tls620 loads within 1'56" (still almost twice as slow as v4.2
set) in comparison with the original 7'52".
I don't know why AirBag needs XENIX support in the kernel on boot floppy. I
didn't have to add XENIX support to v5.0.5 kernel on tls620 in order to
successfully load this modified emergency set and perform Y2K tests. No,
there isn't XENIX support in that v5.0.5 kernel already added.
> When I replied I was NOT thinking of the emergency boot disks
> that SCO let's you generate.
I know you weren't referring to emergency floppies at all, I just didn't
want to believe I was the only one that experienced this problem.
--
Radek Tomis
r...@mediumsoft.cz
Bill Vermillion
Radek Tomis <r...@mediumsoft.cz> wrote:
>> From: Bill Vermillion <bi...@wjv.com.removeme>
>> Sent: Monday, July 19, 1999 6:06 PM
>> In article <006a01bed1c1$35509780$8e0314ac@rtsnt>,
>> Radek Tomis <r...@mediumsoft.cz> wrote:
>
>[...]
(first part of discussion on slow loads deleted - wjv)
>I've obtained COFF version of 'check-rtc' and it works fine from v4.2
>emergency floppy set. Now it takes only 5 mins to test. Problem solved.
>It's not a problem of v5.0.x "/boot" only. It's a problem of
>all versions of "/boot". It doesn't read from EAFS file systems
>(used by `mkdev fd` for v5.0.x emergency floppies) as quickly as
>possible. More details below.
That's interesting. I have found in testing the the old Xenix
file system is about the slowest around. However for a floppy
system that shouldn't be a problem. I wonder what the thinking
is on an EAFS boot disk. Curious?
>> >So you have never experienced slow load of v5.0.x emergency set at
>> >all ?
>> Honestly? Never. Because I've always used the emergency boot
>> disks generate by BackupEdge, Lone-Tar, etc.
>Thanks for mentioning this. I've tried both (demos) on v5.0.0.
>RecoverEDGE 2.1.3 didn't help (same result), however System Crash
>Air-Bag 3.4.2 (Lone-Tar) knows where is the problem with slow
>v5.0.x emergency floppy load !
>It is mentioned in Air-Bag's readme and better yet in "/etc/airbag"
>front-end script. The problem is with file system type used for
>both boot and root floppy. If it is XENIX (used by `mkdev fd` in
>SCO v4.2) it is fast, if it is EAFS (or AFS and probably also S51K)
>(used by `mkdev fd` in SCO v5.0.x) it is slow.
That sort of stands to reason as the S51 system is about as simple
as you get.
>AirBag uses XENIX file system so the AirBag's emergency set is four
>times faster than standard EAFS v5.0.x set (2 vs 8 mins), however
>still twice as slow as v4.2 emergency set (1'09" only).
>Changing file system type from EAFS to XENIX makes the load roughly
>twice as fast.
It's interesting to note your comment about BackupEdge recover
disks. I've never had them take much more than a minute or two
to load..
>In addition, AirBag uses 1K rotational gap (high-level interleave)
>for XENIX FS. I suppose this I/O slowdown is needed in order for
>slow decompressing (used in "/boot") of v5.0.x compressed kernel
>and root file system image could keep up with I/O flow and prevent
>extra revolutions. Wonder what it would be like with physical 1:2
>interleave and no user-level gap.
I'd suspect they would be the same.
>Changing rotational gap from 1 (no gap) (used by default for both
>SCO v4.2 and v5.0.x mergency set) to 2 (1K gap) makes the v5.0.x
>emergency set's load roughly twice as fast. This gap change is
>contra-productive for v4.2 set, because decompression isn't used,
>and the gap slows the loading a bit (20%).
I wonder if someone assumed that in this world of high-performance
HD's and buffers on the HD themselves, that someone just set
this up for a 1:1 interleave. It should be okay on some systems,
but will be a pig on others.
I learned a lot about this a long time ago (20 really) when I was
using an OS that let you 'tune' how it was to run. Floppy drives
had a lot of different track-track access times. Format a disk on
a drive with fast track to track access and read it on a slow one
seem to take forever. We'd blow 10 rev - at least - on a read.
Take a drive that spins at 300RPM. Thats 5 revolutions per second.
If it would read a 1:2 interleave that takes 2/5ths of a second
to read the track after taking into account access time and head
settling. Total probably 1/2 second factoring in (as a guess) the
latency, settling time, etc.
(The newest HD's are using 'zero rotational delay') a firmware
implementations that starts reading data as soon as the head gets
to the track no matter what sector is under it. The old paradigm
said wait until sector 1 appears and then read. Large on drive
cache systems make this easy - and with sector counts often running
over 80 sectors per track should show measureable improvement)
Blowing 10 revs means 10/5ths of a second - or two seconds for
each track. Depending on a variety of factors the 1:1 is going to
be 1/4th the speed. That matches your 8 minutes vs 2 minutes,
does it not?
>I've found yet another trick how to short cut the time to load
>v5.0.x set. Changing number of blocks per cylinder (when creating
>XENIX FS) from 18 (9K) to 9 (4.5K) makes the load about 20% faster.
>I find this strange (3,1/2" DSHD floppy has 9K optimal block size
>(track size)), but that's what I've found.
I can sort of envision this (just musings on my part here) in
relation ship to interleave. 4.5K block size is the block
for 1 revolution - 1/2 the sectors. So each revolution gets
one block of smaller size instead of two revolutions for the larger
size. Just a guess however.
>So here is the procedure to turn way too slow v5.0.x emergency set
>into fast one:
Good info.
>After this, tls620 loads within 1'56" (still almost twice as slow
>as v4.2 set) in comparison with the original 7'52".
Script started on Thu Jul 22 10:12:16 1999
bc 1.04
scale=2
60 + 56
116
420 + 52
472
472 / 116
4.06
quit
4.06 time slower/faster - depending on your direciton of view.
Matches with my 'back of the envelope' calculations from above.
>I don't know why AirBag needs XENIX support in the kernel on boot
>floppy. I didn't have to add XENIX support to v5.0.5 kernel on
>tls620 in order to successfully load this modified emergency set
>and perform Y2K tests. No, there isn't XENIX support in that v5.0.5
>kernel already added.
Many systems need an S51 type file system from which to boot. That
sort of says something about the complexity of the newer faster
filesystems on some systems/OSes.
>I know you weren't referring to emergency floppies at all, I just
>didn't want to believe I was the only one that experienced this
>problem.
I hadn't - and I don't now why. The last emergency set I tested
and built was on a 300MHz PII, OSR5.0.5, 256MB ram, and 16MB ECC on
the HD controller. Loaded just fine in the normal expected time.
I wonder if it is resources dependant - thought I would think
most modern hardware should be able to handle this.
Radek Tomis
> Sent: Thursday, July 22, 1999 4:24 PM
> In article <001301bed40c$e3f828a0$8e0314ac@rtsnt>,
> Radek Tomis <r...@mediumsoft.cz> wrote:
> >> From: Bill Vermillion <bi...@wjv.com.removeme>
> >> Sent: Monday, July 19, 1999 6:06 PM
>
> >> In article <006a01bed1c1$35509780$8e0314ac@rtsnt>,
> >> Radek Tomis <r...@mediumsoft.cz> wrote:
> >
> >[...]
>
> (first part of discussion on slow loads deleted - wjv)
> >It's not a problem of v5.0.x "/boot" only. It's a problem of
> >all versions of "/boot". It doesn't read from EAFS file systems
> >(used by `mkdev fd` for v5.0.x emergency floppies) as quickly as
> >possible. More details below.
>
> That's interesting. I have found in testing the the old Xenix
> file system is about the slowest around. However for a floppy
> system that shouldn't be a problem. I wonder what the thinking
> is on an EAFS boot disk. Curious?
Good point.
EAFS (and also AFS, S51K, ES51K and even HTFS) layout is basically the same
as XENIX as far as reading is concerned, so you made me do more tests and I
found that unlike I said in my previous post, EAFS performs as good/bad as
XENIX.
I had either done something wrong in previous tests or happened to test
XENIX FS only with certain settings and on certain (faster) machine,
resulting in half time load for XENIX vs. EAFS (see notice for "*" under the
table below). And last but not least, AirBag (its "readme" and mostly XENIX
vs. EAFS comment in "/etc/airbag") led me astray little bit, because I had
thought (and one test that I cannot reproduce anymore confirmed this) that
the difference between EAFS and XENIX is in the file system type itself. Not
so, the difference is only in settings used to create XENIX and EAFS.
The following table shows more (results were double verified):
tls620, boot floppy disk only (v5.0.5 kernel, size 2.01 MB, compressed size
947 KB):
+---------------------------------------------------------+
| FS, gap/bpc, interleave time to load "/unix.Z" |
+---------------------------------------------------------+
| P-100, 32MB P-200 MMX, 32 MB |
| EAFS, 1/400, 1:1, 3'09" 3'10" |
| EAFS, 1/ 18, 1:1, 3'09" 3'09" * |
| EAFS, 1/ 9, 1:1, 3'09" 3'09" * |
| EAFS, 2/ 18, 1:1, 3'09" 3'10" |
| EAFS, 2/ 9, 1:1, 3'09" 3'10" |
| EAFS, #2/ 18, 1:1, 50" |
| |
| EAFS, 1/400, 1:2, 1'02" 1'00" |
| EAFS, 1/ 18, 1:2, 1'00" 1'00" |
| EAFS, 1/ 9, 1:2, 1'00" 1'01" |
| EAFS, 2/ 18, 1:2, 1'07" 1'08" |
| EAFS, 2/ 9, 1:2, 1'07" 1'07" |
| EAFS, #2/ 18, 1:2 1'33" |
| |
| XENIX, 1/400, 1:1, 3'09" 3'10" |
| XENIX, 1/ 18, 1:1, 3'09" 3'10" |
| XENIX, 1/ 9, 1:1, 3'09" 3'09" * |
| XENIX, 2/ 18, 1:1, 1'00" 1'00" |
| XENIX, 2/ 9, 1:1, 49" 49" |
| |
| XENIX, 1/400, 1:2, 1'00" 1'01" |
| XENIX, 1/ 18, 1:2, 1'00" 1'01" |
| XENIX, 1/ 9, 1:2, 1'01" 1'01" |
| XENIX, 2/ 18, 1:2, 1'42" 1'42" |
| XENIX, 2/ 9, 1:2, 1'32" 1'32" |
+---------------------------------------------------------+
gap - rotational file system gap (FS interleave) in FS
blocks (XENIX) or clusters (EAFS)
- XENIX 1K: 1 = no gap (1:1), 2 = 1K gap (1:2), 3 = 2K gap (1:3),
and so on
- EAFS 1K, cluster 16K: 1 = no gap (1:1), 2 = 16K gap (1:2)
- EAFS 1K, cluster 1K: 1 = no gap (1:1), 2 = 1K gap (1:2)
bpc - number of file system Blocks Per Cylinder
- effective with XENIX FS and gap != 1 only
interleave - physical sector interleave ('format <device> -i interleave')
* - For these tests (and another XENIX test also on P-200 MMX that
I can't remember, because I threw the paper to the bin just
after my previous post, thinking "I'm done"), I believe
(I had them written down) I really got the half time
(1'28" vs. 3'09"), but I haven't been able to reproduce
them, although tried several times (always got 3'09" or
3'10"). That's still a little mistery for me.
# - EAFS created with 1K clusters (`mkfs -f EAFS <device> 2880 2 <bpc>
-E -C 1`) to get effective gap of 1K only as opposed to 16K for
all other EAFS tests used with default cluster size 16K. P-200
MMX tests are missing, because I was not going to try this
different cluster size setting until few moments ago. I've gotten
this idea during update of this article.
"/unix.Z" disk blocks layout:
- EAFS,1/400 == EAFS,1/18 == EAFS,1/9 (no gap)
- EAFS,2/18 == EAFS,2/9 (16K gap)
- EAFS,2/18 with cluster size 1K (1K gap):
blocks: large contiguous chunks with 1K gaps, example only:
162 164 166 ... 690 692
183 185 187 ... 1204 1206
699 701 703 ... 1436 1438
[...]
- track layout:
cyl 0, head 0: 5K
cyl 0, head 1: 4K
cyl 1, head 0: 5K
cyl 1, head 1: 4K
---
cyl 2, head 0: 5K
...
- almost constant 1K rotational gap
- XENIX,1/400 == XENIX,1/18 == XENIX,1/9 (no gap)
- XENIX,2/18:
blocks, (0 = cylinder boundary):
0 2 4 6 8 10 12 14 16
1 3 5 7 9 11 13 15 17
18 20 22 24 26 28 30 32 34
19 21 23 25 27 29 31 33 35
..
..
- track layout:
cyl 0, head 0: 5K
cyl 0, head 1: 4K
cyl 0, head 0: 4K
cyl 0, head 1: 5K
---
cyl 1, head 0: 5K
...
- constant 1K rotational gap with exception of 2K and 0K gap once
for each cylinder (!)
- XENIX,2/9:
blocks, (0 = cylinder boundary):
1 3 5 7
0 2 4 6 8
10 12 14 16
9 11 13 15 17
19 21 23 25
18 20 22 24 26
..
..
- track layout: 4K, 5K, 4K, 5K, ...
cyl 0, head 0: 4K
cyl 0, head 0: 5K
cyl 0, head 1: 4K
cyl 0, head 1: 5K
---
cyl 1, head 0: 4K
...
- constant 1K rotational gap
The problem of slow load with compressed v5.0.x emergency set is perhaps in
16-bit implementation of decompressing algorithm ('file /boot' => "... 86
executable"), because my load simulation with standard 32-bit i386
'compress' binary worked fine:
+----------------------------------------------------------+
| time compress -d < /mnt/unix.Z > /tmp/ramdisk/unix |
| time fsrd -s /dev/rfd0 inode -d 8/9 | compress -d > ... |
| |
| FS, gap/bpc, interleave time |
+----------------------------------------------------------+
| P-100, 32 MB RAM |
| EAFS, 1/400, 1:1, 34" |
| EAFS, 1/ 18, 1:1, 34" |
| EAFS, 2/ 18, 1:1, 43" |
| EAFS, 1/400, 1:2, 54" |
| XENIX, 1/400, 1:1, 34" |
| XENIX, 1/ 9, 1:1, 34" |
| XENIX, 2/ 9, 1:1, 43" |
| XENIX, 1/ 9, 1:2, 54" |
+----------------------------------------------------------+
Reading from raw floppy device (using my own tool `fsrd`) ensured that no
system cache/buffer was in use to read from floppy.
BTW, during the tests I managed to combine both v4.2 emergency floppies
(BOOT+ROOT) on single one (1.44M) (/boot + compressed kernel copied onto
ROOT floppy plus removing some unnecessary stuff) and I shortened the time
to load emergency set even further:
v4.2 emergency boot floppy disk only (v4.2 kernel, size 919 KB, compressed
size 408 KB):
+----------------------------------------------------------+
| FS, gap/bps, interleave time to load "/unix" |
+----------------------------------------------------------+
| EAFS, 1/400, 1:1, 41" |
| EAFS, 1/ 18, 1:1, 41" |
| XENIX, 1/ 18, 1:1, 41" |
+----------------------------------------------------------+
+----------------------------------------------------------+
| FS, gap/bpc, interleave time to load "/unix.Z" |
+----------------------------------------------------------+
| EAFS, 1/400, 1:1, 1'35" |
| XENIX, 1/ 18, 1:1, 1'35" |
| XENIX, 1/ 9, 1:1, 1'35" |
| XENIX, 2/ 18, 1:1, 31" |
| XENIX, 2/ 9, 1:1, 26" |
| XENIX, 1/ 18, 1:2, 32" |
| XENIX, 1/ 9, 1:2, 32" |
| XENIX, 2/ 18, 1:2, 50" |
| XENIX, 2/ 9, 1:2, 45" |
+----------------------------------------------------------+
[RecoverEDGE's emergency set loads as slow as standard v5.0.x set]
>
> It's interesting to note your comment about BackupEdge recover
> disks. I've never had them take much more than a minute or two
> to load..
Right, because of different interleave (see EAFS 1/400, 1:1 vs. 1:2 in the
first table above).
> >In addition, AirBag uses 1K rotational gap (high-level interleave)
> >for XENIX FS. I suppose this I/O slowdown is needed in order for
> >slow decompressing (used in "/boot") of v5.0.x compressed kernel
> >and root file system image could keep up with I/O flow and prevent
> >extra revolutions. Wonder what it would be like with physical 1:2
> >interleave and no user-level gap.
>
> I'd suspect they would be the same.
Yes, for 18 blocks per cylinder it is the same.
(XENIX, 2/18, 1:1 vs. XENIX, 1/18, 1:2)
Some thoughts on this (that most probably don't impact emergency set load
time at all):
While 2/18 needs twice as much head switches as 1/<any> (see block layout
above), there is twice as much idle time for decompressing with 2/18 (1K
logical gap vs. 1 sector (0.5K) physical gap), thus some extra rev might be
sometimes required for 1:2. Assuming '/boot' reading from floppy via BIOS in
1K (2 sectors) chunks and decompressing synchronously. The 1 sector spin
idle time with 1:2 interleave is wasted while waiting (inside BIOS code) for
the 2nd sector to appear under the head.
For 9 blocks per cylinder it is slower (20%).
(XENIX, 2/9, 1:1 vs. XENIX, 1/9, 1:2)
> >Changing rotational gap from 1 (no gap) (used by default for both
> >SCO v4.2 and v5.0.x mergency set) to 2 (1K gap) makes the v5.0.x
> >emergency set's load roughly twice as fast. This gap change is
> >contra-productive for v4.2 set, because decompression isn't used,
> >and the gap slows the loading a bit (20%).
>
> I wonder if someone assumed that in this world of high-performance
> HD's and buffers on the HD themselves, that someone just set
> this up for a 1:1 interleave. It should be okay on some systems,
> but will be a pig on others.
>
> I learned a lot about this a long time ago (20 really) when I was
> using an OS that let you 'tune' how it was to run. Floppy drives
> had a lot of different track-track access times. Format a disk on
> a drive with fast track to track access and read it on a slow one
> seem to take forever. We'd blow 10 rev - at least - on a read.
>
> Take a drive that spins at 300RPM. Thats 5 revolutions per second.
> If it would read a 1:2 interleave that takes 2/5ths of a second
> to read the track after taking into account access time and head
> settling. Total probably 1/2 second factoring in (as a guess) the
> latency, settling time, etc.
> Blowing 10 revs means 10/5ths of a second - or two seconds for
> each track. Depending on a variety of factors the 1:1 is going to
> be 1/4th the speed. That matches your 8 minutes vs 2 minutes,
> does it not?
Right, 10 vs. 2 revs roughly corresponds to 8 vs. 2 minutes.
But from what did you derive those 10 revs ?
From experience with different floppy drives mentioned above ?
I'm a bit confused here.
The difference between XENIX 2/18,1:1 vs. 2/9,1:1 (1'00" vs. 49"):
> >I've found yet another trick how to short cut the time to load
> >v5.0.x set. Changing number of blocks per cylinder (when creating
> >XENIX FS) from 18 (9K) to 9 (4.5K) makes the load about 20% faster.
> >I find this strange (3,1/2" DSHD floppy has 9K optimal block size
> >(track size)), but that's what I've found.
>
> I can sort of envision this (just musings on my part here) in
> relation ship to interleave. 4.5K block size is the block
> for 1 revolution - 1/2 the sectors. So each revolution gets
> one block of smaller size instead of two revolutions for the larger
> size. Just a guess however.
Well, I could agree, but only if it would be in relationship to *physical*
(1:2) interleave, which I actually tested (reading 1:2 floppy raw device
with 4.5K vs 9K block size) and there's really no difference.
However, since here we have logical FS interleave (gap parameter), the
"/boot" (or any other SW for that matter) cannot use different block size
other than 2 or 1 sector (1 or 1/2 KB), because file's blocks (and sectors)
are not contiguous (with gap=2), so you can't read (in almost all cases)
more than one block at once (i.e. AFAIK you can't tell floppy drive to read
sectors 1,2,5,6,9,10,13,14,17,18, all in one operation). Of course, with
physical interleave, this is transparent to SW, and whole track (9K) or half
of the track (4.5K) can be requested at once, provided that file's block in
the filesystem are contiguous.
My theory, now that I understand the FS layout in regard of gap and bpc, is
different.
First of all, I found out that the gap parameter does not mean number of
physical blocks (512-byte sectors) per cylinder as EAFS version of mkfs
displays. It means number of logical file system blocks (as I guessed in the
previous post), so gap 18 means 18 KB cylinder size (using 1KB logical
blocks).
Now if you take a look at the XENIX 2/18 (1:1) block layout (under the first
table above), you will notice, that once per each cylinder, there are two
consecutive blocks without any gap. The XENIX 2/9 and also EAFS 2/<any> with
1K clusters layouts don't have any rotational gap missing.
As you said, one rev is worth of 0.2 seconds. For "/unix.Z" (947 KB) on
XENIX 2/18, there are 52 (947K / 18K) rotational gaps missing (0K gaps). 52
extra revs are worth of 10.4 seconds, which matches 1'00" vs. 49" or 50"
difference.
> >So here is the procedure to turn way too slow v5.0.x emergency set
> >into fast one:
>
> Good info.
This procedure (XENIX, 2/9) still remains the best combination (as well as
new one discovered a while ago: EAFS 2/18, 1K cluster) even after new tests,
but only for floppies with physical interleave 1:1.
If you must use 1:2 floppies, for some reason, use standard EAFS 1/400 or
1/18 layout (used by SCO itself and RecoverEDGE). However, the best
combination for any 1:2 emergency set will still be almost 20% slower than
the best combination for 1:1 set.
If you use Lone-Tar's AirBag, avoid 1:2 floppies, because AirBag's layout
(XENIX, 2/18) is considerable slower than the best combinations for 1:2
floppies (e.g. EAFS 1/400).
If you use RecoverEDGE, choose to format floppies during creation process
using system default (1:2) interleave.
> >After this, tls620 loads within 1'56" (still almost twice as slow
> >as v4.2 set) in comparison with the original 7'52".
>
> Script started on Thu Jul 22 10:12:16 1999
> bc 1.04
BTW, 'bc 1.04' works ?
What does it mean ?
> scale=2
> 60 + 56
> 116
> 420 + 52
> 472
> 472 / 116
> 4.06
> quit
>
> 4.06 time slower/faster - depending on your direciton of view.
> Matches with my 'back of the envelope' calculations from above.
Yes, but I still don't understand those 10 revs...
> >I don't know why AirBag needs XENIX support in the kernel on boot
> >floppy. I didn't have to add XENIX support to v5.0.5 kernel on
> >tls620 in order to successfully load this modified emergency set
> >and perform Y2K tests. No, there isn't XENIX support in that v5.0.5
> >kernel already added.
>
> Many systems need an S51 type file system from which to boot. That
> sort of says something about the complexity of the newer faster
> filesystems on some systems/OSes.
Even HTFS is basically as simple as XENIX/EAFS to read.
Well, I understand necessity of boot file system in SCO v5.0.x to avoid
1024-cylinder limitation rather than '/boot' inability to boot from HTFS,
because HTFS, as I mentioned above, has very small differences as far as
plain reading of files is concerned. The only considerable difference as I
see it is different directory content structure (HTFS uses variable while
S51K family uses fixed), but it's not a big problem really.
But maybe there's some other major limitation for inability to boot from
HTFS, that I don't see (besides 1024 cylinders).
> >I know you weren't referring to emergency floppies at all, I just
> >didn't want to believe I was the only one that experienced this
> >problem.
>
> I hadn't - and I don't now why. The last emergency set I tested
> and built was on a 300MHz PII, OSR5.0.5, 256MB ram, and 16MB ECC on
> the HD controller. Loaded just fine in the normal expected time.
> I wonder if it is resources dependant - thought I would think
> most modern hardware should be able to handle this.
Now we know. It's because you use 1:2 floppy disks whereas I became a victim
of 1:1 religion, which eventually turned out to be the best one ever ;-)
PS: I know, my sig separator below isn't correct (it lacks trailing space),
but my lovely Microsoft Outlook Express thinks that any trailing space
in the e-mail or news message is useless.
--
Radek Tomis
r...@mediumsoft.cz
Radek Tomis
In article <04a801bee029$e29f3c40$8e0314ac@rtsnt>,
Radek Tomis <r...@mediumsoft.cz> wrote:
>> From: Bill Vermillion <bi...@wjv.com.removeme>
>> Sent: Thursday, July 22, 1999 4:24 PM
>
>> In article <001301bed40c$e3f828a0$8e0314ac@rtsnt>,
>> Radek Tomis <r...@mediumsoft.cz> wrote:
>> >> From: Bill Vermillion <bi...@wjv.com.removeme>
>> >> Sent: Monday, July 19, 1999 6:06 PM
>>
>> >> In article <006a01bed1c1$35509780$8e0314ac@rtsnt>,
>> >> Radek Tomis <r...@mediumsoft.cz> wrote:
>> >
>> >[...]
>>
>> (first part of discussion on slow loads deleted - wjv)
>> >It's not a problem of v5.0.x "/boot" only. It's a problem of
>> >all versions of "/boot". It doesn't read from EAFS file systems
>> >(used by `mkdev fd` for v5.0.x emergency floppies) as quickly as
>> >possible. More details below.
>> That's interesting. I have found in testing the the old Xenix
>> file system is about the slowest around. However for a floppy
>> system that shouldn't be a problem. I wonder what the thinking
>> is on an EAFS boot disk. Curious?
>Good point. EAFS (and also AFS, S51K, ES51K and even HTFS) layout
>is basically the same as XENIX as far as reading is concerned, so
>you made me do more tests and I found that unlike I said in my
>previous post, EAFS performs as good/bad as XENIX.
OK. That's the problem with tests. Sometimes you get an answer
that looks reasonable and you stop, not knowing that something was
wrong. Been there lots of times. Now I'm eternally skeptical.
>... And last but not least, AirBag (its "readme" and mostly XENIX
>vs. EAFS comment in "/etc/airbag") led me astray little bit,
>because I had thought (and one test that I cannot reproduce anymore
>confirmed this) that the difference between EAFS and XENIX is in
>the file system type itself. Not so, the difference is only in
>settings used to create XENIX and EAFS.
Can you give a brief synopsis of the /etc/airbag EAFS comments?
>The following table shows more (results were double verified):
>tls620, boot floppy disk only (v5.0.5 kernel, size 2.01 MB,
>compressed size 947 KB):
Thanks for the chart.
(I've deleted many lines and only left a few in for comment)
>+---------------------------------------------------------+
>| FS, gap/bpc, interleave time to load "/unix.Z" |
>+---------------------------------------------------------+
>| EAFS, 1/ 9, 1:1, 3'09" 3'09" * |
>| EAFS, 2/ 9, 1:1, 3'09" 3'10" |
>| EAFS, 1/ 9, 1:2, 1'00" 1'01" |
>| EAFS, 2/ 9, 1:2, 1'07" 1'07" |
Isn't 1/9 the 5.25" HD format? In that case - depending on
hardware, etc., the bit stream to the disk is about 1/2 of
that of that on the 3.5" HD. eg 250Kbits/second vx 500Kbit.
I guess that would only make a difference in the older machines,
the ones I started with running 2 - 4 Mhz CPUs and slower busses.
>
>The problem of slow load with compressed v5.0.x emergency set is
>perhaps in 16-bit implementation of decompressing algorithm ('file
>/boot' => "... 86 executable"), because my load simulation with
>standard 32-bit i386 'compress' binary worked fine:
I wonder if that is an idea of taking the lowest common denominator
that will work everywhere. When I was using a 16/32 processor
(Motorola 68000 - internally 32 bit external) I used to get full
news feeds (back in the days when 100MB per/day was undreampt of)
and with the limited memorry I get 13 bit compressed feeds.
Getting 16 bit compressed feeds required so long to uncompress
because of swapping due to HW memory limitation, that the system
would be busy almost 24 hours/day just uncompressing and spooling
the news to it's hierarchy. Of course BNews was damned slow also.
But in many areas the idea is to use the lowest common denomiator
so that it will work in any environment. Or was it just code that
work, and was not needed/user very often so that it made sense to
leave it alone.
For the average person waiting 4 minutes instead of 2 minutes on
a load of a recovery disk doesn't mean a lot if they are only going
to have to do it 2 or 3 times in a 5 year span. Then there are
those of us who've done this a half-dozen times in one. (I wonder
what the record is??)
>While 2/18 needs twice as much head switches as 1/<any> (see block
>layout above), there is twice as much idle time for decompressing
>with 2/18 (1K logical gap vs. 1 sector (0.5K) physical gap), thus
>some extra rev might be sometimes required for 1:2. Assuming
>'/boot' reading from floppy via BIOS in 1K (2 sectors) chunks and
>decompressing synchronously. The 1 sector spin idle time with 1:2
>interleave is wasted while waiting (inside BIOS code) for the 2nd
>sector to appear under the head.
Twice as many head switches doesn't sound right to me. There
should only be one head switch per track. Or am I mis-interpreting
thisr?
>Right, 10 vs. 2 revs roughly corresponds to 8 vs. 2 minutes.
>But from what did you derive those 10 revs ?
>From experience with different floppy drives mentioned above ?
>I'm a bit confused here.
I don't recall but I've around floppies most of my 'computer life'.
You want slow? The old IBM PC ST506 type hard drives used a 1:6
interleave and would max out at 69KB/sec. I was using a system
with 8" DSDD floppies - with a 1:1 interleave - that would take
the data at full interface rate 500Kbit/sec, or about 62.5KB/sec
People would be amazed at the high speed of these, and I saw no
reason for people spending $2500 for a 5MB drive (these were addons
before IBM introduced the XT), when a $500 8" device was only about
10% slower, 1/5th the cost, and could have infinite storage - at
a cost of about $5.00 per 1.2MB 8" DSDD disk. However
most people experienced floppies in the Commodore, Apple, TRS
world (the latter was the fastest) where 25KB second was the
maximum and it was often in the 10-15KByte second.
I have a Shugart 400 - handwritten serial number in the 1600 range
- that came from the first evaluation run of 5.25" drives made. (I
don't know if they started numbering a 1 or 1000 - but pilot runs
are typically made in extremly low volume. The PCB snaps onto
the drive with phosphor-bronze (it looks like) type springs.)
(I got it several years later), but that givess and idea where I've
come from. Things are so much better now)
>> I can sort of envision this (just musings on my part here) in
>> relation ship to interleave. 4.5K block size is the block
>> for 1 revolution - 1/2 the sectors. So each revolution gets
>> one block of smaller size instead of two revolutions for the larger
>> size. Just a guess however.
>Well, I could agree, but only if it would be in relationship to
>*physical* (1:2) interleave, which I actually tested (reading 1:2
>floppy raw device with 4.5K vs 9K block size) and there's really no
>difference.
I was only thinking of physical interleaves.
>> Script started on Thu Jul 22 10:12:16 1999
>> bc 1.04
>BTW, 'bc 1.04' works ?
>What does it mean ?
It means I edit my typescript file too much :-). The bc 1.04
is the prompt after bc boots up. I accidentally elimated the
command I used to start 'bc', when I deleted all the copyrights,
etc from the included text. My news/mail machine is nothing more
than that news/mail, pure text, Cnews, Elm, and Lynx as a web
browser (can get a lot of text in a hurry). Running FBSD in 16MB.
>> 4.06 time slower/faster - depending on your direciton of view.
>> Matches with my 'back of the envelope' calculations from above.
>Yes, but I still don't understand those 10 revs...
I dont' know if you quoted that part, but when I looked at it above
I don't remember that, and I can't very easily go back to my
original post while replying to this one. Sorry.
>Well, I understand necessity of boot file system in SCO v5.0.x to
>avoid 1024-cylinder limitation rather than '/boot' inability to
>boot from HTFS, because HTFS, as I mentioned above, has very small
>differences as far as plain reading of files is concerned. The only
>considerable difference as I see it is different directory content
>structure (HTFS uses variable while S51K family uses fixed), but
>it's not a big problem really.
>But maybe there's some other major limitation for inability to boot
>from HTFS, that I don't see (besides 1024 cylinders).
I read that in the docs, or notes, or somewhere else. Perhaps it
has to do with the ability or space requirements in the boot
sectors. That is out of my range of knowledge. (or it is now if
it wasn't at one time:-) )
>Now we know. It's because you use 1:2 floppy disks whereas I became
>a victim of 1:1 religion, which eventually turned out to be the
>best one ever ;-)
Did I mention I format all of my floppies on the Unix system
because they will fail if they won't verify. While on the PC
systems you just map out the bad blocks. Since I want to be able
to use them interchangeably, I dd in the first track of a freshly
formatted DOS disk that I know was made from original distribution
media - and put that in a file.
Then my little script just goes into a loop, formats a disk under
Unix, dd's the DOS boot track back onto the disk, and now I have
a flawless disk that works under both. I'll toss away a 25cent
1.4MB disk if it's not perfect. However in the days of $5.00
88KB disks you'd not do that . (We had a group purchase and
were able to get a box of 10 88KB SSSD disks at about $45.00 per
box instead of the going $60.00/box rate).
>PS: I know, my sig separator below isn't correct (it lacks trailing
>space), but my lovely Microsoft Outlook Express thinks that any
>trailing space in the e-mail or news message is useless.
Why does that not surprize me ?
PS - If this doesn't make it to the newsgroups, feel free to repost
it if you wish. I need to investigate the missing posts - as my
newsfeeds have changed and although it propagates out to other
local sites with global connectivity, something has changed.
Bill