Check for discards at udp Recv-Q netstat -a

[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.