kessler%cons.utah.edu@wasatch.utah.edu (Robert R. Kessler) (08/24/89)
We are running on a PS/2 Model 80, using SCO Xenix 2.2.x. We have an Arnet Smartport from which we run a half a dozen terminals. The problem is that when someone does a tar (to our Mountain tape drive), all of the devices connected to the Arnet board hang up. So, we have to have everyone log out, do the tar, then everyone logs back in. SCO claims that tar uses so much of the system resources that the Arnet board gets lost. Is this true? Has anyone experienced anything similar. B.
daveh@marob.masa.com (Dave Hammond) (08/25/89)
In article <3195@wasatch.utah.edu> Robert R. Kessler writes: >We are running on a PS/2 Model 80, using SCO Xenix 2.2.x. We have an >Arnet Smartport from which we run a half a dozen terminals. The problem >is that when someone does a tar (to our Mountain tape drive), all of >the devices connected to the Arnet board hang up. So, we have to have >everyone log out, do the tar, then everyone logs back in. SCO claims >that tar uses so much of the system resources that the Arnet board >gets lost. We have several machines running SCO 2.2 and 2.3, all configured with an Arnet Smartport and a Mountain internal tape drive. All are AT-bus machines (286 ATs, 286 Compaqs and 386 clones). Tar has always been used to backup these machines (often while users are logged in) with no such effect. Therefore, unless the PS/2 (or the MCA) is a special case, IMO the SCO response is an unlikely possibility. The Arnet uses no hardware interrupts in smart mode, so an interrupt conflict is unlikely. I would check for a conflict between the Arnet and Mountain controller memory addresses. You might even check conflicts between the disk-cache memory address (if any) and the other 2 controllers. -- Dave Hammond daveh@marob.masa.com
clewis@eci386.uucp (Chris Lewis) (08/26/89)
In article <3195@wasatch.utah.edu> kessler%cons.utah.edu@wasatch.utah.edu (Robert R. Kessler) writes: >We are running on a PS/2 Model 80, using SCO Xenix 2.2.x. We have an >Arnet Smartport from which we run a half a dozen terminals. The problem >is that when someone does a tar (to our Mountain tape drive), all of >the devices connected to the Arnet board hang up. So, we have to have >everyone log out, do the tar, then everyone logs back in. SCO claims >that tar uses so much of the system resources that the Arnet board >gets lost. > >Is this true? Has anyone experienced anything similar. The question I have in response is how "hung" do they get? Bursty? Or totally dead? Bursty is typical of many systems with tape drives. Though, on better systems it should be almost imperceptable. Full blown hung is another story: It's not truly tar's fault - 1/4" streamer drivers are extremely difficult to write, many of them will have interrupts disabled (eg: no terminal I/O) for relatively long periods of time - in order to get the stupid thing streaming, they heavily hog the CPU to make sure that they don't miss the inter-command timing windows (typically a couple of milleseconds before the tape drive decides to stop and backup). It *shouldn't* be particularly objectionable - especially since Xenix 2.2.x tar can't talk in buffers bigger than 32K (or is it 64K? doesn't matter...), so you should get slices occasionally. Does your tape drive do a lot of "shoe-shining"? If not, well, you'd best live with the situation - it's so damn difficult (and important) to keep these drives streaming, that it's worth almost anything to get them to do it. If they do "shoe-shine", I suspect that the Mountain Driver or possibly the Arnet (tho, I doubt it due to the reviews I've heard) is doing some disgusting things with the interrupt level or something. (I assume that the Mountain driver is not the same as the Wangtek) Bitch loudly. There is a remote possibility that you have the card's interrupt set wrong, but *those* symptoms are *extremely* slow tape I/O - which you don't seem to be having. I've been hearing rave reviews on Xenix 2.3.1 Wangtek tape driver performance on 20Mhz or so CPU's, so it might be time to upgrade your O/S (especially if the Mountain driver is the same as the Wangtek). -- Chris Lewis, R.H. Lathwell & Associates: Elegant Communications Inc. UUCP: {uunet!mnetor, utcsri!utzoo}!lsuc!eci386!clewis Phone: (416)-595-5425
valsee@qat.UUCP (08/26/89)
well, sco might be right. i had a similar situation here with a 386 AT-type machine with two arnet smartport-8 boards... whenever anyone queued a print job beyond a certain length, the arnet boards would go out and talk to the little animals. this was on sco 2.2.4 and fairly early arnet drivers. in this case, talking to arnet revealed that they knew about this, and had rewritten their installable drivers to fix it. i got a new driver disk, which fixed the problem. i don't know that the microchannel arnet board drivers have similar problems, but calling arnet and asking them about it couldn't hurt. valerie see ...attctc!texbell!techsup!qat!valsee ...attctc!texbell!techsup!seev
bruce@mdi386.UUCP (Bruce A. McIntyre) (08/27/89)
In article <3195@wasatch.utah.edu>, kessler%cons.utah.edu@wasatch.utah.edu (Robert R. Kessler) writes: > > > We are running on a PS/2 Model 80, using SCO Xenix 2.2.x. We have an > Arnet Smartport from which we run a half a dozen terminals. The problem > is that when someone does a tar (to our Mountain tape drive), all of > the devices connected to the Arnet board hang up. So, we have to have > everyone log out, do the tar, then everyone logs back in. SCO claims > that tar uses so much of the system resources that the Arnet board > gets lost. We use the Arnet Smartport on various machines, with the Archive board... I have not seen any of the machines exhibit this behavior. The machines we use are: 1. Compaq deskpro 386/20 2. Mylex 386/16 Since the Arnet board doesn't use interrupts, there should be no real problem with the tape drive. Make sure that there is no other problem, like shared memory being trashed because of cache, etc. bruce -- ========================================================================= Bruce A. McIntyre, McIntyre Designs, Inc. VOICE(215)322-1895 143 Bridgetown Pike, Langhorne, Pa. 19047 DATA (215)357-2915 {wells|lgnp1}!mdi386!bruce bruce@mdi386 tbit+