All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Newton <newton@unb.ca>
To: Andrew Morton <akpm@zip.com.au>
Cc: linux-kernel <linux-kernel@vger.kernel.org>
Subject: RE: excessive interrupts on network cards
Date: Tue, 25 Sep 2001 18:38:31 -0300	[thread overview]
Message-ID: <3BB11992@webmail1> (raw)

Yea, it is a single port card... I had meant to mention that in the email I 
sent out...  ie: that it wasn't reporting correctly... but, I didnt really 
think it was related, since the eepro was doing the same thing.

  As for comparing with ifconfig, I ran 'watch 1 ifconfig -a', and sure 
enough, I have about ~7000-7500 packets coming in right now.  And, the 
'procinfo -D', reports ~21000-22000 interrupts per second.

  Other sources I have used to confirm packet rate... include output from 
'sniffer', a flow generator that was monitoring that link, and the hub this 
machine is plugged into.

  the hub has 3 active ports.. port 1 is one side of our internet conenction 
(out to our provider), port 2 was from the hub over to our main router... port 
3 is a mirror of the IN on port 1 and the OUT on port 2 to port 3.  Comparing, 
and verifying, showed port 3 getting 10K packets (this afternoon, which 
obviously drops at night, which it is here now), and down to 7K now.

Chris


>===== Original Message From Andrew Morton <akpm@zip.com.au> =====
>Chris Newton wrote:
>>
>> Hi,
>>
>>   I 'think' the number of interrupts being generated for the network 
traffic I
>> monitor, is excessive.  Having talked quikly with Donald Becker, he 
indicated
>> that I should be seeing a little less than the number of RX/TX packets/s on 
a
>> wire, in terms of interrupts/s.  That, however, is not what I am seeing.  I 
am
>> seeing 3 times as many interrupts/s as I am seeing packets/s.
>>
>>   I have used three network devices to look at the stream I am monitoring, 
and
>> it is usually aorund 5K packet/s IN, and 5K out, fed full duplex into a 
single
>> 3Com 3c982 (2.4.10 kernel reports that anyways).  However, watching:
>
>3c982 is a dual-port server NIC.  Is your card dual-port?  If not, it's 
probably
>a 3c980, and I goofed :)
>
>>  'procinfo -D', reports on the order of 30,000 interrupts per second.
>
>That does sound rather high.  You should compare the interrupt rate
>with the packet rate from `ifconfig' or /proc/net/dev.
>
>Normally, 3c59x will show approx three Tx packets per interrupt
>and one Rx packet per interrupt.  It varies with workload, but
>it tends to vary in the "good" direction - at higher packet
>rates, we do more work in a single interrupt and the interrupt-per-packet
>rate falls.


             reply	other threads:[~2001-09-25 21:29 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-09-25 21:38 Chris Newton [this message]
2001-09-25 21:42 ` excessive interrupts on network cards Benjamin LaHaise
  -- strict thread matches above, loose matches on Subject: below --
2001-09-25 22:32 Chris Newton
2001-09-25 19:20 Chris Newton
2001-09-25 20:01 ` Andrew Morton
2001-09-25 20:36 ` Tim Moore

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3BB11992@webmail1 \
    --to=newton@unb.ca \
    --cc=akpm@zip.com.au \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.