<?xml version="1.0" encoding="UTF-8"?>
<!-- Generated on Tue, 24 Nov 2009 23:21:13 -0800 -->
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <atom:link href="http://software.intel.com/en-us/articles/intel-direct-ethernet-transport/feed/" rel="self" type="application/rss+xml" />
    <title>Intel Software Network Comments feed</title>
    <link>http://software.intel.com/en-us/articles/intel-direct-ethernet-transport/feed/</link>
    <description></description>
    <language>en-us</language>
    <item>
      <title>By jmbnyc@gmail.com</title>
      <description><![CDATA[ Very timely, useful and interesting library. The documentation is lacking (thanks for producing man pages but they are not sufficient for trying to learn how to use the API). In addition, the abstraction is weak. I am going to try to put a C++ abstraction over the top of the det user space API so that the code can be made more accessible to developers. With multi-core, 10GbE and rack density improvements having kernel bypass communication is a huge win in terms of latency. I just wish a little more time was put into the documentation that covered the basic design of the API. The ping pong code does a good job, but it would be nice if it was in a real document with some diagrams and some commentary around buffer sizes.

/JMB ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-direct-ethernet-transport/#comment-9157</link>
      <pubDate>Sat, 22 Nov 2008 11:15:01 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-direct-ethernet-transport/#comment-9157</guid>
    </item>
    <item>
      <title>By terrs</title>
      <description><![CDATA[ sound good.  someone has testing Benchmarks ?  ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-direct-ethernet-transport/#comment-9488</link>
      <pubDate>Sun, 07 Dec 2008 06:55:49 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-direct-ethernet-transport/#comment-9488</guid>
    </item>
    <item>
      <title>By Mardel</title>
      <description><![CDATA[ Any benchmarck or laboratory test for this project ?
We will implement a new HPC cluster and we would like 10 Gb instead of
IB....if Intel DET works we could use it for interconnect 

 ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-direct-ethernet-transport/#comment-24003</link>
      <pubDate>Fri, 08 May 2009 00:20:49 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-direct-ethernet-transport/#comment-24003</guid>
    </item>
    <item>
      <title>By rklarsen</title>
      <description><![CDATA[ I can supply some sample data points for the micro benchmarks NetPIPE which measures one-way latency and bandwidth through a ping-pong message exchange.  I have a modified NetPIPE that adds DAPL as a transport interface.  The sender uses RDMA writes while the receiver polls memory to determine message arrival.  This is similar to how MPI libraries use RDMA transports.

The benchmark was run using 3.6Ghz Xeon CPUs with Intel 82598EB 10Gig Ethernet NICs (Oplin) through a Fujitsu XG-700 switch.  The Ethernet driver was configured for immediate interrupt on frame arrival.  This should give you a sense of the best case potential for DET.

Netpipe Latency (usec)

Msg Size	tcp	det/dapl
      1	19.47	10.10
     16	19.48	10.16
     64	19.74	10.33
    256	20.70	11.69
   1024	23.30	14.23
   4096	33.33	22.76
  16384	63.19	53.90


Netpipe Bandwidth (Mbits/s)

Msg Size	tcp	det/dapl
   65536	4031	4228
 131072	4791	4990
 262144	4644	5326
 524288	3999	5250
1048576	3802	5105
2097152	3979	5026
4194304	3763	4973


 ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-direct-ethernet-transport/#comment-24034</link>
      <pubDate>Fri, 08 May 2009 11:12:50 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-direct-ethernet-transport/#comment-24034</guid>
    </item>
    <item>
      <title>By rklarsen</title>
      <description><![CDATA[ hmmm, let's see if this is easier to read....

Netpipe Latency (usec)

Msg Size / tcp / det-dapl
      1 / 19.47 / 10.10
     16 / 19.48 / 10.16
     64 / 19.74 / 10.33
    256 / 20.70 / 11.69
   1024 / 23.30 / 14.23
   4096 / 33.33 / 22.76
  16384 / 63.19 / 53.90

Netpipe Bandwidth (Mbits/s)

Msg Size / tcp / det-dapl
  65536 / 4031 / 4228
 131072 / 4791 / 4990
 262144 / 4644 / 5326
 524288 / 3999 / 5250
1048576 / 3802 / 5105
2097152 / 3979 / 5026
4194304 / 3763 / 4973
 ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-direct-ethernet-transport/#comment-24035</link>
      <pubDate>Fri, 08 May 2009 11:16:41 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-direct-ethernet-transport/#comment-24035</guid>
    </item>
    <item>
      <title>By rklarsen</title>
      <description><![CDATA[ I neglected to mention that the MTU size was set to 9000 for the NetPIPE test run. ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-direct-ethernet-transport/#comment-24049</link>
      <pubDate>Fri, 08 May 2009 15:44:58 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-direct-ethernet-transport/#comment-24049</guid>
    </item>
    <item>
      <title>By Mardel</title>
      <description><![CDATA[ I just see you results today. THXS ! and I'm still analysing and trying to understand it.
One more question:
Could you have any chance to compare(to have an idea) your results against IB QDR ?

Kindest Regards and THXS again,

Mardel

 ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-direct-ethernet-transport/#comment-24231</link>
      <pubDate>Tue, 12 May 2009 08:50:05 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-direct-ethernet-transport/#comment-24231</guid>
    </item>
    <item>
      <title>By rklarsen</title>
      <description><![CDATA[ No, I don’t have QDR results and I’m not sure what could be gleaned from comparing a 40Gbs HCA to a 10Gbs commodity NIC.   However, I do have SDR IB results that were measured on the same platform which are at least more of an apples-to-apples comparison.

Netpipe Latency (usec)

Msg Size / tcp / det-dapl / ib-dapl(SDR)
      1 / 19.47 / 10.10 / 3.41
     16 / 19.48 / 10.16 / 3.50
     64 / 19.74 / 10.33 / 3.71
    256 / 20.70 / 11.69 / 4.68
   1024 / 23.30 / 14.23 / 6.27
   4096 / 33.33 / 22.76 / 10.64
  16384 / 63.19 / 53.90 / 25.15

Netpipe Bandwidth (Mbits/s)

Msg Size / tcp / det-dapl / ib-dapl(SDR)
  65536 / 4031 / 4228 / 6829
 131072 / 4791 / 4990 / 7145
 262144 / 4644 / 5326 / 7313
 524288 / 3999 / 5250 / 7398
1048576 / 3802 / 5105 / 7444
2097152 / 3979 / 5026 / 7468
4194304 / 3763 / 4973 / 7479
 ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-direct-ethernet-transport/#comment-24233</link>
      <pubDate>Tue, 12 May 2009 09:43:49 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-direct-ethernet-transport/#comment-24233</guid>
    </item>
    <item>
      <title>By marc</title>
      <description><![CDATA[ when I load the module and start det_perf I get 

marc@mlnx_lab01:~/det-1.1/det-1.1.0/kernel$ ../../examples/det_perf

Running as server on eth0
det_open: No such file or directory

i checked the src but can not see where /dev/det gets created

Marc ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-direct-ethernet-transport/#comment-27859</link>
      <pubDate>Sat, 18 Jul 2009 08:30:34 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-direct-ethernet-transport/#comment-27859</guid>
    </item>
    <item>
      <title>By rklarsen</title>
      <description><![CDATA[ Marc,

It sounds like loaded the driver manually in which case you'd have to make the /dev/det character device node manually with mknod(1).  The preferred way is to invoke the control script which is found in /etc/init.d/det if you did a formal installation of the package.  If not, you'll find it at det/usr/det in the tarball.  The arguments to the script are [start] | [stop] | [restart].  If you'd still rather do it all manually, you can discover the major device number after the driver is loaded by cating /proc/devices.

Roy ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-direct-ethernet-transport/#comment-27950</link>
      <pubDate>Mon, 20 Jul 2009 10:28:40 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-direct-ethernet-transport/#comment-27950</guid>
    </item>
    <item>
      <title>By Cluster Connection &amp;raquo; Why Is InfiniBand (and other interconnects) So Fast?</title>
      <description><![CDATA[ n/a ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-direct-ethernet-transport/#comment-30209</link>
      <pubDate>Wed, 26 Aug 2009 10:16:21 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-direct-ethernet-transport/#comment-30209</guid>
    </item>
    <item>
      <title>By brian</title>
      <description><![CDATA[ Thanks a great deal for this, I hope you're finding enough support to continue development. Could you elaborate a bit as to how multicast, and perhaps udp in general is handled? ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-direct-ethernet-transport/#comment-31376</link>
      <pubDate>Tue, 22 Sep 2009 06:07:02 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-direct-ethernet-transport/#comment-31376</guid>
    </item>
    <item>
      <title>By rklarsen</title>
      <description><![CDATA[ Brian,

I'm sorry for the delayed post.  To be clear, the Direct Ethernet Transport does not use IP protocols so I assume you’re asking if something like the InfiniBand unreliable datagram service along with multicast is implemented.  The answer is no and we have no plans for implementing it.  A reliable connected service is the only one available.

Roy
 ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-direct-ethernet-transport/#comment-32624</link>
      <pubDate>Tue, 13 Oct 2009 09:53:24 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-direct-ethernet-transport/#comment-32624</guid>
    </item>
  </channel></rss>