[erlang-questions] why is gen_tcp:send slow?

[Johnny Billquist]

Per Hedeland wrote:
> Johnny Billquist <bqt@REDACTED> wrote:
>> Per Hedeland skrev:
>>> Whether this is Edwin's problem I don't know - the "fixed packet rate"
>>> observation may actually be more or less correct: As you explained, TCP
>>> doesn't ack packets, it acks bytes - but the actual *sending* of acks is
>>> definitely related to the reception of packets (or "segments" if you
>>> prefer), in particular in a one-way data transfer where there are no
>>> outgoing data packets that can have acks "piggy-backed". The details may
>>> vary, but in general in such a case an ack is sent for every other
>>> packet received, or after a ("long" - 200 ms) timeout if no packets are
>>> received.
>> Hmm. Well, a tcpdump will quickly tell if the window size is zero, and he's 
>> hitting the RTT-limiting factor.
> 
> Hmm hmm, I think I wasn't thinking straight when I wrote the above - I
> was speculating that this could be something other than the RTT-limiting
> factor (otherwise small vs big packets shouldn't make a difference in
> throughput), along the lines of "the receiver has data to ack but is
> delaying the sending of the ack until he recieves another segment".  But
> this can't be the explanation I believe - if you're sending smaller
> packets, you can send that many more into a given window before you need
> to wait for an ack, so there are more "opprtunities" for the reciever to
> send a delayed ack.

Yes.
However, one thing to also keep an eye out for is if a lot of small 
packets are generated, and the received can't accept packets at that 
pace. Then you'll experience lost packets, followed by retransmits. And 
this is definitely related to the RTT.
This is especially a problem if you have a transmitter sitting with an 
ethernet interface running at a higher speed than the receiver ethernet. 
Not totally unheard of if you have a switch in between...

But this situation will be very visible in the tcp counters on the system.

Do the erlang system turn off the nagle algorithm, or force TCP to push 
packets? Otherwise the underlying tcp layer should not be sending small 
packets at a high pace.

	Johnny