topic Packet size query in Operating System - HP-UX

Packet size query

Gordon_3 — Sun, 02 Jul 2006 21:07:51 GMT

Hi,

Wanna know, in host level, when using netstat -I to see the no. of packets transfer, what size it is referring to? Is this a good way to determine if the Nic card is already saturated with packets? Or other better way is there? If that case, what's the theory max. no. of packets of 100Mbps / 1G Mbps NIC card? Thx.

Bgds,
Gordon

Re: Packet size query

Peter Godron — Mon, 03 Jul 2006 02:45:37 GMT

Gordon,
have you looked at thread:
http://forums1.itrc.hp.com/service/forums/bizsupport/questionanswer.do?threadId=7736

Re: Packet size query

Gordon_3 — Mon, 03 Jul 2006 20:47:14 GMT

Hi Peter,

Thx for that, so basically if I don't see any packets collision / retranmission, I can assume my NIC is still not saturated, right? Thx.

Bgds,
Gordon

Re: Packet size query

Bill Hassell — Mon, 03 Jul 2006 21:33:53 GMT

100 Mbit and 1000 Mbit cards are full duplex so it is impossible to have collisions unless the card has been mistakenly set to half duplex. The lanadmin command will report on the current settings and statistics. Saturation of the LAN card produces no errors because it is running as fast as it can. Given the overhead in running any LAN card, you can expect between 50 % and 80% as the maximum throughput. Use lanadmin to clear the stats for an accurate measurement.

Re: Packet size query

rick jones — Wed, 05 Jul 2006 13:35:23 GMT

If your _NIC_ is saturated on inbound you should see some inbound drops or discards that do not correlate to inbound errors in the second section of lanadmin output.

If you NIC is saturated on outbound, you may see outbound drops or discards not correlated to errors in the second section of lanadmin output.

Also, for outbound NIC saturation you would see the outbound queue length staying non-zero for a non-trivial length of time.

Re: Packet size query

rick jones — Wed, 05 Jul 2006 13:36:22 GMT

WRT duplex, half and full:

$ cat usenet_replies/duplex
How 100Base-T Autoneg is supposed to work:

When both sides of the link are set to autoneg, they will "negotiate"
the duplex setting and select full-duplex if both sides can do
full-duplex.

If one side is hardcoded and not using autoneg, the autoneg process
will "fail" and the side trying to autoneg is required by spec to use
half-duplex mode.

If one side is using half-duplex, and the other is using full-duplex,
sorrow and woe is the usual result.

So, the following table shows what will happen given various settings
on each side:

Auto Half Full

Auto Happiness Lucky Sorrow

Half Lucky Happiness Sorrow

Full Sorrow Sorrow Happiness

Happiness means that there is a good shot of everything going well.
Lucky means that things will likely go well, but not because you did
anything correctly :) Sorrow means that there _will_ be a duplex
mis-match.

When there is a duplex mismatch, on the side running half-duplex you
will see various errors and probably a number of _LATE_ collisions
("normal" collisions don't count here). On the side running
full-duplex you will see things like FCS errors. Note that those
errors are not necessarily conclusive, they are simply indicators.

Further, it is important to keep in mind that a "clean" ping (or the
like - eg "linkloop" or default netperf TCP_RR) test result is
inconclusive here - a duplex mismatch causes lost traffic _only_ when
both sides of the link try to speak at the same time. A typical ping
test, being synchronous, one at a time request/response, never tries
to have both sides talking at the same time.

Finally, when/if you migrate to 1000Base-T, everything has to be set
to auto-neg anyway.