OpenBSD has no such value to modify, at least not by that name.
anyway, trying to optimize one OS based on (out-of-date?) blog-post
for another OS (albeit both are BSDs) is very close to shooting your own foot.

so I'll vote for it being a bad idea.

i suggest you to start a new thread asking for advice with whatever problem you were
trying to solve with that optimization, if there actually is a limit you're encountering.

Books are static, the software is subject to change. The book was published in December 2004 and the sysctl was added just that year.

Code:

CVSROOT: /cvs
Module name: src
Changes by: tedu@cvs.openbsd.org 2004/04/19 16:52:33
Modified files:
sys/kern : kern_sysctl.c uipc_mbuf.c
sys/sys : sysctl.h
sys/uvm : uvm_extern.h uvm_init.c uvm_km.c uvm_km.h
Log message:
introduce a new km_page allocator that gets pages from kernel_map using
an interrupt safe thread.
use this as the new backend for mbpool and mclpool, eliminating the mb_map.
introduce a sysctl kern.maxclusters which controls the limit of clusters
allocated.
testing by many people, works everywhere but m68k. ok deraadt@
this essentially deprecates the NMBCLUSTERS option, don't use it.
this should reduce pressure on the kmem_map and the uvm reserve of static
map entries.

barti, if you are wanting to find information on parameter tweaking, searching the official mailing lists is far more useful & effective as opposed to mining unknown blog posts of dubious value. In particular, your time will be better spent reading through all of the responses found below:

Note that this information is also dated -- meaning that its application value to more recent versions of OpenBSD is questionable -- which is the point most of the project consistent make to users. In general, the tweaking of system parameters without significant knowledge & experience should be avoided altogether.

The soundbite phrase frequently quoted is "Knobs are for knobs".

Last edited by ocicat; 1st October 2012 at 08:33 PM.
Reason: add clarity since archive information on this subject is also dated

As a final comment barti, you will not find high quality results by searching for OpenBSD-related information using a general-purpose search engine such as Google. Yes, Google may ultimately return hits to information found in the mailing lists, but those hits will not appear in on the first page of search results. The mailing lists simply do not receive enough traffic in order to get a search-order ranking equivalent to their value. This is why most information found the first page of Google searches is dreck.

The best information on OpenBSD is in the archives of the projects' mailing lists. To search the mailing lists specifically, look at any of the archive search engines discussed at the following:

Since OpenBSD has so many data points with dramatically higher latency, it is the clear loser in this benchmark

The clear winner in the graph is Linux 2.6. OpenBSD does not scale at all, and even panics under high load

Whoa! Obviously, something is seriously broken in the OpenBSD memory management. OpenBSD is so incredibly slow that compared to this performance, NetBSD looks like Warp 9, and Linux is not even on the same chart.

OpenBSD had big performance drops in the process, adding to the previous embarassment with mmap. I can really only warn of using OpenBSD for scalable network servers.

OpenBSD data points are all over the place in this graph; again, I would advise against using OpenBSD for scalable network servers

OpenBSD 3.4 was a real stinker in these tests. The installation routine sucks, the disk performance sucks, the kernel was unstable, and in the network scalability department it was even outperformed by it's father, NetBSD. OpenBSD also gets points deducted for the sabotage they did to their IPv6 stack. If you are using OpenBSD, you should move away now.

==================
Does openbsd in later versions do better then this?

I posted above that books (and your ten or twelve year old web pages) are static, and that the OS continues to evolve. For example, in 2003, OpenBSD was still a uniprocessor operating system.

You appear (to me) to avoid conducting your research where up-to-date information can be found. You never seem to ask us about information in:

The OpenBSD FAQ

The OpenBSD man pages

The OpenBSD Journal

The OpenBSD mailing lists

These four places are where information you might need and use can be found. As an example, in the last several days there has been a discussion on the misc@ mailing list of performance benchmarks of the cryptographic overhead of IPSec on a SuperMicro quad core Xeon platform. That user is able to route 900MB per second through his platform in plaintext benchmarks, and 600MB per second through it with encryption and ESP tunnel overheads. You've asked about performance; that's just one metric from this week, not from more than a decade ago. Performance questions and answers regularly are discussed on misc@.

In your history here, every time you have questioned the usability of this OS in this thread and in others, you cite third party information that has been incomplete, outdated, unsubstantiated, or misleading. Or you yourself may misunderstand. For example:

Quote:

I read also that the openbsd developers will break things to make the system more secure.

I don't know what you read, or where you read it, since you didn't say. Let me give you some facts: See the New Technologies section of http://www.openbsd.org/security.html -- in that list are two technologies that stop broken applications from misbehaving: ProPolice and W^X memory protection. The purpose of those technologies was to find badly written software and arrange to get it fixed, whether built-in or third party. Both of these technologies have been completely successful; there are 7,700 third party ports/packages that do not have the programming problems these technologies were designed to catch.

More information on ProPolice and W^X can be found in a number of the papers and presentations available through the Project website. Here's one that covers both of these technologies:

I'm sorry, barti, but I'm not going to try to defend the OS against every Internet posting you find in the wild and bring here. It is entirely up to you whether or not to use this OS. If you decide to do so, you should get your primary information on configuration, tuning, administration, and operation from official channels. And while I'm on the subject -- this forum, too, is third party and not an official channel.

Last edited by jggimi; 3rd October 2012 at 02:39 AM.
Reason: typos, clarity