Problems with network commands under ODT-VIEW

Wu Liu wul at sco.COM
Wed Jun 5 08:09:09 AEST 1991


/--dhiraj at bohra.cpg.oz.au (Dhiraj Sharma) said...
| I am having a problem with ODT-View:
| 
| [ descriptive text deleted... ]
|
| If after step 3 I do not switch screens and just wait, say 5-10mins, for ping
| to produce some output, ping still produces nothing, but then in other 
| multiscreens (the ones not running X) I receive the message "Out of stream 
| resources".  After which contact with all machines on the net is lost.
| 
| This problem does not only occur with ping, but also with other network
| commands as rlogin, with rlogin hanging until I switch to another screen
| and then come back to the one running X. Another example is df which
| just shows the local filesystems and none of the NFS remote mounted ones.
| 
| THESE PROBLEMS  *DO NOT* OCCUR WHEN  PING OR ANY OF THE OTHER COMMANDS ARE
| ISSUED FROM ONE OF THE SCREENS WHICH IS NOT RUNNING X.
|
| [ hardware configuration and config.h contents deleted... ]
\--

You're running out of streams buffers or queues.  Since ODT-VIEW uses
streams buffers for local X client/server communication (faster that
way) and TCP/IP (and NFS, through TCP) uses streams as well, it's
quite possible to run out, especially if you're using one or both
heavily.  The solution is to determine which streams resource or
resources are maxed out and increase them.  The crash(ADM) utility has
a command (strstat) to tell you the state of your streams resources.

You should make the change in streams resources by running the
configure(ADM) tool as root.  You'll need to relink your kernel.

The process it somewhat painful (if you don't guess right, you'll have
to reconfigure, relink, and reboot until you do), but worth the effort.

If you use NFS heavily, you'll want to increase the number of 4k, 2k,
and 1k buffers.  TCP and Xsight tend to want use the 16-512 byte buffer
sizes.  Each system configuration will vary, so it's very much a trial
and error process.  Good luck.



More information about the Comp.unix.sysv386 mailing list