lkml.org 
[lkml]   [1999]   [Jun]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: XTP: A better TCP than TCP
Date
> As I understand it, the idea behind not requiring flow-control in IL
> was that the higher level protocols would take care of this; in 9P
> (which is the main user of IL), there's a reply to each request, so if
> the server is replying slowly, the client will slow down to compensate.

NFS and CORBA don't have such a feature. And even if you *think* you
have such a feature, you may be surprised. In the example I gave (with
Legion and MPI), the server was simply being overrun with requests,
even though it replied to every one.

Likewise, IL attempts to do a good job at being adaptive over a
WAN. But it's hard to believe that it's as good at it as TCP.

> Yes, this requires the higher level protocol knows about doing
> flow-control stuff like nagle, but the idea is that the TCP layer doesn't
> _really_ know what the application requires and setting options such as
> TCP_NODELAY is a crude way of telling it.

Given an example where TCP_NODELAY does significantly worse than any
other method? I looked at this a little bit with MPI over TCP. The one
loss you're getting is that the MPI header is getting sent as a
separate packet from the MPI data, because they are separate write()
calls. I added code to make sure that the header and data went out
with a single write(), and there was no significant improvement. Other
than that, what's the lossage?

-- g

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.045 / U:0.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site