RE: CVS slow and TCP Compression

[Scott Willy]

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

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.

csw





> -----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
> issue.
>
> Daniel
>
> ----- 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
> behavior
> > 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
> fast).
> > 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,
> the
> > checkout would slow to a craw. If we left it long it enough it would
> finish
> > 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.
> The
> > 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
> not
> > be part of our problem, but...
> >
> > We would be most interested if anybody else has seen something like this
> or
> > has any comments.
> >
> >
> > _______________________________________________
> > Info-cvs mailing list
> > address@hidden
> > http://mail.gnu.org/mailman/listinfo/info-cvs
> >
>
>
> _______________________________________________
> Info-cvs mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/info-cvs