[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