[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: CVS slow and TCP Compression
RE: CVS slow and TCP Compression
Mon, 2 Jul 2001 12:54:51 +0200
Thanks for everybody's replies.
Some more info...
1) Not sure its a duplex problem as FTP does not have this speed problem.
I just downloaded 8MB in 37 seconds. One would think a duplex problem
would affect all protocols.
[8647568 bytes sent in 37.5 secs (2.3e+02 Kbytes/sec)]
2) By slow, I mean 2MB takes 30 minutes with the -z option and 10 seconds
with the -z option.
3) We have the same behavior when we made a private LAN (i.e. a hub, the
cvs server and one client). There was no other traffic. Nothing else
4) By tons of collisions, I mean that the little blinky lite on the hub goes
from not blinking to full-on when I start a cvs checkout.
> -----Original Message-----
> From: address@hidden [mailto:address@hidden Behalf Of
> Daniel Beckham
> Sent: 01 July 2001 18:59
> To: Cvs (E-mail)
> Subject: Re: CVS slow and TCP Compression
> Someone else might be able to answer the question as to whether it has
> anything to do with cvs, but I would think it's a simple matter of network
> performance. It would make sense that using compression will
> speed up the
> checkout process, but what kind of speed problems are we talking
> about? Do
> you mean, a 2MB file take 30 minutes to download or 1 minute?
> And how much
> faster does a 2MB file checkout with compression on? What sort of network
> are you running? When you say tons of collisions, what do you mean?
> Collisions on an Ethernet segment is a normal thing. If I remember
> correctly, under 3% is ok, but more than that could indicate a network
> ----- Original Message -----
> From: "Scott Willy" <address@hidden>
> To: <address@hidden>
> Sent: Sunday, July 01, 2001 5:39 AM
> Subject: CVS slow and TCP Compression
> > We have installed cvs on a Cobalt Cube (Linux) and had some bizarre
> > which we would like to share.
> > We have been using cvs on a Solaris server for 18 months or so
> and decided
> > to get a Cube and dedicate it to cvs. After installing cvs on
> the cube we
> > did some tests and all seems to be working fine. We took
> repositories with
> > 1000's of files of source code and do checkouts no problem (and very
> > Then...
> > We did a test with repositories containing libraries of big (100KB-2MB)
> > jar/dll/exe files (and not C++ or java source code). After a few files,
> > checkout would slow to a craw. If we left it long it enough it would
> > the checkout, but it was too slow to be usable.
> > We found a workaround by using the -z option to set the TCP
> compression to
> > something other than zero. Anything between 1-9 seems to work just fine.
> > checkouts of the large files is fast.
> > Bizarre...
> > Another observacation we had, was that when doing a checkout we
> would get
> > tons of Ethernet collisions on the LAN. This was true for both
> the Solaris
> > server we have in production and the Cube we were testing. This was true
> > even if we only had cvs server and one client on the LAN.
> > We still had tons of collisions using our workaround (-z), so they might
> > be part of our problem, but...
> > We would be most interested if anybody else has seen something like this
> > has any comments.
> > _______________________________________________
> > Info-cvs mailing list
> > address@hidden
> > http://mail.gnu.org/mailman/listinfo/info-cvs
> Info-cvs mailing list