Inbound Discards

[Tim Downs]

I have noticed that the Inbound Discards on my network card increases throughout the day. I'm wondering if this is something I should be concerned about. I do have issues with users and a gui client (Lawson) that hangs (hour glasses) periodically during the day and they have to exit the app and go back in. Could these be related?

Thanks

[Bill Douglass]

It could be a auto-negotiation problem. Check out the following thread:

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

[Tim Downs]

Both the switch and network card are set up 100 FULL DUPLEX.

[Mark Greene_1]

If you don't mind my asking, which Lawson client? We are just starting a project to purchase & install their HR product to run on a P630-6C4.

Thanks!
mark

[John Dvorchak]

when I suspect a LAN issue, I usually look at how the NIC's actually connect to the LAN. Barring any wiring issues, first thing to do is to run lanadmin and determine how the NIC is configured:

lanadmin -x

You can determine the NMID by running lanscan.

What you are looking for is wether it is 100 full or Auto etc. You can check with the network people to see what they are looking for. Typically if the LAN switch support 100 full then I would suggest that you force you NIC to 100 full as autonegotiate often messes up.

You can set this on the fly with lanadmin or, depending on the NIC you have, /etc/rc.config.d/hpbtlanconf would contain the settings and you are looking for:

HP_BTLAN_SPEED[1]=100FD

If none of this makes sense, please tell us the model of the computer and the version of the OS.

[Bill Douglass]

Is your system under load? "Inbound Discards" is listed as possibly a symptom of full network buffers.

[rick jones]

You should compare the number of inbound discards with the number of inbound frames. If the percentage is "high enough" for some definition of "high enough" then yes, it could be a problem. Could it cause a hang requiring an app restart - unlikely. However, it could cause the TCP retransmission timers to get fairly high (60 seconds) and the user may mis-interpret this as a hang and decide to exit the app.

IIRC, Inbound Discards and Inbound Errors are separate - that is one is not a superset of the other - however that could be wrong, and I suppose Discards could be a superset of Errors.

If there is a duplex mismatch between the host and the switch, I would expect to see Inbound Errors incrementing, and then also either FCS or late collision errors.

If all you see are Inbound Discards and no Inbound Errors, it means that from time to time a burst of traffic is arriving that is too much for the combination of NIC and system to handle. The drops could be in the NIC because it is not getting enough recv buffers posted in time by the driver, or it could be that the driver's attempts to allocate recv buffers is failing, or it could be that the driver's attempt to pass the packet(s) up the stack have encountered a queue limit.

[Tim Downs]

I made sure Auto-negotiation was off when we set it up. Results of lanadmin -x 0:

Current Speed = 100 Full-Duplex Auto-Negotiation-OFF

The switch is also hard coded to 100 full.

The version of the Lawson client is 7.3.3.

Also I'm only getting Inbound discards no Inbound errors.

[Paula J Frazer-Campbell]

HI

Inbound discards

"The number of inbound packets which were chosen to be discarded even though no errors had been detected to prevent their being deliverable to a higher-layer protocol. One possible reason for discarding such a packet could be to free up buffer space."

Paula

[Tim Downs]

I have also noticed with netstat -p tcp that I have 197 connect request dropped due to full queue.Should I be concerned about this.
This is an rp5405 with 4 gig ram running the Lawson application with an Oracle database and Netscape Enterprise web server. The system is rebooted every night.

[James A. Donovan]

Sounds like you may need to do a little tuning of your tcp parameters. Check the value of tcp_conn_request_max.

# ndd -get /dev/tcp tcp_conn_request_max
4096

You may need to tune other parameters as well. Take a look at this document

http://www.sean.de/Solaris/soltune.html

good tuning info

[Tim Downs]

I did change the tcp_conn_request_max from the default of 20 to 1024 last week(etc/rc.config.d/nddconf) but we are still having the issue. I will review the document and see if anything else will help. We are running HPUX 11 with 4 gig ram/ 8 gig swap. This system only has about 45 user logged in at one time. I know we have 300 web users setup but they only use the web piece to order supplies so the number of conncurrent web users is very low.

[rick jones]

tcp_conn_request_max would only be indicated if _netstat_ -p tcp showed connections dropped due to full queue. that is a very different statistic from a lanadmin inbound discards. if connections are being dropped due to full queue, the connection request packets have already made it through the NIC.

if there are just inbound discards and no inbound errors, then likely as not it represents a "simple" overload issue.

you now need to consider things like correlating the inbound discards to times when the CPU taking interrupts from the NIC is saturating. if there is not much other I/O traffic, you can use glance to see which cpu(s) have time in interrupt.

the easiest time to do this is when the system is otherwise idle and you can run say a netperf TCP_RR test through the interface to another system. then the interrupt CPU should be reasonably clear.

now, if you are on 11i, you can download the interrupt migration software from software.hp.com - that can be used to show the interrupt assignments of all the I/O devices on the system. with that you can see if say your NIC and perhaps some other busy I/O devices are sending their interrupts to the same CPU. you can then see about altering the CPU assignments to spread things out and avoid overloading any one CPU.

in general the interrupt/NIC assignment code does a good job, but like any heuristic it is a compromise.