General FreeBSD desktop workload optimization thread.

In my further quest for desktop optimization, I looked into the PC-BSD sources. And, oh man, is trac awesome!! Anyway they added some options to the kernel:

Code:
#
# PCBSD -- Generic kernel configuration file for PCBSD 8
#

include GENERIC

ident		PCBSD

# Include atapicam support
device          atapicam        # ATAPI Cam Support

# Added support for pf / altq
device          pf
device          pflog
device          pfsync
options         ALTQ
options         ALTQ_CBQ
options         ALTQ_RED
options         ALTQ_RIO
options         ALTQ_HFSC
options         ALTQ_CDNR
options         ALTQ_PRIQ
options         ALTQ_NOPCC

# AppleTalk Support
options         NETATALK

# x86 real mode BIOS emulator, required by atkbdc/dpms/vesa
options         X86BIOS
options		SC_PIXEL_MODE

but more importantly, the following entries in /boot/loader.conf and /etc/sysctl.conf respectively

Code:
# Kernel Options
kern.ipc.shmseg=1024
kern.ipc.shmmni=1024
kern.maxproc=10000

Code:
# Disable the system speaker
hw.syscons.bell=0

# Disable coredump
kern.coredump=0
	
# Up the maxfiles to 4x default
kern.maxfiles=49312
	
# Allow users to mount CD's
vfs.usermount=1

# Enable more sound channels
dev.pcm.0.play.vchans=4
dev.pcm.0.rec.vchans=4

I thought I'd share with you since these are "certified tweaks" if you will for desktop use as stated in the pc bsd wiki.

Cheers!
 
Some random thoughts re this thread:

On the whole, I'm not keen on applying tweaks where I don't understand what they do.

But even if I do understand them, I don't think it's wise to modify the default install without a good reason -- which means that the FIRST thing to do is to profile the system and identify any bottlenecks. There's not much sense in optimizing something that has little impact on overall performance anyway. Do you know where your system is spending the most time? Optimize THAT.

Old programmer's motto: premature optimization is the root of all evil. (It might have been Ritchie or Pike who said that. One of those Unix pioneers anyway.)

Another classic mistake is applying a bunch of tweaks all at once, so you can't tell which one (if any) made any noticeable difference.

Disk access and the filesystem can be a bottleneck, but it's not always. I wouldn't assume that it is, not without some stats to support that conclusion.

You should approach optimization as an exercise in troubleshooting. The most effective methods follow a similar logic. Learn to use vmstat, top, gstat and similar tools. They're not just for servers, you can use them on a desktop too. :)
 
ckester, good points.

I would like to add, that for example 'poor file system performance' is rarely caused by the filesystem performance as such or the disks performance as such. In most 'desktop' cases I found out the filesystem gets hit by badly written, or rather, improperly ported software, devel/gamin comes to mind (I know, it can be configured properly, but "out of the box" is not).

On the other hard, current computers are way more powerful than the needs of almost any desktop application.

By the way, I fail to understand what use can a desktop system have of pf/altq.
 
ckester said:
Do you know where your system is spending the most time? Optimize THAT.

My desktop spends absolutely most of it's time with doing nothing ( waiting for input ).
I guess that is troublesome...

danbi said:
I fail to understand what use can a desktop system have of pf/altq.
You need it if you want to use your desktop as (most probably NAT-ing) internet-router for other computers of yours. Other than that, i don't see a point, either.
 
Packet filter on the local host can be useful, if you want to prevent incoming access from other systems, or restrict incoming access to specific systems, or if you want to block outgoing ports that you don't use.

That last part is most useful on non-Unix systems where malware can use up a lot of network bandwidth, and gave rise to the whole Personal Firewall app category. :)
 
xibo said:
My desktop spends absolutely most of it's time with doing nothing ( waiting for input ).
I guess that is troublesome...

Ha, good one!

Obviously, I meant the things the system is doing when it isn't waiting on the slow human at the keyboard. We usually don't perceive that kind of idling as a performance problem.

Our computers, if they were sentient, would probably have a different opinion. All the more reason to take a thoughtful approach to performance tweaking -- someday the tables might be turned and the computers might be tweaking us. If so, I'd like them to remember how respectful and uncapricious I was when I was in charge. ;)
 
lulz were shared 8)~... hopefully Bender isn't an accurate portrait of the AI to come... what with the KILL ALL HUMANS and what not^^
 
phoenix said:
Packet filter on the local host can be useful, if you want to prevent incoming access from other systems, or restrict incoming access to specific systems, or if you want to block outgoing ports that you don't use.

That last part is most useful on non-Unix systems where malware can use up a lot of network bandwidth, and gave rise to the whole Personal Firewall app category. :)

The way I see it, the policy of the network's gateway should be good enough for any host of that network, and I'd rather allow or block a certain range of services to a certain range of hosts on the gateway than to configure each of the hosts' firewalls.

If the undesired traffic originated from within the own network, fixing the source would prove more efficient then walking/rlogin-ing around and blocking it from each and any host, too.

I don't know about the configurability of the "router" devices you get from ISPs these days, but even if they aren't able to filter the traffic properly I'd replace them with an old PC for firewalling - the PC could do dns- and webcaching which most "router"-s probably can't, too, and webcaching is worth the effort.

About the malware: Every time I get back home from the university kde's dns caching deamon would easily take all the bandwidth of my ISDN uplink to keep it's cache alife, even when there's no outgoing connection or even a browser window running.

Well, in the end however i guess the presence of a firewall isn't a real performance hog for a desktop machine, since desktop's don't get dozens of megabytes of traffic per second to filter and don't do any expensive IDS triggered auto-firewaling, firewall-backed dynamic traffic shaping, or any other expensive firewall-related tasks either.

kronisk said:
lulz were shared 8)~... hopefully Bender isn't an accurate portrait of the AI to come... what with the KILL ALL HUMANS and what not^^
hopefully xibo isn't accurate about his portrait of DutchDeamon to have deleted that post of yours even before xibo clicked the "submit reply" button.
 
I was particularly curious about the usefulness of ALTQ in a desktop, or a server in general. ALTQ is an addition to network drivers that adds prioritization support. If it's useful for non-router usage, perhaps it should be enabled in the FreeBSD GENERIC kernel by default :)
 
danbi said:
I was particularly curious about the usefulness of ALTQ in a desktop, or a server in general. ALTQ is an addition to network drivers that adds prioritization support. If it's useful for non-router usage, perhaps it should be enabled in the FreeBSD GENERIC kernel by default :)

On Windows OS, where that functionality isn't straightforwardly accessible, I would say that ALTQ would undoubtedly be useful. For example, you might be running ftp and BitTorrent transactions, downloading the new windows seven service pack, having your spy-ware report about you and all that while playing video games in the internet, so you rate limit everything other then your game in order to get acceptable latencies.

Some of the download software can be configured to cause only a certain amount of traffic over some time, but many others can't, and when configuring them you rarely consider that you might eventually run multiple of them at the same time.

Of cause, "getting more bandwidth" would also fix the problem ( well, not really, but we should try! )

Unfortunately, there aren't many video games for FreeBSD, and a poor latency in rlogin, telnet, ssh, and so on is normaly not that bad that it would render them unusable. When they become, there's usually other hosts in your network helping to destroy the quality of service, and then you'll need the gateway to do the traffic shaping again - rather than the clients/hosts.

IMO router machines are a primary target for FreeBSD, so it should be in GENERIC anyway.
 
xibo said:
hopefully xibo isn't accurate about his portrait of DutchDeamon to have deleted that post of yours even before xibo clicked the "submit reply" button.

Hopefully talking about oneself in the third person is not an indication of the propensity to utter unsubstantiated allegations.
 
Tell me if it's not allowed to revive such old threads; at least I didn't find anything in the forum rules.

I was with a frozen desktop on Linux due to the problem of copying files to an usb drive: The pernicious USB-stick stall problem.

In FreeBSD-13.0-BETA3-amd64 I get a little improvement, the mouse doesn't get stuck and if I open a medium size application, such as Abiword, it takes a little time to respond, while an application like Firefox lags too much, sometimes until the copy is finished.

I wonder if these suggestions are valid today and how I could improve I/O and the use of limited RAM (2GB). I'm using the Xfce desktop.
 
the use of limited RAM (2GB)
🤣

Limited? I run a machine with half of that:
Code:
root@xxx:~ # grep memory /var/run/dmesg.boot
real memory  = 1077936128 (1028 MB)
avail memory = 959512576 (915 MB)
agp0: aperture size is 256M, detected 32764k stolen memory
I'm using the Xfce desktop
I can recommend x11-wm/openbox on low-end machines like mine (stand-alone, no DE). Runs very smooth.

OpenBox: It runs in about 7MB of memory
Xfce4: It runs in about 70MB of memory


In addition, i run the i386 variant of FreeBsd because it has a lower memory footprint than the amd64 variant. (Too bad i386 will be demoted to tier 2 in 13.x)
 
In addition, i run the i386 variant of FreeBsd because it has a lower memory footprint than the amd64 variant. (Too bad i386 will be demoted to tier 2 in 13.x)
It will not have bigger impact on users as freebsd-update(8) and pkg(8) will be working as usual (binary upgrades and packages).

Its just bugs that will be treated less 'critically' in i386 now.

... and i386 is really old ... I mean Pentium M chips are from 2003 ... that is 18 years ago :)

Of course I with that i386 will remain supported on FreeBSD with freebsd-update(8) and pkg(8) upgrades and packages.
 
...how I could improve I/O and the use of limited RAM (2GB). I'm using the Xfce desktop.

Dump the DE for the WM of your choice. I like x11-wm/fluxbox.

I use editors/leafpad for everything expect when at the login terminal, then it's ee.

Trying out sysutils/gkrellm2 for meters so you can monitor what's going on with your CPU and Memory would be my suggestion. It looks nice, has 180 skins to do it, does a good job and doesn't take up much resources watching them.
 
I was with a frozen desktop on Linux due to the problem of copying files to an usb drive: The pernicious USB-stick stall problem. In FreeBSD-13.0-BETA3-amd64 I get a little improvement, the mouse doesn't get stuck and if I open a medium size application, such as Abiword, it takes a little time to respond, while an application like Firefox lags too much, sometimes until the copy is finished. I wonder if these suggestions are valid today and how I could improve I/O and the use of limited RAM (2GB). I'm using the Xfce desktop.
I found only one sysctl(8) knob mentioned a decade ago that is not available today. IMHO the recommendations from tuning(7), espc. concerning UFS, are still valid. I'd try to disable vfs.vmiodirenable (loader.conf(5)) to have more RAM for applications, and only enable back if that results in a significant slowdown when you use the desktop. You may want to insert the I/O scheduler gsched(8) with my rc(8) script. It served me well for years when I had an UFS on a gjournal(8)'ed disk. IMHO that's preferable to the standard UFS journal. See the article in /usr/local/share/doc/freebsd.
 
I think this is the first architecture ever (for FreeBSD at least) that got demoted from tier 1 to tier 2. But as vermaden says, the whole infrastructure for building the patches (freebsd-update(8)) and pkg(8) was already in place and working. They're not going to remove that. Things are different for architectures that moved up from 3 to 2 (and eventually maybe even tier 1). Then there's no infrastructure in place yet and that would need to be set up first.
 
Back
Top