From: Dmitry Yusupov <dima@neterion.com>
To: Asgeir Eiriksson <asgeir@chelsio.com>
Cc: jaganav@us.ibm.com, "H. Peter Anvin" <hpa@zytor.com>,
Roland Dreier <roland@topspin.com>,
open-iscsi@googlegroups.com,
"David S. Miller" <davem@davemloft.net>,
mpm@selenic.com, andrea@suse.de, michaelc@cs.wisc.edu,
James.Bottomley@HansenPartnership.com,
ksummit-2005-discuss@thunk.org, netdev@oss.sgi.com,
Benjamin LaHaise <bcrl@kvack.org>
Subject: RE: Linux support for RDMA
Date: Fri, 01 Apr 2005 16:02:37 -0800 [thread overview]
Message-ID: <1112400157.9559.98.camel@beastie> (raw)
In-Reply-To: <67D69596DDF0C2448DB0F0547D0F947E01781F1A@yogi.asicdesigners.com>
On Fri, 2005-04-01 at 15:50 -0800, Asgeir Eiriksson wrote:
> Venkat
>
> Your assessment of the IB vs. Ethernet latencies isn't necessarily
> correct.
> - you already have available low latency 10GE switches (< 1us
> port-to-port)
> - you already have available low latency (cut-through processing) 10GE
> TOE engines
>
> The Veritest verified 10GE TOE end-to-end latency is < 10us today
> (end-to-end being from a Linux user-space-process to a Linux
> user-space-process through a switch; full report with detail of the
> setup is available at
> http://www.chelsio.com/technology/Chelsio10GbE_Fujitsu.pdf)
>
> For comparison: the published IB latency numbers are around 5us today
> and those use a polling receiver, and those don't include a context
> switch(es) as does the Ethernet number quoted above.
yep. I should agree in here. On 10Gbps network latencies numbers are
around 5-15us. Even with non-TOE card, I managed to get 13us latency
with regular TCP/IP stack.
[root@localhost root]# ./nptcp -a -t -l 256 -u 98304 -i 256 -p 5100 -P - h 17.1.1.227
Latency: 0.000013
Now starting main loop
0: 256 bytes 7 times --> 131.37 Mbps in 0.000015 sec
1: 512 bytes 65 times --> 239.75 Mbps in 0.000016 sec
Dima
> 'Asgeir
>
>
> > -----Original Message-----
> > From: netdev-bounce@oss.sgi.com [mailto:netdev-bounce@oss.sgi.com] On
> > Behalf Of jaganav@us.ibm.com
> > Sent: Thursday, March 31, 2005 5:49 PM
> > To: H. Peter Anvin
> > Cc: Roland Dreier; Dmitry Yusupov; open-iscsi@googlegroups.com; David
> S.
> > Miller; mpm@selenic.com; andrea@suse.de; michaelc@cs.wisc.edu;
> > James.Bottomley@HansenPartnership.com; ksummit-2005-discuss@thunk.org;
> > netdev@oss.sgi.com; Benjamin LaHaise
> > Subject: Re: Linux support for RDMA
> >
> > Quoting "H. Peter Anvin" <hpa@zytor.com>:
> > > Benjamin LaHaise wrote:
> > > >
> > > > I'm curious how the 10Gig ethernet market will pan out. Time and
> > again
> > > > the market has shown that ethernet always has the cost advantage
> in
> > the
> > > > end. If something like Intel's I/O Acceleration Technology makes
> it
> > > > that much easier for commodity ethernet to achieve similar
> performance
> > > > characteristics over ethernet to that of IB and fibre channel, the
> > cost
> > > > advantage alone might switch some new customers over. But the
> > hardware
> > > > isn't near what IB offers today, making IB an important niche
> filler.
> > > >
> > >
> > > From what I've seen coming down the pipe, I think 10GE is going to
> > > eventually win over IB, just like previous generations did over
> Token
> > > Ring, FDDI and other niche filler technologies. It doesn't, as you
> say,
> > > mean that e.g. IB doesn't matter *now*; furthermore, it also matters
> for
> > > the purpose of fixing the kind of issues that are going to have to
> be
> > > fixed anyway.
> > >
> > > -hpa
> > >
> > >
> > >
> >
> > No doubt, Ethernet will eventually win .. btw, Hasn't history proven
> this
> > over
> > ATM? More specifically when the industry predicted that ATM will
> replace
> > ethernet :)
> >
> > However, I'll have to agree with Ben that IB technolgy will fill an
> > important
> > niche segment, more specifically so in the low end of High Performance
> > Computing
> > (HPC) segment which is in a transition mode currently moving away from
> > proprietary interconnects to industry standards based IB technology.
> > Eventhough,
> > ethernet may eventually may catch up with IB in terms of the bandwidth
> but
> > IB
> > fabrics can offer better latencies.
> >
> > Thanks
> > Venkat
>
>
>
>
next prev parent reply other threads:[~2005-04-02 0:02 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-01 23:50 Linux support for RDMA Asgeir Eiriksson
2005-04-02 0:02 ` Dmitry Yusupov [this message]
-- strict thread matches above, loose matches on Subject: below --
2005-04-02 1:59 jaganav
2005-04-01 1:49 jaganav
2005-04-01 1:57 ` H. Peter Anvin
[not found] <20050324233921.GZ14202@opteron.random>
[not found] ` <20050325034341.GV32638@waste.org>
[not found] ` <20050327035149.GD4053@g5.random>
2005-03-27 5:48 ` [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics Matt Mackall
2005-03-27 6:33 ` Dmitry Yusupov
2005-03-27 6:46 ` David S. Miller
2005-03-28 19:45 ` Roland Dreier
[not found] ` <1112042936.5088.22.camel@beastie>
2005-03-28 22:32 ` Benjamin LaHaise
2005-03-29 3:19 ` Linux support for RDMA (was: [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics) Roland Dreier
2005-03-30 16:00 ` Benjamin LaHaise
2005-03-31 1:08 ` Linux support for RDMA H. Peter Anvin
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=1112400157.9559.98.camel@beastie \
--to=dima@neterion.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=andrea@suse.de \
--cc=asgeir@chelsio.com \
--cc=bcrl@kvack.org \
--cc=davem@davemloft.net \
--cc=hpa@zytor.com \
--cc=jaganav@us.ibm.com \
--cc=ksummit-2005-discuss@thunk.org \
--cc=michaelc@cs.wisc.edu \
--cc=mpm@selenic.com \
--cc=netdev@oss.sgi.com \
--cc=open-iscsi@googlegroups.com \
--cc=roland@topspin.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;
as well as URLs for NNTP newsgroup(s).