Brian Utterback wrote:
> That doesn't make sense to me. Nagle is necessary because of the
> high level of overhead of sending packets over the network. And it
> never prevents data from flowing, it only slows the flow down.
A couple points. Nagle algorithm is *not* necessary. It
is an optimization. The overhead in loopback TCP connection
is the system call and context switch.
> If the application writes the data with small buffers, the amount
> of resources used per unit will be the same with or without the
> block. The same number of data blocks will be used, and the same
> number of context switches.
I think you misunderstood the following *IF* part in my previous
email.
---
*IF* the sender is clever and does its own buffering so
that when it is unblocked, it can send a huge chunk of
data, it will be a win.
---
It will be one single big write after the unblock *IF* the app
is clever and does its own buffering. And this is indeed what
some apps do to handle write blocking. It is a win. The
optimization is not about storage space. Hope this clarifies
the dynamics.
> In fact, the block might actually
> increase the number of syscall used by the reader.
Could you explain your reasoning above? It does not seem to
be true universally. In fact, the app mentioned above wins
because the number of syscall done by the reader is also
reduced, exactly the opposite what the above point.
> The only
> thing saved is the high water mark of simultaneous data blocks
> used might be lower.
I believe this is never the intention of the current code.
And this is not what makes some apps perform better.
> Nagle tries to reduce the number of packets
> used by allowing the application to write more data before sending
> the packet. That doesn't work in this case.
Why? Actual data shows that some apps indeed perform better.
Could you explain your reasoning why the performance data does
not correctly represent the dynamics of the code flow and
the reason why the improvement is not real?
> It seems backwards to me because:
>
> 1. The purpose of fused connections was to reduce the TCP baggage,
> not introduce more.
Could you clarify what you implied by introducing more TCP
baggage? I think the current code removes all TCP protocol
data processing in the loopback case, not introduces more.
> 2. As far as I know, no other IPC method imposes this kind of flow
> control. Why single out TCP?
Maybe there is another misunderstanding. TCP is not being
singled out. There are some apps which need to talk to both
local and remote peers. To simplify the code, the app writer
chooses to use TCP socket to communicate with all of them.
If an app only needs to do IPC, I believe TCP is probably
not the right choice in many circumstances. And because the
app needs to communicate with remote peers, it also has
mechanism to handle write blocking. The current code optimization
is based on this fact.
Again, the question to answer is how to make it work better.
But if you really think that the above observation on the
dynamics of data flow is incorrect, please state the reasoning.
--
K. Poon.
[EMAIL PROTECTED]
_______________________________________________
networking-discuss mailing list
[email protected]
