[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: PPP speeds; "nice"-ness



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

noah

On Fri, 27 Aug 1999, Alan Eugene Davis wrote:

> 
> Whenever apt-get is scarfing files by ftp, it seems to take much of
> the "bandwidth" of my 33.6 modem.  Fetchmail is often running very
> slowly, while apt may run at 2K or even 3K, according to it's own
> reports.  
> 
> This prompts me to ask, is there a concept of "nice"ness for TCP/IP
> connections?  How does apt arrange to have a priority, as apparently
> it does, and arrange to have good speeds when other processes don't?  
> 
> Is this all the rumblings of my imagination?
> 
> Alan 
> 
> 
> -- 
> Unsubscribe?  mail -s unsubscribe debian-user-request@lists.debian.org < /dev/null
> 


  PGP public key available at
  http://lynx.dac.neu.edu/home/httpd/n/nmeyerha/mail.html
  or by 'finger -l frodo@ccs.neu.edu'



-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBN8WvvodCcpBjGWoFAQHGkwP/R6bWdSax7yqDb552YmguvBpmJOs4ETgn
QleYGfSdZ9xw6u5KuZKXhVPvRwWEmhoF4UdlekX+nnZTsFn0cNe3jH02z+1T4LDy
eKZfLqgugqh603bg+vH9h9kDV+LHyE1iB/hh2/KUcZCe/tnNdZno5W94UCkhfkzR
fvhFoKsEmzI=
=VR0S
-----END PGP SIGNATURE-----


Reply to: