Parallel sockets or?
bruce.labitt at autoliv.com
bruce.labitt at autoliv.com
Thu Oct 8 09:29:18 EDT 2009
> bruce.labitt at autoliv.com wrote:
> > The TCP connection to my FFT server is not performing anywhere near
the
> > link speed. (14%)
<snip>
> >
> > Reading some papers about increasing WAN performance between super
> > computers mentioned the use of parallel sockets to increase TCP
network
> > throughput. The parallel sockets with default TCP settings had higher
> > throughput than a single "highly tuned" socket. There are quite a few
> > papers explaining how this can be.
> >
<snip>
> > I did find UDT, which looks interesting. For the main transport it
uses
> > UDP, with overhead to make it "reliable". Supposedly it is very fast.
I
> > did try the test code, at least the project compiled, and I managed to
> > send data at 650Mbps, across my local network, if I believe its
> > diagnostics. Unfortunately for me, it is written all in C++, which
makes
> > it hard for me to understand how to use it. If at all possible, I'd
like
> > to use simpler, C libraries and TCP.
> >
> > Suggestions, comments, where do I go from here???
> >
> > Regards,
> > Bruce
> >
<snip>
> >
> There is another way to radically increase communication speed that is
> very popular in the cluster world. Basically hardware is added to allow
> memory to memory writing. One node communicates with another by writing
> into this device which is mapped to the other nodes memory controller (a
> 50,000 foot simplification but useful). Here is an article that
> describes "cluster interconnects":
>
> http://www.clustermonkey.net//content/view/124/34/
>
> You might find this useful for more than your current project.
>
> -Alex
Thanks for the link. It was an interesting read.
Unfortunately, the RDMA NICs are not a solution for me right now. Whereas
one could replace the NIC in my workstation, it is not so easy in my
bladeserver chassis. For the moment I am stuck with software only
solutions. I could go to 10Gb ethernet, but the upgrade would be steep
$$$ at this time. Even if one were to go 10Gb, the essential problem of
not filling the pipe is there - (TCP is apparently not so good for filling
the pipe without tweaks) not to mention the additional CPU load. One
additional comment on the article - good overview (10000+ ft), sparse on
implementation details.
I will play about with psockets for a little while longer - until I get
too frustrated. /ranton An unfinished project is kind of hard to pick up,
especially if there aren't any notes somewhere as to what is left undone.
/rantoff Nonetheless, it would be nice to get it to work. Plenty of
people would like to have a performance boost in their applications, I
would think...
Perhaps UDT is not as bad as it looks... UDP data channel, TCP control
channel... At least UDT is a complete working and active project...
-Bruce
******************************
Neither the footer nor anything else in this E-mail is intended to or constitutes an <br>electronic signature and/or legally binding agreement in the absence of an <br>express statement or Autoliv policy and/or procedure to the contrary.<br>This E-mail and any attachments hereto are Autoliv property and may contain legally <br>privileged, confidential and/or proprietary information.<br>The recipient of this E-mail is prohibited from distributing, copying, forwarding or in any way <br>disseminating any material contained within this E-mail without prior written <br>permission from the author. If you receive this E-mail in error, please <br>immediately notify the author and delete this E-mail. Autoliv disclaims all <br>responsibility and liability for the consequences of any person who fails to <br>abide by the terms herein. <br>
******************************
More information about the gnhlug-discuss
mailing list