That's odd

[ewx]

IP 172.31.59.129.42194 > 172.31.59.130.22: 1107577 bytes 358739 bytes/sec (2802 kbit/sec)
IP 172.31.59.130.22 > 172.31.59.129.42193: 1057597 bytes 67920 bytes/sec (530 kbit/sec)

...or put another way, transfering the same file across the same wireless network is about 5 times as fast if going to my laptop as coming from it. (The link is nominally 54Mbit/s.)

Comments

[sweh.livejournal.com]

Transmission power? If the laptop is weak in transmitting then it might require many retransmissions per packet; the ACKs when copying to the laptop are small enough that the slow down is less.

[ewx.livejournal.com]

Hmm. Not impossible; I don't have a feel for what a plausible proportion of retransmitted packets is in the absence of problems (see below).

In any case, it's made me get around to running another cable upstairs.

kakajou$ netstat -sptcp
tcp:
        13397499 packets sent
                8207354 data packets (3523716771 bytes)
                45780 data packets (65846398 bytes) retransmitted
                0 resends initiated by MTU discovery
                4928625 ack-only packets (119572 delayed)
                0 URG only packets
                2 window probe packets
                160358 window update packets
                55384 control packets
        10805216 packets received
                6566509 acks (for 3523503748 bytes)
                101396 duplicate acks
                0 acks for unsent data
                5737152 packets (1674841297 bytes) received in-sequence
                2031 completely duplicate packets (351511 bytes)
                2 old duplicate packets
                24 packets with some dup. data (22683 bytes duped)
                15916 out-of-order packets (17923068 bytes)
                1 packet (1 byte) of data after window
                1 window probe
                2942 window update packets
                436 packets received after close
                0 discarded for bad checksums
                0 discarded for bad header offset fields
                0 discarded because packet too short
        24468 connection requests
        6893 connection accepts
        0 bad connection attempts
        0 listen queue overflows
        31328 connections established (including accepts)
        47956 connections closed (including 387 drops)
                3709 connections updated cached RTT on close
                3709 connections updated cached RTT variance on close
                267 connections updated cached ssthresh on close
        22 embryonic connections dropped
        6566505 segments updated rtt (of 4981940 attempts)
        33420 retransmit timeouts
                14 connections dropped by rexmit timeout
        9 persist timeouts
                0 connections dropped by persist timeout
        456 keepalive timeouts
                1 keepalive probe sent
                15 connections dropped by keepalive
        4072424 correct ACK header predictions
        4079355 correct data packet header predictions

[ewx.livejournal.com]

though I do notice that 0.6% of packets are retransmitted while 1.9% of bytes are retransmitted, implying a bias towards larger packets among those requiring retranmission, which would be consistent with your theory.

[fanf]

Isn't there a WIFI mode in which more transmission slots are reserved for the base station, on the assumption that most traffic will be flowing to the various clients on the network?

[ewx.livejournal.com]

I'll see if I can remember the base station's password and dig around in its configuration.

[mikewd]

You may be getting retransmits by the MAC on the card itself at the 802.11 level which won't show up in the IP stats. (iwconfig or /proc/net/wireless or whatever it is in modern Linuxen should show these sort of stats. and the base station should show a similar thing from its end).

You could also try experimenting with the RTS/CTS options as in theory turning off RTS may increase throughput (but only if you don't have other stations active that your laptop card can't hear directly).