U613042@HNYKUN11.BITNET (Olaf Seibert) (12/04/87)
Our local user group spreaded some, quite unlikely, rumours in their
newsletter. I don't believe them, but if they are true, that would be
very nice.
They wrote, that during some phase in the development of the trackdisk.
device, it was necessary to type in a hexdump, from paper, that was
developed on another kind of machine. During this re-typing, someone
made a typing error, which noone noted since everything works.
The result of this single incorrect byte would be, that the disk speed
now is only one fifth of what it could (and should) be.
I know all of this is quite unlikely, but anyhow, some comment on it
would be welcome.
See you,
---
The opinions possibly reflected herein are my own, and not necessarily
those of someone else I might be connected with. They MAY, however, be.
>>> I *thought* I was living in a free, modern country....
--- Olaf (Rhialto) Seibert... U613042@HNYKUN11.BITNET
USENET is *almost* an anagram of unsent ... BITNET: Because It's There
Computers? Just say *YES*! Customs? Just say *NO*!grr@cbmvax.UUCP (George Robbins) (12/06/87)
In article <8712041550.AA01428@jade.berkeley.edu> U613042@HNYKUN11.BITNET (Olaf Seibert) writes: > > Our local user group spreaded some, quite unlikely, rumours in their > newsletter. I don't believe them, but if they are true, that would be > very nice. > > They wrote, that during some phase in the development of the trackdisk. > device, it was necessary to type in a hexdump, from paper, that was > developed on another kind of machine. During this re-typing, someone > made a typing error, which noone noted since everything works. > > The result of this single incorrect byte would be, that the disk speed > now is only one fifth of what it could (and should) be. Stuff and nonsense. The disk performance is slow because the disk organization inherited from Tripos wasn't designed for speed or even simplicity, rather they were exploring allocation, reliability and recoverability strategies. If you take out all the silly stuff, assume that diskettes (or hard drives) are inherently reliable and decide that simple allocation scheme may not be that bad, you get performance comperable to a PC or the like. BTW, all the code is in C, BCPL or Assembler, so what bugs exist are a little more involved than some bad hex errors. -- George Robbins - now working for, uucp: {uunet|ihnp4|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)