From: gram@uctcs.cs.uct.ac.za (Graham Wheeler)
Newsgroups: comp.unix.questions,comp.unix.wizards,comp.unix.sysv386
Subject: SVR4 network problem
Date: 6 Apr 92 15:27:11 GMT
Organization: University of Cape Town

Hi all

I have a problem with Dell SVR4 that probably has a trivial solution
lurking somewhere. It seems to be a Streams problem, or possibly due
to the change in network daemon structure between V3 and V4.

Basically, any operation which involves opening some form of network connection
is extremely slow. This includes telnet (takes about two minutes for login
prompt), netstat (can take up to ten minutes), and any forking of X clients.
Once a connection is established, performance is fine. 

This is all on a local Ethernet trunk which has only the Unix 486, a couple
of DOS PC's, and an X terminal on it. I can disconnect the X terminal with no
effect, so it isn't that.

I've spent a lot of time chasing this, concentrating on telnet. Once
you get the login prompt, everything is fine. The CPU is typically >80% idle,
so it isn't CPU load. When netstat actually reports on the net, it shows no
ierrs, no oerrs and no collisions, so it ain't network load.

Using truss and several shell scripts, I have detected the following as far as
the telnet problem goes:

1) I request a session from a DOS PC

2) inetd gets a telnet request, and confirms it immediately. An in.telnetd
process is immediately invoked.

3) in.telnetd then sits for anything from 30 seconds to 4 minutes before
executing login.

4) Once the login is executed, things go back to normal.

I have been able to pinpoint the in.telnetd delay to a set of exponentially
increasing timeouts in calls to poll(). The Streams module being polled is
/dev/udp, just after the `sockmod' module is pushed. The last call to poll is
followed by a call to close(), and then a call to access("/usr/lib/tcpip.so").
Unfortunately I don't have the in.telnetd source, so I can't tell exactly
what is going on.

If anyone can suggest a solution to this problem I would
be most grateful. The problem is obviously not in in.telnetd itself, as
netstat, ftp, etc all suffer from the problem.
Also, if I am logged on to the machine, and then do a telnet
to the same machine, it takes quite a long time before inetd gets the telnet
request (and then another age for in.telnetd to complete). All this time the
CPU is up to 99% idle, and the network is quiet.

The ethernet card is a vanilla 8-bit wdn8003 card.

HELP!
-- 
Graham Wheeler                     | "That which is weak conquers the strong,
Data Network Architectures Lab     | that which is soft conquers the hard."
University of Cape Town            | 		Lao Tzu - Tao Te Ching Ch. 78
gram@cs.uct.ac.za                  | There's no justus; there's just us
and
Graham Wheeler                     | "That which is weak conquers the strong,
Software Systems Engineer          | that which is soft conquers the hard."
Aztec Information Management       |            Lao Tzu - Tao Te Ching Ch. 78
gram@aim1.aztec.co.za              | There's no justus; there's just us


--
Graham Wheeler                     | "That which is weak conquers the strong,
Data Network Architectures Lab     | that which is soft conquers the hard."
University of Cape Town            | 		Lao Tzu - Tao Te Ching Ch. 78
gram@cs.uct.ac.za                  | There's no justus; there's just us