Very Computer

I'm using a PPP connection to the external world and I'm having problems
with TPC throughput, for example an ftp download.

The symptoms are the following.  I monitor both the modem lights and the
hash mark progress.

Initially everything goes fine -- the receive light is on constantly and
the hash advances about 4K/sec, which is what the 56K modem gives.

At some point the hash marks stop advancing, and shortly after the receive
light stops.  At this point I can check with ifconfig that there has been
one packet error on the interface.  

After a while there is some sporadic activity on the lights, a whole slew
of hash marks appears at once, and the transmission resumes normally.

This process is repeated at regular intervals, so the effective throughput
is much less than the peak -- about 2.6 K/s.

What I believe is happening is that the dropped packet is not ACK-ed at
the TCP level, and the remote host stop sending further packets until this
one is retransmitted.

What is the relevant parameter to tweak, so that the error is encountered
and the packet -- retransmitted _before_ the other packets stop flowing?

Also, what could cause the fairly regular dropping of the packets?

--

I have exactly the same problem. If you start ppp with kernel debugging
messages turned on, you will probably see a frame checksum error each time
the connection pauses. The only thing I was able to find about it was the
guess that a modem doesn't work properly. But the same connection works fine
with W95!

No one in comp.protocols.ppp or comp.dcom.modems had an answer to my question
so far. So if you finally can come up with something to prevent these *
stalls, I would REALLY appreciate it if you could let me know.

Regards,

Martin

--

Quote:> No one in comp.protocols.ppp or comp.dcom.modems had an answer to my question
> so far.

OK, we dropped the packet and we have to retransmit it.  But this should
only add an extra packet, not stop the flow for two seconds.

My guess is that the timeout for retransmit is set too high, and the number
of un-ACK-ed packets to low.  I have a suspicion that there is a parameter
for this to be tweaked, but which?

Quote:> So if you finally can come up with something to prevent these *
> stalls, I would REALLY appreciate it if you could let me know.

--