Linux-kernel mailing list archive 2000-23,: Re: Slow TCP connection between linux and wince

# Re: Slow TCP connection between linux and wince

Pavel Machek (pavel@suse.cz)
Mon, 5 Jun 2000 00:08:42 +0200

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Pavel Machek: "Re: RFC Maestro-3i"
- Next message: Pavel Machek: "Re: Slow TCP connection between linux and wince"
- Previous message: Pavel Machek: "Re: Slow TCP connection between linux and wince"

Hi!

> > CE machine downloads data from linux webserver. That webserver is
> > pretty much dedicated to my CE machine, therefore I'm willing to do
> > any hacks.
>
> First ``hack'' I would do is to check the microsoft servers if they have
> any documentation on CE TCP tuning (like increasing receive buffers and
> enabling delayed acks)

Even if there was a fix, it is inpractical. This machine has 15
minutes average lifetime: each 15 minutes linux is booted and that
means clean system.

I'm trying to make linux run on that CE. That means:

Hard reset (ram is cleared; it has no place for disk)

Configure networking using stylus

Download pbsdboot.exe (100K) + linux kernel (1.7M). Download of kernel
takes 10 minutes.

Boot linux; then; there's no other option than hard reset.

> > I've two computers (PC and philips velo 1) connected using null-modem
>
> What kind of device (PDA?) is this?

PDA.

> The small window is atleast a majority contributing reason. What kind
> a b0rken stack does it have? See IETF/PILC draft slow-links and advice
> for subnetwork designers for details.
>
> Anyway, solution is not to use TCP then - UDP based or raw serial
> transmission. If you must use TCP then you can make the sending
> TCP/IP stack not care about the window and experiment.

I'd have to write special downloader.exe and download it using TCP
first. Unfortunately, I'm not able to produce windows CE executable.

> > > 02:59:02.875029 192.168.55.100.1029 > 10.0.0.3.www: . ack 232141 win 3100 (DF)
> > > 02:59:02.875097 10.0.0.3.www > 192.168.55.100.1029: . 233601:235061(1460) ack 196 win 16060 (DF)
> > > 02:59:03.235031 192.168.55.100.1029 > 10.0.0.3.www: . ack 233601 win 3100 (DF)
> > > 02:59:03.235094 10.0.0.3.www > 192.168.55.100.1029: . 235061:236521(1460) ack 196 win 16060 (DF)
> > The WinCE machine does not seem to implement delayed acks. Without that
> > good performance is very hard.
>
> There's still a chance that the stack supports delayed acks because
> transmitting a segment of 1500 bytes over 115200 bps link takes about 130
> ms. Delayed ack timeout is 200 ms. As 2*130>200 the stack will never
> send delayed acks. Lowering MTU would help in this case.

Lowering MTU to 500 (or so) made performance slightly worse; I tried that.

> I think it supports this theory that the time between sending two segments
> is about 350 ms = 130+200+~20 ms.
>
> Pavel, have you by chance tested with <2.3.99-pre3? This is just a hunch
> but you could try this patch.

No, it was 2.4.0-test1.

> --- linux-2.4.0-test1-ac6.bak/net/ipv4/tcp.c Mon Apr 24 23:59:57 2000
> +++ linux-2.4.0-test1-ac6/net/ipv4/tcp.c Wed May 31 17:22:41 2000
> @@ -546,7 +546,7 @@
> struct socket *sock;
>
> read_lock(&sk->callback_lock);
> - if ((sock = sk->socket) != NULL && atomic_read(&sk->wmem_alloc) == 0) {
> + if ((sock = sk->socket) != NULL) {

I'll try this, thanx.

> > > > I've two computers (PC and philips velo 1) connected using null-modem
> > > > cable at 115200. Unfortunately, connection speed is ~2.7K/sec (where
> > > > 10K/sec should be possible). TCP dump looks like this:
>
> Check again line. This tcpdump shows nothing abnormal, you should
> see full line utilization.

> In fact this tcpdump proves that this line is not 115kbaud. 8)
> It is perfect to measure its real bandwidth. F.e. RTT is very
> good estimated as 0.9sec.

No, sorry, line is 115200. I configured both winCE and linux to give
115200; it is not possible to misconfigure them both 10x and not notice.

> > > The WinCE machine does not seem to implement delayed acks. Without that
> > > good performance is very hard.
>
> Failure to delaye acks do not affect throughput. Too long delay really can.
> It is possible in this case, by the way. RTT does not match to link speed
> even closely.
>
> Window is small, but 2 packet window is also enough to saturate
> this link.
>
> To resume: either receiver holds ACKs (probably, it is confused
> with its own small window), or something on link is wrong.
> Incredible regularity of the tcpdump forces to suspect that it
> is not 115kbaud really. 8)

Serial port on linux is configured to 115200. Is there any
misconfiguration able to make latency higher?
Pavel

    --
    I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
    Panos Katsaloulis describing me w.r.t. patents me at discuss@linmodems.org

    -
    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/

- Next message: Pavel Machek: "Re: RFC Maestro-3i"
- Next message: Pavel Machek: "Re: Slow TCP connection between linux and wince"
- Previous message: Pavel Machek: "Re: Slow TCP connection between linux and wince"