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

[Johnny Billquist]

Per Hedeland skrev:
> Johnny Billquist <bqt@REDACTED> wrote:
>> No. RTT can not be used to calculate anything regarding traffic bandwidth.
>> You can keep sending packets until the window is exhausted, no matter what the 
>> RTT says. The RTT is only used to calculate when to do retransmissions if you 
>> haven't received an ACK.
> 
> Well, yes and no - RTT by itself cannot be used to calculate bandwidth,
> and TCP itself doesn't need to "know" the bandwidth anyway, but the
> possible throughput is dependant on RTT: Since you can have at most one
> window size of un-ack'ed data outstanding, and data can't be ack'ed
> until it's been received:-), the throughput is bounded by the ratio of
> (max) window size to RTT. With only 16 bits of window size available and
> an RTT of 300 ms, the theoretical max throughput is 65535/0.3 bytes/s or
> ~ 1.75 Mbit/s.

Yes. If you manage to fill the whole window, then the bandwidth starts to be 
reduced from the theoretical max of the media, and then RTT is related to how 
much your BW is reduced. And of course, your "ability" to fill the window is 
related to RTT as well.

> Of course this problem, a.k.a. "long fat pipe", was solved long ago as
> far as TCP is concerned - enter window scaling (RFC 1323), which allows
> for the 16 bit window size to have a unit of anything from 1 to
> (theoretically) 2^255 bytes. These days it should also actually work
> most everywhere. Nevertheless, the max window size is under the control
> of the TCP "user", and if the kernel and/or the application limits the
> size of the receive buffer to something less than 64kB, window scaling
> can't help.
> 
> 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. But unless the receiver is acting funny, it 
should only announce a new window size when there is substantial space available 
in the receive buffer, at which time the sender should send large packets, and 
not lots of small ones.

Oh well, someone needs to look into this a bit more obviously. I haven't even 
properly looked at the problem description. I just thought I'd point out some 
wrong assumptions on how TCP works. :-)

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt@REDACTED             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol