[Top][All Lists]

[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:Todd.Denniston@ssa.crane.navy.mil]
> Sent: Tuesday, May 02, 2006 4:52 PM
> To: Kelly F. Hickel
> Cc: bug-cvs@nongnu.org
> Subject: Re: problems building feature release on windows
> Mark D. Baushke wrote:
> > Hash: SHA1
> >
> > Kelly F. Hickel <kfh@mqsoftware.com> 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
> probably be better to do some empirical testing first to be sure of
> 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
> the
> CPU.  I suspect that if the server machine is only serving CVS, that
> you
> brought the PIII up in uniprocessor mode it would still almost[1] keep
> 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
> repository, temp dir and LockDir in a RAM disk (loop device) to remove
> hard drive rewriting. If it was CPU bound you would get the same
timing I

 [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
> protocol well enough to be sure, but a tag operation I think sends
> file
> name individually to the server, it would be unlikely but perhaps you
> enough message traffic during a tag to swamp your net (really
> (might never mind this, I reread part of your email and local access
> 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
> 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


reply via email to

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