GEustace@massey.ac.nz (Glen Eustace) (09/26/89)
We have a network comprising mainly of PCs and MacIntoshs. These machines
are currently being served from a Pyramid 9815 via NFS and AUFS(CAP).
Firstly let me detail our environment, and then ask my questions.
1. Pyramid 9815 OSx4.4c - Quotas enabled on most disk partitions.
Sun386i/150 SunOS4.0.1.
2. Various PC-AT, and Turbo-XT clones. PC-DOS 3.1 and MS-DOS 3.3.
PC-NFS 3.0.0, I have got 3.0.1 but these problems exist with both.
Config.sys => files=70, buffers=30, pcnfs.sys /m /f127 /s /i0
Western Digital 8003E Ethernet cards.
3. Networks is mainly thin ethernet off Multiport repeaters, these in
turn being connected via fibre and thick coax trunks. To the best
of our knowledge all of this hardware is running well within spec.
4. Network load is typically 8-10% measured with a Tektronics TDR and
the 'traffic' program on the Sun.
Problems:
1. PC-NFS Telnet. Using the telnet program that is supplied as part of
the PC-NFS product is becoming increasingly difficult as it tends to
pause in the middle of output quite frequently. Sometimes the
pause can be as long as 30 sec but typically is about 5 secs.
2. General IO Problems. Many PC applications complain about File IO
problems, these often go away when the appropriate operation is
retried. i.e. Editors complain that the directory is full when
one tries to save a file, yet a second attempt works fine.
e.g. I tried copying a large portion of my hard disk using XCOPY
to an area on the Sun. It failed 3 times in a row, each time on a
different file but always with the same error 'Access denied'.
I tried putting /t0 on the pcnfs.sys line in config.sys, all that
did was hang the machine.
3. SAS/PC 6.03. When ever SAS is run in batch mode,
i.e. H:> SAS T.SAS, it always quits with the following error
Error: Undetermined IO failure. Investigations to date indicated
it is probably when SAS tries to write the first line in its log.
As the log file is created yet never written to.
If the log file is redirected to a 'NON-Network' drive everything
is fine i.e. H:> SAS -LOG C: T.SAS. All the easy things like access
and disk space available are Ok.
When running SAS in Display Manager mode, it is not possible to
'file' the contents of any window in to a file on a network
drive. SAS just reports, Unable to create file ..... yet other
applications e.g. SPSS/PC and MINITAB don't have any trouble.
Can anyone tell me what could be causing any of the above problems. We
are running out of things to try, look at, change! It is probably
something very trivial in how we have things set up, but we can't see it.
--
-----------------------------------------------------------------------
Glen Eustace, Software Manager, Computer Centre, Massey University,
Palmerston North, New Zealand. Phone: +64 63 69099 x7440 GMT+12
E-Mail via Internet: G.Eustace@massey.ac.nz
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>craig@com2serv.C2S.MN.ORG (Craig S. Wilson) (09/27/89)
In article <309@massey.ac.nz> GEustace@massey.ac.nz (Glen Eustace) writes: >We have a network comprising mainly of PCs and MacIntoshs. These machines >are currently being served from a Pyramid 9815 via NFS and AUFS(CAP). >Firstly let me detail our environment, and then ask my questions. > >2. Various PC-AT, and Turbo-XT clones. PC-DOS 3.1 and MS-DOS 3.3. > Western Digital 8003E Ethernet cards. > >4. Network load is typically 8-10% measured with a Tektronics TDR and > the 'traffic' program on the Sun. > >Problems: > >1. PC-NFS Telnet. Using the telnet program that is supplied as part of > the PC-NFS product is becoming increasingly difficult as it tends to > pause in the middle of output quite frequently. Sometimes the > pause can be as long as 30 sec but typically is about 5 secs. > > Glen Eustace, Software Manager, Computer Centre, Massey University, I have twenty-some pc's on a thin net with a Sun 3/260 as the main server. I have experienced the delay described above and have in the past chalked it up to my configuration. I use the 3Com 3C501 cards, which have no on board intelligence. I have found that even when I am the only user on the network, I get a number of delays. In fact, it seems to be worse, when there are fewer users. I figure that my pc can't keep up with the message rate and throws some messages away. Am I close? I can't say that I have investigated this phenomenon too closely. If I had an ethernet controller with onboard intelligence, would I have the same problems? Is anyone aware of a PC-NFS driver for the Excelan 205T controller? I have about five laying around I would like to put to use. Any help on these questions is greatly appreciated. /craig Craig S. Wilson | Democracy |{amdahl|hpda}!bungia!com50!craig Com Squared Systems, Inc | is not a |craig@c2s.mn.org 2520 Pilot Knob Road | spectator |(612) 452-9522 voice Mendota Heights MN 55120 | sport! |(612) 452-3607 fax
romkey@asylum.SF.CA.US (John Romkey) (09/28/89)
In article <2701@com50.C2S.MN.ORG> craig@com2serv.c2s.mn.org (Craig S. Wilson) writes: >I use the 3Com 3C501 cards, >which have no on board intelligence. I have found that even when I am >the only user on the network, I get a number of delays. In fact, it >seems to be worse, when there are fewer users. I figure that my pc >can't keep up with the message rate and throws some messages away. > >Am I close? I can't say that I have investigated this phenomenon too >closely. If I had an ethernet controller with onboard intelligence, >would I have the same problems? Sort of. The problem is necessarily one of intelligent vs. dumb cards, though. The problem is that the 3C501 is probably the worst performing ethernet card on the market. The 3C501 is basically a 3C500 on a smaller card, with fewer components. No architectural changes. The 3C500 was the first ethernet card available for the IBM PC. It had a lot of bugs (not surprising) and a major problem with the way buffering is done - it has only one packet buffer, shared for transmit and receive. Because of this, you can't receive packets in rapid succession (never mind back to back) and you can't receive packets while you're loading the buffer with a packet to transmit. So, performance is pretty bad. My experience with intelligent ethernet cards is the only reason you'd want to run most of them under DOS is to save memory (get the TCP stack out of DOS memory). Often the programming interface is so cumbersome that there's more overhead talking to the card than there is doing the TCP protocol. The best performing smart card I've seen is the CMC ethernet card, and it does outperform the card I recommend below, but it's also more expensive. I must admit to not having done any kind of comprehensive tests among various smart cards, so I can't give you exact numbers. For a while, there was an argument that you could use a smart card with a faster processor in it than your PC and thereby gain in performance. Recently they've been lagging way behind in this area, though, and frankly, I'd much rather run my TCP on my 16MHz 80386 than on an 8MHz 80286 or even slower chip. I'd instead recommend a different dumb card, like the Western Digital WD8003E, which is one of the best performing 8 bit ethernet cards, and also one of the cheapest. -- - john romkey USENET/UUCP: romkey@asylum.sf.ca.us Internet: romkey@ftp.com "Live the life you love, Use a god you trust, and don't take it all too seriously." - Love & Rockets
milne@ics.uci.edu (Alastair Milne) (10/11/89)
romkey@asylum.SF.CA.US (John Romkey) writes: >In article <2701@com50.C2S.MN.ORG> craig@com2serv.c2s.mn.org (Craig S. Wilson) writes: >I'd instead recommend a different dumb card, like the Western Digital >WD8003E, which is one of the best performing 8 bit ethernet cards, and >also one of the cheapest. I'm glad to hear it since those are what we have. Nevertheless, the pauses in PC-NFS telnet are still there, prominently. 5 seconds is certainly not uncommon. On one or two occassions, the pause got so long it was essentially a hang, and I lost the connection. As I recall, I had to reboot the PC -- these network hangs are often unbreakable. Alastair Milne
mike@relgyro.stanford.edu (Mike Macgirvin) (10/14/89)
In article <1989Oct11.063935.8440@paris.ics.uci.edu> milne@ics.uci.edu (Alastair Milne) writes: >romkey@asylum.SF.CA.US (John Romkey) writes: >>In article <2701@com50.C2S.MN.ORG> craig@com2serv.c2s.mn.org (Craig S. Wilson) writes: >>I'd instead recommend a different dumb card, like the Western Digital >>WD8003E, which is one of the best performing 8 bit ethernet cards, and >>also one of the cheapest. > I'm glad to hear it since those are what we have. Nevertheless, the pauses > in PC-NFS telnet are still there, prominently. 5 seconds is certainly not > uncommon. On one or two occassions, the pause got so long it was While NFS activity can certainly bog down due to network loading, we resolved a lot of sluggishness on our PC's by checking all the cable connections... it seems that the temporary student who put much of the wiring in place couldn't solder very well, and also didn't know that there is a significant difference between RG-58 and RG-59 cable. We replaced the bad cable, fixed a few connectors, and VOILA!, most of the network delays vanished. Now we only see it when one of our diskless machines decides to compile emacs or something like that... you might try looking at collision statistics to figure out if it's the cabling or not. /*+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Mike Macgirvin + + - Systems Administrator Stanford Relativity Gyroscope Experiment (GP-B) + + - Internet: mike@relgyro.stanford.edu (36.64.0.50) + + - Bitnet: mike%relgyro.stanford.edu@stanford + + - Uucp: uunet!relgyro.stanford.edu!mike + + "'Scuse me, while I kiss the sky" - Robert James Marshall (Jimi) Hendrix + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++*/