All of lore.kernel.org
 help / color / mirror / Atom feed
From: Varun Chandramohan <varunc@linux.vnet.ibm.com>
To: Robert Hancock <hancockr@shaw.ca>
Cc: vatsa@linux.vnet.ibm.com, linux-kernel@vger.kernel.org,
	e1000-devel@lists.sourceforge.net, jbarnes@virtuousgeek.org,
	greg@kroah.com, netdev@vger.kernel.org
Subject: Re: Strange problem with e1000 driver - ping packet loss
Date: Tue, 24 Jun 2008 10:03:53 +0530	[thread overview]
Message-ID: <48607931.20908@linux.vnet.ibm.com> (raw)
In-Reply-To: <485A9678.5000707@shaw.ca>

cc'ing netdev

Robert Hancock wrote:
> Srivatsa Vaddagiri wrote:
>> Hi,
>>     I happened to look at a system which was exhibiting poor ping
>> performance with e1000 driver (in 2.6.25) and had some questions 
>> regarding that.
>>
>> Ping test was done between the system and a laptop, which were connected
>> using a straight ethernet cable. Ping reported round trip times running
>> into seconds (!) and also packet loss.
>>
>> Upon some investigation, I found that the interrupt count field in
>> /proc/interrupts (associated with eth1) is not incrementing as fast as
>> it should. Moreover eth1 interrupt line is shared with the hard disk
>> interrupt (ata_piix) as below:
>>
>> # cat /proc/interrupts
>>
>> .
>>
>>  10:       2296    XT-PIC-XT        ata_piix, eth0, eth1
>>
>> .
>>
>> IRQ10 is thus being shared by both the hard disk and eth0/eth1.
>>
>> Here's the strange observation I made:
>>
>> When I initiate some disk activity (ex: dd if=/dev/zero 
>> of=/tmp/file), ping performance suddently shot up (round trip time in 
>> double digits ms, 0% packet loss)! I presume this is because that 
>> e1000 intr handler is called
>> whenever there was a interrupt from hard disk on IRQ10, which polled
>> NIC and processed packets immediately.
>>
>> As soon as I kill the background disk-write intensive job, ping
>> performance again dropped.
>>
>> This meant that e1000 NIC is having trouble interrupting the OS.
>>
>> Before I could jump up and say this is a hardware issue, I was told
>> that Windows works just fine on the server (and as well as 2.4 kernel,
>> which I couldnt verify) :(
>>
>>
>> Some more observations:
>>
>> 1. I tried setting e1000 parameters (RxIntDelay=0, RxAbsIntDelay=0,
>>    TxIntDelay=0, TxAbsIntDelay=0, InterruptThrottleRate=0). None of
>>    them helped.
>>
>> 2. When ping performance was poor, readprofile showed that system
>>    is mostly idle. This confirms that OS is not getting very
>>    frequenty interrupts from eth1 and hence idling.
>>
>> 3. When ping performance was poor, ethtool -S eth1 showed that
>>    rx_bytes was incrementing at a good pace, showing that the    NIC 
>> was receiving ping responses back, but not handing them over
>>    to OS for further processing
>>
>> 4. e1000 chipset is 82546GB
>>
>> 5. e1000e driver didnt work at all (it doesnt recognize the cards).
>>
>>
>> Any advice on how to fix this problem?
>
> Can you post your dmesg output from bootup with no special options 
> (noacpi, etc.) enabled?
> -- 
> To unsubscribe from this list: send the line "unsubscribe 
> linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>


  parent reply	other threads:[~2008-06-24  4:34 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <fa.QBOn2aWyqGnBJJticG4h09lpxD0@ifi.uio.no>
2008-06-19 17:25 ` Strange problem with e1000 driver - ping packet loss Robert Hancock
2008-06-19 20:25   ` Vegard Nossum
2008-06-20 12:30   ` Srivatsa Vaddagiri
2008-06-20 14:40     ` Robert Hancock
2008-06-25 14:32       ` Srivatsa Vaddagiri
2008-06-25 18:09         ` [E1000-devel] " hong zhang
     [not found]     ` <alpine.LFD.1.10.0806251455500.3014@localhost.localdomain>
2008-06-25 19:04       ` Len Brown
2008-06-26 13:37         ` Srivatsa Vaddagiri
2008-06-24  4:33   ` Varun Chandramohan [this message]
2008-06-18 12:52 Srivatsa Vaddagiri
2008-06-18 19:18 ` Brandeburg, Jesse
2008-06-19  3:45   ` Srivatsa Vaddagiri

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=48607931.20908@linux.vnet.ibm.com \
    --to=varunc@linux.vnet.ibm.com \
    --cc=e1000-devel@lists.sourceforge.net \
    --cc=greg@kroah.com \
    --cc=hancockr@shaw.ca \
    --cc=jbarnes@virtuousgeek.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=vatsa@linux.vnet.ibm.com \
    /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.