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
prev parent 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 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.