smenda@aldetec.oz.au (Greg Smenda) (11/02/90)
We are running a TCP/IP network that is displaying some funny characteristics.
The basic setup is a motorola Delta 1147 system
connected to MVME147 processor board running pSOS+ real time operating system
and pNA (it's tcp-ip module).
The pNA side acts as a server, with sockets being created in SOCK_STREAM mode.
Our delta machine is doing a blocked read on the opened socket, yet
after a burst of data has commenced, some reads are only partially completing -
i.e 200 bytes of a 500 byte packet is returned, and the remaining 300 bytes
must be 'mopped-up' in the next read. The real crunch is that our data
transfer seems to grind to a halt, with mopup reads required on nearly every
unit of data that is transferred from the pSOS system. Also the time taken to
actually read a complete packet goes way down the gurgler when these mopup
reads are required.
Running a similar data transfer between 2 delta machines results
in similar problems, although the dreaded time-lag in mopping up doesn't
appear to be present.
Typically, a burst of data may be 5000 514-byte packets, sent at a rate of
5-20 a second ... Degradation can been seen from as early as the 20th packet.
(The test between the 2 delta machines was transferring at a faster rate,
allowing for time-sharing etc)
I've tried using 'nettrace', which returns streams of information, most that
does not concern the connection of interest. However, messages are rapidly
sent to the console while this program is running, giving the diagnostic
message 'if37x_rx: trace packet dropped - canput failed'. Some packets of
interest that nettrace does report concerning our link, have a TCP flag value
of RESET, where can I get info on what this means? Are there other utilities
that may assist a novice networker in monitoring a specific connection,
particularly being able to identify data that has arrived but not been read,
and reporting any 'out-of-the-ordinary' retries/errors in the data transfer
for that connection. (If not, what about information on structures,
routines that I could use to monitor the socket from a program ??)
--
__________________________________________________________________________
Greg Smenda Internet : smenda@aldetec.oz.au
ACSnet : smenda@aldetec.oz
Voice : +61-9-4451888 0800 - 1730 WST
System Administrator : +61-9-3859521 otherwise
Aldetec Pty Ltd.
- Fishy fishy fishy fish, it would go where ever I did go -
__________________________________________________________________________