Wes Peters wrote:
>
> Julian Elischer wrote:
> >
> > ok here are some of the problems..
> >
> > Matt's changes allow dd to copy data at 2.5 times the rate it did before.
> > I consider dd to be an application. The problem is due to resource
> > handling in the kernel and results in large amounts of Idle CPU time.
> >
> > Another primary problem with the FreeBSD kernel (being addressed by Kirk)
> > is that after writing a file, once the data has been queued for IO you
> > cannot read the data in that file (even though it is present) until the IO
> > is complete. With 64 tags, it is concievable that this could take a half
> > second on a modern disk.
> >
> > These are problems shown up by the benchmarks but
> > which can be shown to affect ordinary operations.
> >
> > There are other problems related to SMP and the GKL..
> > e.g.. two processes cannot access buffers at the same time, even though
> > they are both present , because only one of them is allowed in the kernel
> > at a time. Therefore One processor will spend a bunch of time at idle..
>
> I think it's been pretty well known since the beginning that FreeBSD
> SMP performance is nothing to cheer about. How does FreeBSD fare
> against NT or other systems on single processor systems?
Sorry to follow up on my own message, but I noted today in PCWeek
their trip back to the benchmark lab includes ripping 3 CPUs and
768M RAM out of the system, to benchmark how Linux and NT perform
on "lower-end" hardware. They also allowed the RedHat dudes to
switch to an Adaptec SCSI controller to talk to the RAID array.
How are we holding up under this "diminished" configuration?
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters Softweyr LLC
http://www.softweyr.com/~softweyr w...@softweyr.com
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
