meaning of buffer counters in TCPIP SHOW DEVICE BGnnnn /FULL

[Guinaudeau]

hello,

i am using VMS 7.3-2 with TCP V5.4

i observed delays on STREAM (= TCP) configured device periodically, on connections used to send refresh data frequently (normally, every 10 seconds) from VMS to a Windows client. there are circa 40 PC connected on the system and not every connections are slowed down. i observe IO waits in the counters of TCPIP SHOW DEVICE and i try to figure out why those waits occure and to lower them.

first, i try to understand the exact meaning of "SHOW DEVICE SOCKET ... /FULL" output, for BG devices of type STREAM (= TCP).

i have looked at TCPIP management reference documentation, it explains flags and some other fields look easier to understand.

concerning the buffer counters and counters of IO waits, less clear to me.

Do i miss an explanation in the documentation ?

Socket buffer bytes : (i assume it is) the number of bytes currently waiting in system buffers to be sent or received ?

Total buffer limit : (i assume it is) maximum buffer size set by SETSOCKOPT SO_RCVBUF and SO_SNDBUF ?

What do mean : Socket buffer quota ? Total buffer alloc ?

IO waits : i have seen RCV wait 0 or 1, and SEND increasing regularly to a large value, i saw more than 3000. so i am confused about what can mean these counters : number of pending waits at the snapshot time (RCV looks like this) ? or a count of wait situations since socket creation (SEND looks rather like that) ?

now the next question : what could be the reasons for these SEND IO waits : free buffer exhausted at socket level ? TCPIP window reduced or zero-window from the connection peer ?

I attach some additional informations from the system.

Thanks in advance for any help

louis

******************

Device_socket: bg1009 Type: STREAM
LOCAL REMOTE
Port: 61527 2877
Host: 192.168.72.216 192.168.74.11
Service:

RECEIVE SEND
Queued I/O 0 0
Q0LEN 0 Socket buffer bytes 0 0
QLEN 0 Socket buffer quota 4380 4380
QLIMIT 0 Total buffer alloc 0 0
TIMEO 0 Total buffer limit 35040 35040
ERROR 0 Buffer or I/O waits 1 159
OOBMARK 0 Buffer or I/O drops 0 0
I/O completed 6512 6791
Bytes transferred 284754 3205096

Options: KEEP
State: ISCONNECTED PRIV
RCV Buff: WAIT
SND Buff: None

**************************

[Richard Whalen]

I don't know the internals of TCP/IP Services, but I'll take a stab at some of your questions.

Don't worry about Socket buffer quota; that's a limit of how much unsent data your program can have pending before your program stalls until some of the buffer can be sent. Data will be sent as soon as the transmission window from the other system opens up to allow it. This is the normal flow control for TCP.

The Buffer or I/O waits could be a tuning issue. TCP/IP services uses buffered I/O and therefore needs sufficient non-paged pool. This problem could possibly be solved by tuning your system with
@sys$update:autogen savparams setparams feedback
It's also possible that this is just a count of the number of times that the program had to wait because it reached the the socket buffer quota. The example that you provided shows none in use at the moment, but it can be a very transitory thing.

[Guinaudeau]

richard,

i will not worry about socket buffer bytes, as long as it is a transient non-null value.

i have checked socket buffer quota in a test program : it corresponds in my test with sndbuf and rcvbuf options of the socket. either it corresponds with the sysconfig tcp_xxxspace value, or it corresponds with the value explicitly defined by setsockopt() call. i assume it is negotiated with the peer, and might be differently set in some cases.

the device is an application RPC binding, mostly used to transmit from VMS to PC. it has been created at RPC level and i do not know any control options about the buffer size it requests. eg no API to set this attribute. that is my trouble if (as i suspect) it could be the trouble.

about buffer or IO waits : this looks like a count of the number of times that the program had to wait. in attached file it is impressive, because more waits than send IOs. i see this rarely.

=> reached the socket buffer quota ? since only 4Kbytes, why not ?

you suggest it corresponds with transmission zero-window ( or low-window ? ) : did you read this somewhere in the documentation ?

on a test system, i can possibly TCPTRACE the troublesome connection and have a look at this counter to check for this.

but again : how to increase the quota for a test ?

=> reached a nonpaged pool limit ? sounds not the case, look at the values, current=initial, nonpaged pool reclamation is turned off and 1MB has never been allocated

yours

louis

****************

additional question :

i thought it might help the troubleshooting to use TCPTRACE between VMS production system and a certain PC where the trouble occures. they have peak of traffic Tx+Rx 200K Pk/s and 300Mb/s max 10-20 seconds whereas the test system between 5 and 10% of this peak load represents. i use large RMS buffers/IOs and large TCPTRACE buffers to avoid many direct IOs (and /HOST option to restrict). i can loose packets in the output. might it become worse and TCPTRACE usage disturb the app ??? where to pay attention to (kernel mode, process CPU, nonpaged pool ?) and how to scale what i observe on the test system ? is it safer to start with /BUFFER=5000 which is relatively small and observe and increase smoothly when packet loss occures ?

[Guinaudeau]

here the attachment

[Richard Whalen]

I see nothing in the manual to provide specific information about the numbers that you are asking about.

I don't think that system tuning is a problem from the information that you provided. Nothing in the attachment gives me a clue. You'll have to hope that someone with better knowledge of TCP/IP services looks at this question.

[Guinaudeau]

richard,

thanks.

now i received informations from HP :

1) [whatever the system, Windows or VMS] it sounds like RPC uses 4k buffers by default for TCP connections.

2) there is a way to change this behaviour under VMS : coming with V7.3-2 patch RPC V4.0,

"RPC Runtime now provides support for tuning the socket buffer size by means of a logical
RPC_USE_DEFAULT_SOCKET_BUFFER_SIZE. Setting this logical will allow RPC Runtime to make use of the system default socket buffer size values."

i tested just today this and it helps, just it does not solve completely the trouble :

=> changes for the TCP listener sockets and for the TCP sockets of bindings accepted by RPC server on VMS

=> NO change for the TCP sockets of bindings connected from RPC client on VMS to RPC server on Windows

looks like this setting i did under VMS should also happen under Windows for the other connections to be changed. but i dont know for now whether it is possible in Windows (and depending upon the system version) and how.

louis

[Guinaudeau]

thanks, louis