ip_send_source_quench

[Pete Ellis]

All the documentaion says disabling quenching just stops the message.
So why does telnet access improve and ping lose less packets ?

I have checked other threads and this question has been asked before, but NOT answered.

Pete

[Steve Massey_1]

Pete

How about the reply by James..

http://forums.itrc.hp.com/cm/QuestionAnswer/1,1150,0x18c779bffde7d4118fef0090279cd0f9,00.html

Steve

[Pete Ellis]

Steve,

I have read this thread and document and it states:

Setting the ndd parameter ip_send_source_quench to 0 can be an effective way to deal with the messages. Programs that use icmp protocol, such as ping, use a type of socket called SOCK_RAW. The nature of using raw IP sockets is that ALL packets received that match the protocol type of the raw socket are delivered to ALL the sockets using that protocol. It is up to the application to read all the data in it's socket buffer and discard the data it's not interested in. If any of these sockets are full, the icmp source quench message will be generated.

The term "effective way to deal with the messages" suggests it does not deal with the problem, the sockets are still full. When quenching is disabled we have seen a massive improvement in the performance of telnet.

I just want to know why telnet should improve, if it uses SOCK_RAW then disabling quenching would just surpress the messages and would not empty the sockets quicker. I see there is a patch (PHSS_17810) which increases the buffer size, but ip_send_source_quench can't do that.

Pete

[Rita C Workman · Accepted solution]

Well, communication is not my strong point...but I'm gonna try here...
The reason you see improvement, is because a message stating 'source quench condition' is not being sent. Thus freeing up network message traffic. Since other processes use this same socket...it's hard to tell what improvement you will see when you disable the source quench message. It's like the difference between tcp and udp messages...if a packet send requires a response, you'd see a reduction in performance, but if you set some processes to just do udp packet sends...then you'd see an improvement since it doesn't have to send a response. Other processes like rpc are constantly sending messages to check for something that needs to run.
You can change or tune some network parameters and I'm sure you've realized that when you looked over the manpage on ndd. But unfortunately ip_send_source_quench you may have noticed is not one of them. You can only turn it off (=0) to help tune/improve by reducing unnecessary network traffic.
Now you might be able to tune others via the ndd or via changes to the ~/nddconf file...but that's a whole 'nother issue.
At least this is what I understand...right or wrong....like I said communication is not my strong point...

/rcw

[Pete Ellis]

Rita,

You communicated your reply very well. I agree that if the source server stops wasting time saying I'm busy and just gets on with it, the job will get done guicker (I must communicate this to users,! maybe when I'm sorting out their mistakes they will stop ringing me up asking when it will be fixed, thus it will be fixed guicker. users, don't you just love em!)

All the threads and documentation just stated that the messages were just a nuisance. But in our case it was causing telnet to bomb out on live internet servers, I've been blaming the firewall for weeks, doh!!!

Regards
Pete