Messages in this thread | | | From | Greg Lindahl <> | Subject | Re: XTP: A better TCP than TCP | Date | Thu, 3 Jun 1999 16:37:03 -0400 (EDT) |
| |
> 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/
| |