[H-GEN] Solaris Question (Clarification)
James C. McPherson
James.McPherson at Sun.COM
Sat Jul 13 01:59:12 EDT 2002
[ Humbug *General* list - semi-serious discussions about Humbug and ]
[ Unix-related topics. Posts from non-subscribed addresses will vanish. ]
On Fri, 12 Jul 2002 21:56:29 +1000 "Scott Pullen" <spullen at optusnet.com.au> wrote:
> James thanks for that. I have already tried looking at the netstat man
> pages but it only lists the number of packets and not how "busy" this
> keeps the nics. The server is a proxy and I want to monitor the traffic
> back into the network and out over the 'net'.
> Everyone keeps telling me that you can't find out how busy the nic is
> because the kernel just routes packets to the nic for transmission and
> is not interested at what speed it is running. Fair enough, is there a
> tool that will tell me how long the wait queue is for transmission or
> the average service time for a packet? ( similiar to the iostat output
> for disks ) That will more than do to tell me how 'congested' the links
> are.
> Do I have to resort to something as crude as a ping response time (which
> has too many variables in it) to at least get some idea. Or is the only
> way to set up ntp on either end and use those statics (still the
> variables issue)? Any suggestions (as long as they are constructive
> :~)3 ) would be welcome. Can someone tell me if the kernel even keeps
> these types of stats?
Hi Scott,
you might want to have a look at your interface's intr kstat as a way to get
an approximation of what your %busy is. For example, my elx interface (see
below) has processed 2247 interrupts since the device instance was probed
at boot (10+days ago). Not a very busy interface by any means (at home with
nothing else turned on right now).
module: elx instance: 0
name: elx0 class: net
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
align_errors 0
blocked 0
brdcstrcv 2102
brdcstxmt 7
carrier_errors 0
collisions 0
crtime 85.100229075
defer_xmts 0
ex_collisions 0
fcs_errors 0
ierrors 0
ifspeed 10000000
intr 2247
ipackets 2166
ipackets64 2166
media twpair^@^@^@^@^@^@^@^@^@^@
missed 0
multircv 1
multixmt 3
norcvbuf 0
noxmtbuf 0
obytes 27408
obytes64 27408
oerrors 0
oflo 0
opackets 81
opackets64 81
promisc off^@^@^@^@^@^@^@^@^@^@^@^@^@
rbytes 320713
rbytes64 320713
rcv_badinterp 0
runt_errors 0
snaptime 898607.091774245
tx_late_collisions 0
uflo 0
unknowns 1
xmt_badinterp 0
xmtretry 0
Of course, if you are using eri, ge, hme, ce etc, then this won't help
you.
I think the primary issue that you are coming up against is that the queuing
of the packets gets done in the streams layer (don't cross the streams!),
and that is where you should be able to get most latency information.
Alteratively, you could use adb/mdb to dump the device's interrupt stats,
or you could check the number of times the interrupt thread has been called
using the callout macro.
I'll ask around internally and get back to you.
brgds,
James C. McPherson
--
Pacrim CPR Engineer 828 Pacific Highway
Gordon NSW
Sun Microsystems Australia 2072
Failfast panic: those controlling voices in my head have
stopped telling me what to do.....
--
* This is list (humbug) general handled by majordomo at lists.humbug.org.au .
* Postings to this list are only accepted from subscribed addresses of
* lists 'general' or 'general-post'. See http://www.humbug.org.au/
More information about the General
mailing list