Re: PPP speeds; "nice"-ness
On Thu, Aug 26, 1999 at 05:20:57PM -0400, Noah L. Meyerhans wrote
> -----BEGIN PGP SIGNED MESSAGE-----
>
> If you were to run two simultaneous downloads of any significant size,
> you'd notice that over time they'd balance out and use up about the same
> bandwidth. You're seeing long fetchmail times because it has to open a
> connection to the mail server and negotiate the transfer of the mail
> files. It has to establish the initial connection, send the first POP
> command, then wait for the response to finally work its way down the
> saturated PPP link, then send another command, wait a long time, etc.
>
> So there is no concept of 'nice'ness in PPP, and therefore no way to speed
> up fetchmail. In the 2.2 kernels, there is a network traffic-shaping
> option, but that only works for outbound transfers, IIRC. And if you
> think about it, that's the only way it can work, really, since the rate at
> which you receive data depends on the rate at which the other host sends
> it; There's no way to tell the other machine that you want it to slow down
> the rate at which it sends data...
>
Actually, there is (or rather, would be if anyone implemented it). You
could control the long-term transfer rate by having the TCP stack delay
packet ackonwledgement; the stack at each end will only allow a certain
amount of unacknowledged data to be "in-flight" at a time (the window size),
and so you can delay fresh packets from the other end by delaying the
acknowledgement of received packets, thus keeping the window full until you
are ready for more data (so long as you don't wait long enough to produce
timeouts). This would result in somewhat bursty transmission, rather than
the smooth degradation that Alan probably has in mind.
John P.
--
huiac@camtech.net.au
john@huiac.apana.org.au
"Oh - I - you know - my job is to fear everything." - Bill Gates in Denmark
Reply to: