RE: CVS slow and TCP Compression

[Steven Rosenstein]

This is just a shot in the dark (I am fairly new to CVS).

I believe you mentioned in an earlier email that you are moving a large number
of binary files.  Is it possible that CVS is somehow examining the contents of
these files (say, to determine end of line?).  In a binary file this would be a
very time-consuming task, and might generate a significant amount of traffic
between the client and the server.  When you turn on compression, regardless of
the level of compression, CVS "knows" that you are moving a binary file, and
turns off all file internal checks?

If this is the case, I believe you can use the -kb commandline modifier to tell
CVS the file you are committing is binary.

I hope this helps

--- Steve




"Scott Willy" <address@hidden> on 07/03/2001 06:31:12 AM

To:   address@hidden
cc:    (bcc: Steven Rosenstein/FTCI)
Subject:  RE: CVS slow and  TCP Compression




We have re-done the FTP tests. Uploads and downloads work fine. Both to/from
the PC (the cvs client) and to/from the cobalt cube (cvs server). The speed
was fine over 100KBytes/sec. Still could be a duplex problem, but the
evidence is not clear.

We are still trying to figure out how to configure the cube's Ethernet
driver to force it into half-duplex mode (it is easy to do so on the PC).

Any case, we can leave it here. I think the most important thing to note is
that by changing the TCP compression level (e.g. -z3 )some network problems
might be solved (or at least worked around).

csw