bug-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: problems building feature release on windows


From: Kelly F. Hickel
Subject: RE: problems building feature release on windows
Date: Tue, 2 May 2006 18:35:16 -0500


> -----Original Message-----
> From: Todd Denniston [mailto:address@hidden
> Sent: Tuesday, May 02, 2006 4:52 PM
> To: Kelly F. Hickel
> Cc: address@hidden
> Subject: Re: problems building feature release on windows
> 
> Mark D. Baushke wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Kelly F. Hickel <address@hidden> writes:
> >
> >
> >>>-----Original Message-----
> >>>On Behalf Of Mark D. Baushke
> >>>
> >>
> >>
> <snip>
> >
> >>One very odd thing that I have no explanation
> >>for is that I moved from a 4 way 700mhz PIII to
> >>a 2 way 2.4 mhz PIV and it takes roughly the
> >>same amount of time. The only inkling of an
> >>explanation is that I was running cvspserver
> >>1.11.x on the PIII and am running 1.12.13 on the
> >>PIV. The cvs process is definitely CPU bound
> >>during this operation (according to top and
> >>xosview).
> >
> >
> > It will be reading the existing files and copying
> > them in to temporary ,filename, files and adding
> > the new tag along the way. I would have thought
> > that operation would be more IO bound than CPU
> > bound, but I have not looked at it closely in a
> > long time.
> >
> 
> With the trouble you are having getting it compiled on windows, it
would
> probably be better to do some empirical testing first to be sure of
what
> you
> are looking for.

 [Kelly F. Hickel] I did those speed tests on linux boxen that weren't
doing anything but serving CVS. Both the PIII (4 way)and the PIV (2 way)
are multiprocessor boxes (not HT, multiprocessor), and the clock rate on
the PIV is 3x that of the PIII.  That's what lead me to want to Quantify
in the first place.

> 
> Like Mark I would expect the bottle neck to be the file IO more so
than
> the
> CPU.  I suspect that if the server machine is only serving CVS, that
if
> you
> brought the PIII up in uniprocessor mode it would still almost[1] keep
up
> with
> the PIV because cvs server is a single threaded process.
> 
> 
> A useful test to see if it is file IO vs CPU bound would be to put
your
> repository, temp dir and LockDir in a RAM disk (loop device) to remove
the
> hard drive rewriting. If it was CPU bound you would get the same
timing I
> THINK.

 [Kelly F. Hickel] I also expected it to be IO bound, which is why we
have several fast drives in a RAID 5 array. I have tried moving temp and
lock to ramdrives (independently and together).  All tests as well as
measurements indicate that it is CPU bound.

> 
> You might also try with and without the -z option to cvs, I don't know
the
> protocol well enough to be sure, but a tag operation I think sends
each
> file
> name individually to the server, it would be unlikely but perhaps you
have
> enough message traffic during a tag to swamp your net (really
unlikely).
> (might never mind this, I reread part of your email and local access
and
> pserver are taking the same amount of time.)

 [Kelly F. Hickel] I have the -z option turned off and have gigabit nics
and full gigabit switches between client and server. (and of course, as
you said, local is the same).

> 
> 
> [1] I believe, If it could be brought up in dual processor it would
> probably
> be the same timing you see now, because one processor would be
handling
> CVS
> and the other the file and net IO.
> 
> --
> Todd Denniston
> Crane Division, Naval Surface Warfare Center (NSWC Crane)
> Harnessing the Power of Technology for the Warfighter

-Kelly




reply via email to

[Prev in Thread] Current Thread [Next in Thread]