>        567752 packets received
>                ...
>                360819 packets (132490877 bytes) received in-sequence
>                ...
>                821 discarded for bad checksums

> That's not really a very high "bad checksum" rate.

The statistics I've got are:

        539053 packets received
                ...
                197666 packets (73182901 bytes) received in-sequence
                ...
                2662 discarded for bad checksums

which is proportionately higher.

Several people suggested turning of VJ header compression, which turns out
to have stopped the bad checksums.  Apparently there is a bug in the
handling of the TTL field which curdles 1 in 256 packets.  (It wasn't
made clear if this is a bug in the spec or the code, and I haven't had
a chance to ftp the RFC and check it out...)

The interesting thing is that while this stopped the behavior of transfers
from my ISP's ftp server pausing regularly (killing throughput), it turned
into a problem of the transfers pausing IRregularly (killing throughput).
I now wonder if the round-trip time calculation is going afoul on their
FTP server (I think there's an ethernet, a T3, and my PPP line between
me and their FTP server)...