Guenter wrote:
> Hi Georg,
> Georg Lippitsch schrieb:
> >> 1) 2mbit umts connection (HUAWEI E270 modem)
>
> >> CURL_MAX_WRITE_SIZE 4096 -> 90k
> >
> > No, default CURL_MAX_WRITE is 16384.
> >
> >> CURL_MAX_WRITE_SIZE 40960 -> 200k
> I did google a bit, and the issue might perhaps be releated to the E270
> itself; I have found this sentence on their website:
> "the world's first High-Speed Uplink Packet Access (HSUPA) USB Modem,
> E270" ...
> http://www.huawei.com/mobileweb/en/news/view.do?id=400&cid=61&type=0
>
> probably the device does some packet compression, whatever, and with
> smaler upload chunks the overhead is bigger?

Note that it shows the same effect with encrypted data, which is
incompressible. There may be some header overhead though, especially
if it groups IP packets into larger HSUPA packets.

> Perhaps the modem has an upload transfer buffer of 65535, and that's
> the optimum for this device?

This is TCP/IP over HSUPA. The writes should be broken into TCP
packets before being sent to the modem, which provided curl is writing
fast enough, are likely to be about 1500 bytes in size, for any value
of CURL_MAX_WRITE_SIZE. The operating system should keep enough
packets in flight to match the TCP window size.

What does "ifconfig" show for the link MTU?

A trace from Tcpdump or Wireshark with detailed timestamps may reveal
a certain burstiness - in the transmission as the TCP window is
probably smaller than the bandwidth-delay product for this link. But
I don't see how that would be affected by increasing
CURL_MAX_WRITE_SIZE.

-- Jamie
Received on 2009-08-20