car@ramecs.UUCP (Chris Rende) (10/08/90)
I read in the FAQ (I think) about the free 3B1 FIXDISK 2.0 disks available
from AT&T. Since it is a free upgrade I decided to call AT&T and ask for a
copy.
The first thing that AT&T asked for was my 3B1 serial number. Since I don't
carry that information to work with me I told the person that I'd have to
call back.
That night I started searching for the serial number on the machine. I found
it in the most obnoxious place for it to be - in the exact middle of the
underside of the case. At least it was on the outside of the case. :-)
I didn't want to shut the machine down and turn it upside down just to get
the serial number so I proped it up with my fist and slid a mirror underneath
it. By shining a flashlight into the mirror I was able to see the serial
number (backwards due to the mirror reflection, of course). Anyone who has
ever tried to lift one of these things can appreciate how much fun it was.
The next day I called AT&T again. Be prepared to wait on hold for a while.
This time they took the serial number and my name, address, and phone number.
This registered the machine in my name (I'm the third owner - but no one else
ever registered it).
A few days later the disks and 6 page instruction booklet arrived!
The instructions said to use the UA to load the disk contents and then reboot.
Since this seems a bit risky I decided to "check out" the contents of the
disks before installing them.
I tried all kinds of CPIO invocations on every floppy device I have but I
kept getting read errors. I put a write protect tab on the disk and fed it
to a disk zapper on a PC. I found that the several of the sectors in track
0 were unreadable. Others were OK. (I didn't look much beyond the start of
the disk). Next I checked disk 2 of the set. It seemed to read OK.
By the way, these disks seem pretty cheap: they don't even have hub rings!
Conviced that I had a bad disk, I called AT&T and asked for another copy.
I had to wait for a technician to call me back. After describing the problem
she agreed to send me a new set of disks.
The second set arrived a few days later. Again no hub rings.
Also, again READ ERRORS at the start of the first disk from both the 3B1
and the PC.
-----------------
I wonder if the drive which is creating these disks needs an alignment...
I'm going to compare the list of bad sectors between the two disks and see
if I can piece together a good disk using the good sectors from each.
And, if someone has a good copy of FIXDISK 2.0 for 3.5, could you please
send me a UUENCODE of the first 10K-20K of the first disk?
car.
--
Christopher A. Rende Central Cartage (Nixdorf/Pyramid/SysV/BSD4.3)
uunet!edsews!rphroy!trux!car Multics,DTSS,Unix,Shortwave,Scanners,StarTrek
trux!car@uunet.uu.net Minix,PC/XT,Mac+,TRS-80 Model I: Buy Sell Trade
"I don't ever remember forgetting anything." - Chris Rendewtm@uhura.neoucom.EDU (Bill Mayhew) (10/08/90)
Yep, the fixdisk 2.0 that I got from AT&T in about March of 1990 had a couple of bad sectors on track 0 and a couple of bad sectors about half way through the first disk. The fixdisk is a big cpio archive. What I did was to format a fresh disk, then copy the bad disk onto the new, ignoring the error reports. I faked a cpio header for the bad area, losing only the CONTENTS file and one of the less interesting support files. I decided I didn't like the 3.51m kernel very much. The metermaid display and nicer any-key-including-non-typing-keys unblanking the screen were welcome additions to the kernel. What I didn't like was that I had much worse performance with uucp transfers than before. I could only get about 1000 char/sec with 3.51m, while 3.51 manages about 1400 char/sec. I tested this pretty extensively with big (~100K files) transferring to a lightly loaded HP9000 mini using a TB+ modem, so I know it isn't my imagination. If you don't use an external modem, 3.51m may be for you. There have been some reports of weird lock files getting scrambled and locking out boot-up on 3.51m. Another plus for 3.51m is that you get recognition of the WD2010 disk controller. The fixdisk is still worthwile because the support programs with fixes all seem to be backwards compatible with 3.51. ==Bill== -- Bill Mayhew NEOUCOM Computer Services Department Rootstown, OH 44272-9995 USA phone: 216-325-2511 wtm@uhura.neoucom.edu ....!uunet!aablue!neoucom!wtm via internet: (140.220.001.001)
rjg@sialis.mn.org (Robert J. Granvin) (10/08/90)
In article <261@ramecs.UUCP> car@ramecs.UUCP (Chris Rende) writes: >By the way, these disks seem pretty cheap: they don't even have hub rings! > > [...] > >The second set arrived a few days later. Again no hub rings. Unrelated to the post in general, I'd just like to point out that lack of hub rings does not indicate the comparable value or reliability of a diskette. All diskettes meet minimum specifications, and AT&T does not use disks that don't meet them. These standards in certain areas can seem to be pretty lax, but in the important areas, they're very specific, and tend to (normally) be much higher than would be necessary. Unfortunately, this doesn't guarantee a 100% success rate. Also, certain types of diskettes simply don't come with hub rings. High density disks for PC/AT's, for example, almost always come without hub rings. There are other types of diskettes for other applications or systems that also come without hub rings. In those cases, adding hub rings may increase your conscious trust of the diskette, but it doesn't really aid the diskette. The disk is no worse than others because it lacks one. -- Robert J. Granvin \\\\\\\\ rjg@sialis.mn.org : INTERNET University of Minnesota \\\ ...uunet!rosevax!sialis!rjg : UUCP School of Statistics \\\\\\\ rjg%sialis.mn.org@nic.mr.net : BITNET "Make sure your dreams last longer than the night."
rjg@sialis.mn.org (Robert J. Granvin) (10/08/90)
In article <1990Oct08.105551.28522@uhura.neoucom.EDU> wtm@uhura.neoucom.EDU (Bill Mayhew) writes: >I decided I didn't like the 3.51m kernel very much. The metermaid >display and nicer any-key-including-non-typing-keys unblanking the >screen were welcome additions to the kernel. What I didn't like >was that I had much worse performance with uucp transfers than >before. I could only get about 1000 char/sec with 3.51m, while >3.51 manages about 1400 char/sec. I tested this pretty extensively >with big (~100K files) transferring to a lightly loaded HP9000 mini >using a TB+ modem, so I know it isn't my imagination. If you don't >use an external modem, 3.51m may be for you. I certainly have no intentions to dispute observation, but I've yet to see any degradation in system or UUCP performance with 3.51m. I was one of those that worked on the field-testing of the kernel and other components for over a year prior to release, and I think I must have installed over a dozen upgrades and variants that led up to 3.51m. Throughout all this time I paid attention to my UUCP activity, since there are some annoying problems that I wanted to track down, and hopefully correct. My stats and summaries for UUCP activity, transfers and rates never significantly decreased more than can be attributed to normal fluctuations. For TB+ only sites, I'm seeing transfer rates between 1200 and 1300. Of course, my mileage may vary. But at least it's one case of where a 3b1 with an external TB+ did _not_ see a degradation from 3.51m. > There have been some >reports of weird lock files getting scrambled and locking out boot-up >on 3.51m. Has anyone ever clarified this? >The fixdisk is still worthwile because the support programs with >fixes all seem to be backwards compatible with 3.51. The fixdisk is also worthwhile because it contains all the contents of Fixdisk 1.0, and some of the errors corrected in 1.0, but especially in 2.0, are fairly critical. Some real serious work went into it by some really good people at AT&T (one in particular (Hi John! :-)), and the results are impressive. It's good to read the fixlist of what it corrects, since that may convince you to upgrade, or at least understand what's going on if you see problems... -- Robert J. Granvin \\\\\\\\ rjg@sialis.mn.org : INTERNET University of Minnesota \\\ ...uunet!rosevax!sialis!rjg : UUCP School of Statistics \\\\\\\ rjg%sialis.mn.org@nic.mr.net : BITNET "Make sure your dreams last longer than the night."
jmm@eci386.uucp (John Macdonald) (10/09/90)
In article <124@sialis.mn.org> rjg@sialis.mn.org (Robert J. Granvin) writes: |In article <1990Oct08.105551.28522@uhura.neoucom.EDU> wtm@uhura.neoucom.EDU (Bill Mayhew) writes: |>I decided I didn't like the 3.51m kernel very much. The metermaid |>display and nicer any-key-including-non-typing-keys unblanking the |>screen were welcome additions to the kernel. What I didn't like |>was that I had much worse performance with uucp transfers than |>before. I could only get about 1000 char/sec with 3.51m, while |>3.51 manages about 1400 char/sec. I tested this pretty extensively |>with big (~100K files) transferring to a lightly loaded HP9000 mini |>using a TB+ modem, so I know it isn't my imagination. If you don't |>use an external modem, 3.51m may be for you. | |I certainly have no intentions to dispute observation, but I've yet to |see any degradation in system or UUCP performance with 3.51m. I was |one of those that worked on the field-testing of the kernel and other |components for over a year prior to release, and I think I must have |installed over a dozen upgrades and variants that led up to 3.51m. |Throughout all this time I paid attention to my UUCP activity, since |there are some annoying problems that I wanted to track down, and |hopefully correct. My stats and summaries for UUCP activity, transfers |and rates never significantly decreased more than can be attributed to |normal fluctuations. For TB+ only sites, I'm seeing transfer rates |between 1200 and 1300. | |Of course, my mileage may vary. But at least it's one case of where |a 3b1 with an external TB+ did _not_ see a degradation from 3.51m. Shortly after the fixdisk came out, I recall seeing an upgrade to a adb patch that changed the system so that incoming characters got processed every 1/60 th of a second, instead of the default 4/60 th. If you (Bill) had installed the original patch on your old system, and did not install the revised patch to your updated system, you might have such a slow-down and it might not be common to all people's experiences. Me, I'm still waiting for there to be enough spare cash around here to upgrade from 3.5.1.4 to 3.51 (and of course I will install the fixdisk then - I may even do it before then since there have been no problems reported from this unsupported-but-probably-not-hazardous activity). -- Cure the common code... | John Macdonald ...Ban Basic - Christine Linge | jmm@eci386
wtm@uhura.neoucom.EDU (Bill Mayhew) (10/10/90)
One thing I should add is that my system has a voice power board in the middle slot of the backplane. I've noticed that if I run the voice manager daemon that my average uucp transfers drop from about 1400 char/sec to around 1200 char/sec (3.51). The behavior is quite repeatable by running setvm on, transferring a file, setvm off, transferring a file then compare the results. It is a bit puzzling, as the voice manager should be spending most of its time sleeping, and only needs to wake up in reponse to ring or off-hook event. The ps command corroborates this, suggesting that voicemgr is not executing a polling loop as indicated by the execution time. The decrease in uucp performance I noticed the FIXDISK kernel was about the same amount. If I get a chance, I'll switch back to the 3.51m kernel without the voice power board to see if that makes a difference. True, the max uucp rate is only about 10 to 15 percent less, but I do like the idea of saving on the order of 10 to 15 percent connect time, especially for long distance calls. I wasn't using the adb patch to change the UART polling rate on either of the two respective kernel verisons. ==Bill== -- Bill Mayhew NEOUCOM Computer Services Department Rootstown, OH 44272-9995 USA phone: 216-325-2511 wtm@uhura.neoucom.edu ....!uunet!aablue!neoucom!wtm via internet: (140.220.001.001)
afc@shibaya.lonestar.org (Augustine Cano) (10/12/90)
In article <1990Oct10.111528.13746@uhura.neoucom.EDU> wtm@uhura.neoucom.EDU (Bill Mayhew) writes: >One thing I should add is that my system has a voice power board in >the middle slot of the backplane. I've noticed that if I run the >voice manager daemon that my average uucp transfers drop from about >1400 char/sec to around 1200 char/sec (3.51). The behavior is quite >repeatable by running setvm on, transferring a file, setvm off, >transferring a file then compare the results. It is a bit puzzling, >as the voice manager should be spending most of its time sleeping, >and only needs to wake up in reponse to ring or off-hook event. The >ps command corroborates this, suggesting that voicemgr is not >executing a polling loop as indicated by the execution time. I remember reading in the voice power docs a categorical warning *NOT* to run the voice manager daemon unless you intend to run the answering machine. It seems that they knew about the performance problems. >The decrease in uucp performance I noticed the FIXDISK kernel was >about the same amount. If I get a chance, I'll switch back to the >3.51m kernel without the voice power board to see if that makes a >difference. I'd bet the culprit is setvm. >[...] > >==Bill== >-- >Bill Mayhew NEOUCOM Computer Services Department >Rootstown, OH 44272-9995 USA phone: 216-325-2511 >wtm@uhura.neoucom.edu ....!uunet!aablue!neoucom!wtm >via internet: (140.220.001.001) -- Augustine Cano INTERNET: afc@shibaya.lonestar.org UUCP: ...!{ernest,tsci,egsner}!shibaya!afc