> -----Original Message----- > From: Todd Denniston [mailto:[EMAIL PROTECTED] > Sent: Tuesday, May 02, 2006 4:52 PM > To: Kelly F. Hickel > Cc: [email protected] > Subject: Re: problems building feature release on windows > > Mark D. Baushke wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Kelly F. Hickel <[EMAIL PROTECTED]> 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 _______________________________________________ Bug-cvs mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/bug-cvs
