Re:

[Super Biscuit <super_bisquit%yahoo.com@localhost>]

I use response times and memory usage.

The gui may take up memory and cpu, so running it in terminal mode gives
better results.

I've run FreeBSD 9.0 on a G3 with 386M and 450MHz CPU. The same on a G4.
All BSDs on amd64 and i386. Curently runnin OpenBSD- still installing- on a
Sun Blade 1000 and will put FreeBSD on it.

ON i386, I also look at the performance of 3d rendering while other
applications are running. Running qemu under a full load with the host also
running.
Desktop performance and build times. The G3 would slow down but not stop while
running multiple builds.
Also on older hardware, I've gotten all three major BSDs on a small disk-
11.5G, 256M, 1.5GHz- and the response time has been better.
Wireless runs direct without wifi radar. If you run Linux, then you know how
cpu and memory costly this can be.
I still use Debian and Fedora but my main preference is for BSD.



--- On Sat, 11/27/10, andre.dolenc%kolumbus.fi@localhost 
<andre.dolenc%kolumbus.fi@localhost>
wrote:

From: andre.dolenc%kolumbus.fi@localhost <andre.dolenc%kolumbus.fi@localhost>
Subject: Re:
To: "Super Biscuit" <super_bisquit%yahoo.com@localhost>
Date: Saturday, November 27, 2010, 9:25 AM

Hi,

How do you measure the performance difference? Under what kind of load?
Or do you simply notice it by the response times?
What kind of HW?
The reason to ask is that I could use this kind of information to replicate
your experience.

Thank you.

br Andre


Super Biscuit [super_bisquit%yahoo.com@localhost] wrote:
> I think that on some architectures there needs to be a more direct way of
> loading without having to boot into the firmware. Right now, it's ppc32 and
> soon sparc64. The former should have an  hfs bootloader you can dd to hard
> disk. Two disks on a G4 and Net still needs me to change the default boot
> device and type in the boot command.
> I agree that BSD systems are cleaner and the performance on embedded
devices
> should be argument enough; however, popular opinion and business has
different
> ideas. Performance o my home machines is anywhere from 200 to 400% better
with
> any BSD than Linux.
> The chewiefs looks like a good idea. I'm more of a Free, Open, Net BSD user
in
> that order.
> --- On Thu, 11/25/10, andre.dolenc%kolumbus.fi@localhost 
> <andre.dolenc%kolumbus.fi@localhost>
> wrote:
>
> From: andre.dolenc%kolumbus.fi@localhost <andre.dolenc%kolumbus.fi@localhost>
> Subject:
> To: netbsd-users%netbsd.org@localhost
> Date: Thursday, November 25, 2010, 10:21 AM
>
> Hello,
>
> (Let me try posting again...)
>
> + Automated *performance* testing incl. kernel RAM usage, real-time and SMP
> characteristics on given HW (e.g. latencies). Such testing will allow
anyone
> to check if, say, a new version of nbsd or a proposed change to nbsd
improves
> performance on own HW.
> By way of example, take a look at http://www.inf.u-szeged.hu/csibe/ and
> http://webkit.sed.hu/benchmark While the GCC test environment is open, and
can
> be downloaded by anyone, the webkit test environment cannot, unfortunately.
>
> The work on-going in nbsd in developing ATS and related test cases is
> absolutely -great-! Keep it up!
>
> + Anything that helps when porting nbsd to new HW, like kernel
> instrumentation, tracing, and debugging.
>
> + Anything UI and graphics related (e.g., how do integrate the UI generated
by
> 3D graphics and overlay on video output. Think of a camera UI for mobile:
the
> UI is transparent and overlayed on the viewfinder which is, essentially, a
> video stream before the picture is taken); Wayland kind of window system,
> etc.
> Even if wayland idea is good for mobile, I am not sure the design and
> implementation is the best possible.
>
> + BSD licensed flash file system. The folks at Szeged are slowing getting
> there. As an introduction, these are the same folks that developed the
current
> flash file system in Linux, and before that they improved JFFS2.
> http://chewiefs.sed.hu/
>
> + Performance improvements are always welcome, esp. related to code size,
> configurability, (soft) real-time, SMP, and so forth. Things like a high
> resolution user space timer come handy when doing some (mobile) audio stuff
in
> userland. Not to mention it comes handy when testing performance, like RT
> characteristics on given HW.
>
> + Memory management can always get better. For instance:
> - in some devices, it is possible to maintain a list of processes that can
be
> killed. This comes handy when the kernel runs out of memory. So, having a
way
> to provide the kernel with such a list is really good.
> - Garbagge Collection and paging defeat each other. There is an article in
the
> ACM "Garbage collection without Paging" (main author is Mathew Hertz)
showing
> one way the VM can cooperate with programming languages that rely on GC
(e.g.,
> Java, Lua, Javascript, etc). Of course, such issues go unnoticed on servers
or
> desktops. It is possible that the changes done for Linux to support Android
> include such improvements.
>
> + Instant-on. The work done to reduce Chrome OS boot time makes a lot of
> sense, IMHO. Of course, many need to have more control over the boot
process,
> but end users don't care. Also, instant-on after sleep is great.
>
> + XiP support. New memory technologies could make nbsd extremely attractive
if
> and when it supports this.
>
> + Power management. Not much missing except when ACPI is not an option. A
> clock framework is very handy when ACPI is not used.
>
> In general, nbsd is a great kernel. Below, a few comments about the
original
> email:
>
>     + please drop CVS,RCS,SVN . ...
> We used git in our past projects, and we had no problems scripting our way
> back and forth.
>
>     + Support for more Filesystems. Whats going on in LINUX is crazy but ..
> It is possible to use Linux filesystems on rumps, but that work never
reached
> completion. Unfortunately. Incidently, the feasibility study was done using
> JFFS2.
>
>     + NetBSD LIVE CD/USB with each release ...
>     + integrating a small X-Window into the System. Something like Project
> "Wayland" from Canonical that has a minimalistic mem footprint expandable
by
> userland modules.
> IMHO, take and improve the wayland ideas, and make it possible for others
to
> use X. But don't let X compatibility get in the way of a good solution. Let
X
> folks deal with the problem, if one arises.
>
>     + NUMA support and a true scheduler fÃr each MultiCore CPU
>     + More focus on Mobile Devices - NetBSD is in my opinion a better
System
> on mobiles than LINUX/Android. Tethering drivers (to iPhone and Android)
would
> be nice.
>
> I definitely support the focus. I also agree on your opinion (at least in
the
> Android context) even though its unlikely we would agree on the reasons.
> "Better" is in the eyes of the beholder.
>
> Thank you for your time.
>
> Disclaimer: the opinions above are my own and don't necessarily reflect
those
> of my employer, colleagues or anyone else. I present these opinions solely
as
> an individual.