Parallel sockets or?

[bruce.labitt at autoliv.com]

> 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>
******************************