More problems with egcs.cygnus.com

[Mike Stump]

> Date: Mon, 6 Mar 00 22:03:09 EST
> From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
> To: gcc@gcc.gnu.org

> I have a "cvs update" running and it's been getting nowhere for many
> minutes.  It's almost impossible for me to do any work once it's
> after 1-2 PM or so.  Is there any hope of getting this problem
> fixed?

> Right now, it looks like a problem between bbnplanet and Cygnus:

> 18  f1-0.paloalto-cr20.bbnplanet.net (131.119.4.2)  91 ms  90 ms  92 ms
> 19  s0.cygnus3.bbnplanet.net (4.1.120.86)  289 ms  340 ms  316 ms
> 20  * sourceware.cygnus.com (205.180.83.71)  314 ms  331 ms

I checked, and there is a nominal 10 kB/s throughput to gcc.gnu.org
per TCP session.  :-( There are 37 ftps going, and 5 cvswebs, and 15
httpd and 2 cvses (if I counted everything correctly) and one active
incoming spider from lycos.  Around 46 active data pumpers.

I could probably ask Paul if he would host the gcc machine on his
OC-12, if we wanted to.  He might be willing.  That would cure the
bandwidth issue I think.  The connectivity quality would be excellent
(think what it takes to host 80% of the world's dns traffic for all
the root servers).  :-)

Physically, it would be in Redwood City.  I know, not exactly ideal,
but I thought I would offer.

Another (much cheaper) way of fixing the problem would be to rewrite
the web pages to point at ftp.cdrom.com's mirror, and burry the main
ftp machine down in the noise someplace.  That way, new users looking
for some files would go to an external machine first.  I was seeing
ftp's from .it, .uk, .za, .pt, .tw, .nz, .fr, .ru, .jp, .kr, just to
name a few.  I can't believe CA, USA is the closest mirror, conclusion
people don't bother with the mirror list because it is too hard for
them to figure it out.  I'd say, let's try a web page update to see if
that cures the problem.

>From there, I think if someone would research how to make a linux box
running 2.2.5 give priority to cvs traffic over ftp traffic, that
might fix things for developers.  An 80 to 1 preference I think should
fix the problem.

Another solution, dump the incomming ftp connection limit down some
more.