[cvsnt] Excessive delays with files > ~800KB

[Arthur Barrett]

John,

Thanks for the info.

If you are sending large messages or attachments - send them (or at least cc them) to support at march-hare.com, since most people on the newsgroup dont want large attachments the newsgroup server automatically quarantines them.

> Okay, here's an extreme example, a nearly-5MB MSSQL 
> ETL package (an XML text file):

first line:
> 13:45:03:   -> Tracelevel set to 3.  PID is 12888

last line:
> 13:45:03:   -> GetUnixFileModeNtEA(C,000006E0) returns 0000

zero time to execute?

> The results from a "cvs -ttt diff" on a slightly 
> smaller (1.6MB) XML file:

> {snip}
> 13:33:17:   -> wnt_stat(Transaction.dtsx)
snip
> 13:33:17:   -> GetUnixFileModeNtEA(T,00000074) returns 0000
> 14:04:52:   -> close_directory()
> {snip}

OK - that's better, except that you do not have server side tracing enabled.  In this case all we can see is the client steps which show no delays (I think).  I've no idea how you enable server side tracing on CVS 1.11.2.

>>> Server: Linux, CVS 1.11.2
>> 
>> This version is very old,
>
> Granted. The CVS server has been in use and stable for a long time.

Still in the Ximbioy FAQ for CVS 1.11.2 under "end of file" errors it says:
 
> There are a few rare combinations of CVS clients and servers 
> which can cause this problem when the server is otherwise 
> set up correctly. If you verify that your transport is set 
> up correctly and you are still encountering this problem, 
> try making sure you are running the most recent versions of 
> the CVS client and server.

http://ximbiot.com/cvs/wiki/index.php?title=CVS_FAQ#cvs_.5Blogin_aborted.5D:_end_of_file_from_server_.28consult_above_messages_if_any.29

>> I'd recommend upgrading to CVSNT for Linux 2.5.03. 
>
> I'm not going to jump at that as the first troubleshooting step...

Well I wasn't really meaning for you to do it straight away, but it also wouldn't hurt.  Also this is the CVSNT newsgroup, if there is a suspicion that the problem doesn't occur with CVSNT server then the majority of people will not be too concerned, which reduces your chance of getting the volunteers to help.  Professional support is different of course.

> Attempting the same operations several times on a Linux 
> box took 11sec to do a stat, an update, and a server-side diff, 
> and ~25sec to do a local diff; on

Yes but this is either a local socket or direct to disk connection (depending on the CVSROOT used) and is not really the same.  It's also the identical server and client version.

> a different WinXP box running WinCVS and Cygwin CVS 
> took ~11 sec for a server-side diff and ~35sec 
> (slower box) for a local diff. The same
> operations take many minutes using the cvsNT client 
> on multiple different WinXP desktops in our office.

This is definitely sounding like a server/client version incompatibility.  Which version of Cygwin CVS did you use?

It may be possible to resolve this in the CVSNT client, but we'll need better diagnostics to "see" what's going on.  The -ttt trace from cygwin wont show the date/time, but may be interesting for a comparison.  We also need to consider the implication of any "fix" on other client/server versions - 1.11.2 is very old and if it is only that version affected then the impact analysis may lean in favour of not making such a change.

Also it's worth re-iterating all the basic diagnostics:
* ensure that virus scanning is not enabled on the client PC "workspace"
* ensure that you are checking out to a local disk - not a network share

These are both common causes of slow client behaviour.

> I don't think the server is the problem, at least 
> not as a primary contributor.

It's still to early to tell.

> Is it possible that cvsNT is ignoring an unexpected
> end-of-file error while talking to the server in some 
> situations? 

Windows sockets will just keep listening till something comes down.

Regards,



Arthur Barrett