Slow VC++ builds from Linux fileserver

David Collier-Brown davecb at Canada.Sun.COM
Wed Sep 9 11:59:41 GMT 1998

You wrote:
To give some concrete figures, building a AppWizard generated project
under NT4 takes 33 seconds when the project files sit on the UltraSparc
and 165 seconds when they sit on Linux. When built under W95 (on a
slower machine - NT4 is 200 MHz PII w/ 128Mb, W95 is a 90MHz Pentium
with 64Mb), the build takes 54 secs when the project files sit on Linux
or UltraSparc (and 64 seconds when the files are hosted on a NT server,
for what it's worth). Yep, a P90/W95 outperforms 200PII/NT4 by a factor
of >2.

As a table:
	Server		Client		Time
	------		------		----
	UltraSparc 	NT4		33
	Linux		NT4		165
	NT4		NT4		-
	UltraSparc 	win95		54
	Linux		win95		54
	NT4		win95		64

Hmmn: I'd break this down into several separable questions:
Let's assume that a compile requires opening and reading lots
of .c .h and a few .o files....

Server side:
	There's caching and throughput issues possible:
	caching allows faster opening of directories to get
	.h files, throughput just give throughput (:-))

	If and only if the win95/ultra build really is 
	indistinguishable from the win95/linux, then the
	machines are producing equivalent performance,
	probably in both areas (theoretically one could have
	high caching and low throughput, the other the opposite:
	I'm ignoring that case)

Client side:
	There is a terrific difference that the above logic 
	suggests is client-specific.

	The right way to diagnose it is to take packet dumps
	with timestamps and grovel over the request-reply pairs
	looking for a feature (;-))

	The bogus way is to guess: I will now guess (:-))

	It sounds like NT is issuing a sequence of SMBs that
	win95 isn't, and some of them are ``slow''.  The extra
	performance of the Ultra pays off here, for reasons I
	haven't got a clue about.

	I'd try turning things off.  First, turn off oplocks.
	Your performance may then be horrible.!!!  Then try
	fake oplocks.  Then try locking=  no. Then share 
	modes on/off.	
	This is in hopes of finding something the NT does
	wrong that's an option.  And it may.
	Beware! Multiple users working on the same project WILL
	mess things up with locking mechanisms turned off. Use
	RCS during any beta-testing!

	And, whether you succeed or fail, send us mail.
	If you do take packet dumps, send the samba team
	an ftp location or url.

David Collier-Brown,  | Cherish your enemies.  They're harder to
185 Ellerslie Ave.,   | come by than friends and more motivated.
Willowdale, Ontario   | davecb at,
N2M 1Y3. 416-223-8968 |

More information about the samba mailing list