Check for discards at udp Recv-Q netstat -a

[Martin Wolff]

Hi,
I am looking for a way to know if the Recv-Q shown at the netstat -a command is discaring or not.
I have seen that the queue increments as traffic arrives heavily from "outside" the server.
Because of some issues at the aplication that retrieves the data, i am suspicious that there may be discards at a queue for a particular udp port (1813 to be precise).
So i would like to know how can i check for discards.

Platforms checked are DS-10 standalone, and DS-25 cluster, running TRU-64 5.1B PK4.

Thanks in advance,
Martin.

[Martin Wolff]

I guess this is the worst time of the year to post a question , jeje :)

[cnb · Accepted solution]

netstat -id will show dropped stats
netstat -s shows all stats

for packet stats #man pfstat.

[Martin Wolff]

Thank you very much,

Using netstat -s, i see now that discards at udp due to "full sockets" are probably the cause of the application issue i am having.

Is there a way to know the size of the UDP buffer, and a way to increase the buffer size?

Thank you very much in advance again,

Martin.

[cnb]

To know the size:

#man UDP

Rgds,

[cnb]

Please ignore my last post. I was thinking of HP-UX!

You might find answers here:

http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V51B_HTML/ARH9UETE/DLPPNDXX.HTM#buf-size

Rgds,

[cnb]

Martin,

This may be what you're looking for:

http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V51B_HTML/ARH9GCTE/TNRCLXXX.HTM#udp-recvspace

http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V40F_HTML/AQ0R3GTE/CHNTXXXX.HTM

http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V40F_HTML/AQ0R3GTE/CHNTXXXX.HTM#net-qlimit

[Martin Wolff]

Thank you very much,
I will have a look at those docs now,
Kr,
Martin.

[Martin Wolff]

Hi, you are right it was all there!!

To see the size of the udp send and receive buffers:

sysconfig -q inet udp_recvspace
sysconfig -q inet udp_sendspace

To see the buffer size limits:

sysconfig -Q inet udp_recvspace
sysconfig -Q inet udp_sendspace

To change the size permanently:

sysconfigdb -a -f stanza_file inet

Where stanza file is like this:

inet:
udp_recvspace = 1024000
udp_sendspace = 1024000

This change is applied at the next reboot,

but using

# sysconfig -r inet udp_recvspace=1024000
udp_recvspace: reconfigured

you can reconfigure the attribute on the fly so you do not have to wait to reboot to get the change done.

Thank you very much for pointing me to those docs!!!!

Kind regards,
Martin.

[cnb]

Glad you were able to locate everything!


Best Regards,
cnb

[Martin Wolff]

Hi,

After testing i have observed that the behaviour is not what i expected.

After setting the udp_recvspace = 1024000

using netstat -an i still see that the R-queue of the udp socket i am using never exceeds the ~65KB, and i still see full sockets discards at netstat -s for udp protocol.

Please observe the following:

10.2.14 Increasing the Transmit and Receive Buffers for a UDP Socket

Tells that:

"You can increase the values of these attributes to 64 KB"

But, from the result of the command:

# sysconfig -Q inet udp_recvspace
inet:
udp_recvspace - type=UINT op=CRQ min_val=1 max_val=4294967295 (i guess the unit is byte here?)

The limit is ~4GB,

I changed the atribute at runtime without rebooting, but the attribute udp_recvspace is CRQ so it should work..

I have also checked that sb_max of the socket subsystem was greater than the value i set for udp_recvspace as stated at:

10.2.18 Increasing the Maximum Size of a Socket Buffer

Maybe i am doing something wrong?
Or missing something?
Or the max value shown at sysconfig is wrong?

Thanks in advance,

Kr,
Martin.

[Rob Leadbeater]

Hi Martin,

The man page for sys_attrs_inet will tell you the relevant default and maximum values...

udp_recvspace has a maximum value of UINT_MAX or 4 billion bytes, but not larger than sb_max.

Cheers,

Rob

[cnb]

Martin,


You might want to run sys_check and take a look at the entire snapshot of the system to make sure other parameters are properly set as well as the overall health of the system components.

http://h30097.www3.hp.com/sys_check/


http://h20392.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=T64_sys_check


Other perfomance areas:
http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V51B_HTML/ARH9GCTE/CHPNTXXX.HTM


http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V51B_HTML/ARH9CDTE/TITLE.HTM


Rgds,

[Martin Wolff]

Thank you both for your help i have already checked the sys_attr_inet and sys_attr_socket for the max values there.

I will have a look at sys_check.

But also i see that the ipqmaxlen value is set to 1024 bytes, this is the maximun length for ip packet queue. It looks very small...

It´s not clear to me how it works,
Perhaps it´s like this:
As soon as the packet enters the ip queue the O.S. determines where to send it? Let say, to which socket to send it?
That´s why is so small? the packets are left there for inspection to be delivered to the correct subsystem - socket for example.

Am i too far from the correct answer?

By the way i will reboot the server just in case it´s needed.....

[Rob Leadbeater]

Hi,

I could be completely off the mark here, but I'm wondering if you would benefit from altering the MTU on the NICs. If you have a Gigabit LAN infrastructure then Jumbo packets may possibly help. (man alt or man bcm).

Cheers,

Rob

[Martin Wolff]

Hi Rob,

The thing is that the aplication this server is running is kind of an enhanced RADIUS server. So it expects to receive UDP packets of aprox 600 bytes. As far as i know the client nor the server can send or receive more than one RADIUS message inside the same UDP payload. So every frame received for this aplication will be aprox 600 plus eth overhead.

Kind regards,
Martin.

[Martin Wolff]

I have rebooted the server, and it looks better now...
I am making heavy tests in order to check if there are no more full socket discards.

I´ll post a note when i have clear results...

Kr,

Martin.

[Martin Wolff]

I have done more tests, and i did not loose packets.

So i put back the buffer size, and i started having full socket issues again.

For the record:

sysconfigdb -a -f stanza_file inet

will not work if the parameter is already defined in /etc/sysconfigtab, if so run:

sysconfigdb -u -f stanza_file inet

-u is to change a parameter that already exists in /etc/sysconfigtab

Thank you all, i will close the thread now.

[Martin Wolff]

One of the commands i stated before is dangerous and can harm your system,

Please note when using:

sysconfigdb

That the -u option replaces all the parameters at the given subsystem with the ones at the specified file.
If the stanza file you pass has less parameters than the configured ones at the sysconfigtab file, then the rest of the parameters will take the default values(need to verify if the defaults are set, but for sure the ones that were configured get lost)

So if you want to add or change new parameters to a subsystem use the -m option!!!

Also it´s not needed to reboot the server,

the problem with the -r option was that the aplication that was using the sockets need to be restarted, then when they open the sockets again the size was raised to the configured one.


Kind regards,
Martin.

[Martin Wolff]

I found the solution thanks to the documentation i was pointed to, thanks a lot!!

Please consider my last post, regarding the parameters to use for sysconfigdb. It´s very important!!!

Thanks all of you for your help.

Martin.