-----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 [EMAIL PROTECTED] < /dev/null > PGP public key available at http://lynx.dac.neu.edu/home/httpd/n/nmeyerha/mail.html or by 'finger -l [EMAIL PROTECTED]' -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBN8WvvodCcpBjGWoFAQHGkwP/R6bWdSax7yqDb552YmguvBpmJOs4ETgn QleYGfSdZ9xw6u5KuZKXhVPvRwWEmhoF4UdlekX+nnZTsFn0cNe3jH02z+1T4LDy eKZfLqgugqh603bg+vH9h9kDV+LHyE1iB/hh2/KUcZCe/tnNdZno5W94UCkhfkzR fvhFoKsEmzI= =VR0S -----END PGP SIGNATURE-----
