public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Dumazet <dada1@cosmosbay.com>
To: Rick Warner <rick@microway.com>
Cc: linux-kernel@vger.kernel.org, eliot@microway.com
Subject: Re: latency doubled on tg3 device from 2.6.11 to 2.6.12
Date: Fri, 02 Sep 2005 16:33:36 +0200	[thread overview]
Message-ID: <431862C0.7040305@cosmosbay.com> (raw)
In-Reply-To: <200509020956.00690.rick@microway.com>

Rick Warner a écrit :
> On Thursday 01 September 2005 05:46 pm, Eric Dumazet wrote:
> 
>>Rick Warner a écrit :
>>
>>>Hello,
>>> We have been testing latency and bandwidth using our proprietary MPI
>>>link checker tool (http://www.microway.com/mpilinkchecker.html) and have
>>>found that the latency increased from ~25ms to ~45ms going from 2.6.11 to
>>>2.6.12. 2.6.13 has the same result.  We also tried the latest bcm5700
>>>from broadcom (8.2.18) and got the same ~45ms latencies.  This was tried
>>>on several different opteron and em64t motherboards.
>>>
>>> We see 20-25ms latencies with the e1000 driver (with some module
>>>options) on all 3 kernel versions.  For those interested, the e1000
>>>options used are:
>>>
>>> InterruptThrottleRate=0 RxIntDelay=0 TxIntDelay=0 RxAbsIntDelay=0
>>>TxAbsIntDelay=0
>>>
>>> Digging through source, it seems that a new locking mechanism for tg3
>>>was put in place in 2.6.12.  Is this the likely cause?  What can we do to
>>>restore our lower latency?
>>
>>Could you please define latency ?
>>
>>tg3 driver was recently updated to use coalescing.
>>
>>So when the nic receives one frame, it may delay up to XXXX us ( XXXX <
>>1024) the interrupt.
>>
>>But 25 ms is far more than 1024 us, so I dont think this coalescing can
>>explain your problem.
>>
>>The HZ change from 1000 to 250 could be the root of the problem ?
>>
>>Using a simple ping between 2 machines with tg3, I get less than 1ms time.
>>
>>Eric
> 
> 
> Our mpi link checker tool does a 1 way transfer of a 0 byte message (+ header) 
> and times it to each system (in addition to other tests).  All systems in a 
> cluster are showing the same high latency.  The numbers I gave were supposed 
> to be us, I used the wrong unit by accident.
> 
> Low latency is often essential to clustered applications.  While a delay of up 
> to 1024 us doesn't affect regular communications too much, it may severely 
> affect mpi jobs.
> 
> Thanks.
> 

OK

tg3 driver set a rx-usecs of 20us per default.
This is certainly the root of your problem.

Try to lower it on mpi links ?

ethtool -C eth0 rx-usecs 0

Eric

      reply	other threads:[~2005-09-02 14:33 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-01 21:30 latency doubled on tg3 device from 2.6.11 to 2.6.12 Rick Warner
2005-09-01 21:46 ` Eric Dumazet
2005-09-02 13:56   ` Rick Warner
2005-09-02 14:33     ` Eric Dumazet [this message]

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=431862C0.7040305@cosmosbay.com \
    --to=dada1@cosmosbay.com \
    --cc=eliot@microway.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rick@microway.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox