Date: Mon, 15 Feb 1999 12:15:05 -0800 From: Kent Stewart <kstewart@3-cities.com> To: Karl Pielorz <kpielorz@tdx.co.uk> Cc: Thomas van Gulick <melkor@Cal040031.student.utwente.nl>, freebsd-questions@FreeBSD.ORG Subject: Re: FreeBSD performance Message-ID: <36C88049.A423185A@3-cities.com> References: <19990215144708.A34665@utumno.student.utwente.nl> <36C83508.B7F45FC8@tdx.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
Karl Pielorz wrote: > > Thomas van Gulick wrote: > > > > I'm currently evaluating FreeBSD as a replacement of Linux as my primary > > development OS. I'm using a Dual PentiumPro system with 192 MB for this. > > I have a similar setup, Dual P-Pro 200 with 256Mb of RAM... > > > However, FreeBSD feels a bit 'sluggish' compared to Linux. A bit slower on > > every task so it seems. > > Hmmm... That's funny, the main reason I switched to FreeBSD was it performed > better / faster - especially under load - heavier the better :) > > > Are there any performance tweaks to increase my system's operating speed? > > I'm currently using the 4-CURRENT, async io and edited the kernel config > > file for as much speed as possible. > > If your running -Current try switching to softupdates rather than async IO - > The _only_ area I found Linux used to be quicker than FreeBSD was with > filesystem throughput, which is apparntly because they run their filesystem as > the equivalent of 'sync', I'd always been more than willing to pay the price > of 'async' vs. 'sync' on the damage recovery front... I don't have anything on FreeBSD but in the past I ran a number of throughput benchmarks on a Cray XM/P running UniCos (a 64-bit AT&T flavor of unix). For our mix of jobs, which included externally simulated user activity and program builds, the benchmarks established that that we could double throughput by caching the writes and allowing the system to write behind. The reads were much more important because a job was waiting for input and any significant delay could cause it to be swapped out. The swapping increased the load artificially since we were running in excess of 60% cpu utilization. The jobs running at the tail end of the benchmark were the ones most affected by delays. The HD system was a DD40, which was capable of 20MB/s continous to each set of stripped disks (4x9.6MB/s HD's operating in parallel). The I/O subsystem was accessed via either a 100MB/s or 1000MB/s data channels. The data channel used for the disk I/O was something only Cray knew. The writes, in all cases, were not important to the running jobs and could be delayed with no side effects. The vector processing capability of the system did not significantly help our mix of jobs. The argument of sync versus async on the writes only matter if you have a flaky system or are doing online database transactions. The delay for the writes are only a couple of seconds. That is why you used to "sync" disks at shutdown. The one funny example we had was when someone typed "sync;sync;sync<cr>" and turned power off. The system was in the middle of sync'ing when the power disappeared. It was explained to him that each sync was to have a <cr> and the commands were to be entered by hand. This provided sufficient delay to clear the buffers. The current set of shutdown scripts eliminate that timing problem. -- Kent Stewart Richland, WA To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?36C88049.A423185A>