December 25, 2003
domain name移轉完成
花了一些時間，終於弄好了FreeBSD dns server，一波三折...
原本以為很簡單的，結果也是真的很簡單，不過因為我自己的疏忽，所以讓他變的很難
起先以為直接把設定檔從別台copy過來改一改就完工了
後來發現我copy的bind9用的named.conf給內建的用會有點問題
在改用內建的直接改，一切看起來都很順利，但查詢的時候卻有問題了...
完全查不到我寫的設定
發覺原來是我自己豬頭，用內建的範例直接改，卻沒有把註解符號拿掉，難怪怎麼改都查詢不到XD
新的domain name是damon.idv.tw
December 24, 2003
seednet 1.5M/384 固一轉換完成
昨天花了一點時間終於換好了isp，從hinet換到seednet 1.5M/384，最大的好處是有給一個固定ip，如果您也是用FreeBSD做nat的話，直接把對外的網路卡改成dhcp就可以了，不過要先請客服人員改成自動連線，他會配一個ip給對外的網路卡
考慮來買一個domain name好了XD
December 20, 2003
全球第一台以AMD 64 bits cpu搭配的NB
您可以在這邊看到詳細的介紹，個人感覺以他的價格不算高，只是看起來有點重，而且沒有內建無線網路，所以好像只有cpu比較高檔一點，其他都普普通通這樣XD
https://www.theregister.co.uk/content/54/34562.html
December 19, 2003
sun java desktop system
今天收到了上各禮拜訂購的sun java desktop system 2003，晚上裝起來看看，感覺真不錯，大公司出的產品果然有一定的品質
試用了一下，發覺，果然是base on suse，有些中文翻譯一樣鳥
ok = 行 , eject = 吐出再度出現了XD
xcin沒有酷音可以用，打字有點痛苦
神奇的是竟然可以不需要重跑X就改螢幕解析度，是我孤陋寡聞嗎？還是suse早就可以做到了？
在選了文鼎字型之後，發覺，比其他家的好看，懷疑sun有偷偷放一些patch到這個版本用的字型處理相關的程式
還內建了star office 7中文版for linux，滿方便的
不過有趣的是內建的gaim竟然把msn支援拿掉了，好樣的sun，果然是微軟的死對頭XD
以價格來說的話單單50美金還滿合理的，也不需要自己搞半天就能夠有好看的字型跟一些內建好的網路芳鄰這類的程式，適合懶得花時間自己來研究怎麼弄X的使用者，比較麻煩的是只能從美國買，運費要30美金，超過軟體價格的一半以上:(
如果您有興趣的話可以在以下的url線上訂購跟看一些說明
https://wwws.sun.com/software/javadesktopsystem/index.html
December 17, 2003
December 14, 2003
康寶獨享杯湯
好吧，我承認我作了一件很愚蠢的事情...
今天出門買東西的時候，到頂好，看到有在賣康寶獨享杯，4包賣35元
沒喝過，買了一盒香菇豆腐杯湯，深刻感覺到台灣廠商不實廣告的嚴重..
回家之後打開一包，覺得重量好像太輕了一點，錯覺嗎？
倒進杯子裡之後，發覺是真的很少很少，照著說明倒了大約100cc的熱水進去攪拌一下
喝了第一口，味道好像不太對的樣子，似乎太淡了一點
在泡第二杯，這次水加少一點，好像味道還是很淡，聞起來也沒有甚麼香味
料的份量跟盒子上的照片的比例大概是四包全部一起放下去泡100cc的熱水可能才會有點接近
總之不是很好喝，下次不買了，包裝跟實際物品實在相差太大，個人感覺上是原本一碗大概35塊錢的湯硬是分成四碗來賣，所以要泡的時候是要四包一起泡100cc的熱水才大概會好一點
December 11, 2003
Tuning FreeBSD for different applications
A guide to server and workstation optimization, by Avleen Vig
Server and workstation tuning is an ongoing process.
Believing that you are done only means that you don't know what else can be tuned.
This article should apply equally to FreeBSD 4.x and 5.x
The method of tuning your system is heavily dependent on its function:
* Will the system perform a lot of small network transactions?
* Or a small number of large transactions?
* How will disk operations factor in?
How you answer these and other questions determines what you need to do to improve the performance of your system.
There are several steps you can take before you need to start changing sysctls or re-arranging your partitions. How your applications are compiled plays a major role too. Beyond application compilation we will look at tuning the various other parts of our system including the network, disks, and other system control functions. I have tried not to duplicate the data in the tuning(7) man page, which already contains a wealth of good information on the basics of system performance tuning.
Optimizing software compiling
When source code is compiled, your compiler makes assumptions about your hardware in order to create compatible binaries. If you have an x86-complient CPU for example, your compiler will by default create binaries which can be run on any CPU from a 386 onwards. While this allows portability, any new abilities your CPU advantage of (MMX, SSE, SSE2, 3DNow!, etc) will not be used. So portability creates inefficiency. This is also why using pre-compiled binaies on your system is a sure fire way to reduce your overall performance!
System tuning is best performed on a new system, before many packages are installed. The steps you take here will also effect any new software you install. We assume that your packages are installed from the ports collection (/usr/ports). These steps should be applicable to any other software compiles and we will cover that later in this paper.
The first step to making sure your ports software will be compiled effeciently is to have good compiler flags set up. These are defined in /etc/make.conf. This file does not exist on new systems, but you can copy /etc/defaults/make.conf to /etc/make.conf.
Edit the file, and look for the line starting: #CPUTYPE=
Valid options for the CPUTYPE are listed in the file, in the paragraph above this line. My server is a P233/MMX, and my CPUTYPE line looks like: CPUTYPE=i586/mmx
What this does: The CPUTYPE option notifies the compiler of any special features your CPU has. The compiler will then, where possible, compile code to take advantage of these features. The disadvantage to this is that your compiled binaries may not run on different CPU types. As long as you aren't copying binaries from one server to another, this should not be a problem.
Also in the file, look for the line: #CFLAGS= -O -pipe
Uncomment this line, and change it to: CFLAGS= -O2 -pipe -funroll-loops
What this does: The '-O2' flag sets the optimization level. GCC has the following possible optimization levels:
* -O: Some opimizations are enabled such as '-fthread-jumps' and '-fdefer-pop'
* -O2: All optimizations which do not cause the size of the resulting executable to increase are turned on. This is useful for a speed/space tradeoff
* -O3: Optimize even more. This option may cause the size of your bianries to increase
* -Os: Optimize for size. Perform most of the optimizations in -O2 and some which reduce the code size
The '-pipe' option decreases the amount of time taken to compile software. When two compiler processes need to communicate data between each other, they can use files on the disk or pipes. As pipes do not require writing anything to disk they can significantly decrease the amount of time taken here.
Finally, '-funroll-loops' causes finite loops to be "unrolled". When a binary compiled with this option is run, the CPU does not have to run through every possible itteration of the loop to get its result. Instead, loops are replaces with with their equivilent non-looping code. This saves one CPU register which would otherwise be tied up in tracking the itteration of the loop.
The gcc man page (man gcc) is a good resource for this.
Warning: It has been noted that for some users on FreeBSD 4.8 and 4.9, the -funroll-loops causes SSHv2 with the base OpenSSH to break. Installing the OpenSSH-portable port to overwrite the base install fixes this problem quickly and easily, and provides a newer version of OpenSSH:
* cd /usr/ports/security/openssh-portable && \
make install -DOPENSSH_OVERWRITE_BASE
The make.conf file also contains a line for CXXFLAGS. These options are similar to our CFLAGS options but are used for C++ code. If you are going to compile C++ code, you should take a look at this also.
Optimizing kernel compiling
Efficient kernel compiling is covered in my Kernel Tuning paper at: https://silverwraith.com/papers/freebsd-kernel.php
Optimizing network performance
How you optimize your system for networking depends on what your system will be doing. Below we will take a look at two common applications for servers, Mail and File serving.
Network throughput:
There are a number of steps which can be applied to all installations to improve network performance, and should be done by everyone.
Most modern network cards and switches, support the ability to auto-negotiate the speed to communicate at. While this reduces administration is, it comes at the cost of network throughput. If your switch, server or workstation is set to use auto-negotiation, every few moments it stops transferring network traffic in order to renegotiate its speed. On low-bandwidth use networks this performance degradation might be hard to spot, but on high-bandwidth use networks it become very obvious: You have packet loss, you cannot achieve your full line speed, and your CPU usage is low. I would recommend that everyone read the man page on their network driver and manually define the network speed. This should if possible, also be done on the network switch. Some simple $10 switches do not have interfaces to which you can log in to set this, but fortunately they usually do not renegotiate the network speed after the cable is plugged in, unless the network link is lost.
The network speed can either be set with ifconfig at run time, or in /etc/rc.conf for boot time. Here are two examples for /etc/rc.conf for the rl(4) and fxp(4) network drivers:
* ifconfig_rl0="inet x.x.x.x netmask x.x.x.x media 100baseTX mediaopt full-duplex"
* ifconfig_fxp0="inet x.x.x.x netmask x.x.x.x media 100BaseTX mediaopt full-duplex"
If you are fortunate enough to have one of the following network cards:
* dc -- DEC/Intel 21143 and clone 10/100 ethernet driver
* fxp -- Intel EtherExpress Pro/100B ethernet device driver
* rl -- RealTek 8129/8139 fast ethernet device driver
* sis -- SiS 900, SiS 7016 and NS DP83815 fast ethernet device driver
Note: If your card isn't listed here, do not give up hope! More drivers are being converted as demand comes in and you should look at the documentation for your driver to see if it is supported. If you're still unsure, join the freebsd-questions@freebsd.org mailing list from https://lists.freebsd.org/mailman/listinfo and ask there.
You can enable DEVICE_POLLING in your kernel. DEVICE_POLLING changes the method through which data gets from your network card to the kernel. Traditionally, each time the network card needs attention (for example when it receives a packet), it generates an interrupt request. The request causes a context switch and a call to an interrupt handler. A context switch is when the CPU and kernel have to switch from user land (the user's programs or daemons), and kernel land (dealing with device drivers, hardware, and other kernel-bound tasks). The last few years have seen significant improvements in the efficiency of context switching but it is still an extremely expensive operation. Furthermore, the amount of time the system can have to spend when dealing with an interrupt can be almost limitless. It is completely possible for an interrupt to never free the kernel, leaving your machine unresponsive. Those of us unfortunate enough to be on the wrong side of certain Denial of Service attacks will know about this.
The DEVICE_POLLING option changes this behavior. It causes the kernel to poll the network card itself at certain predefined times: at defined intervals, during idle loops, or on clock interrupts. This allows the kernel to decide when it is most efficient to poll a device for updates and for how long, and ultimately results in a significant increase in performance.
If you want to take advantage of DEVICE_POLLING, you need to compile two options in to your kernel:
* options DEVICE_POLLING
* options HZ=1000
The first line enables DEVICE_POLLING and the second device slows the clock interrupts to 1000 times per second. The need to apply the second, because in the worst case your network card will be polled on clock ticks. If the clock ticks very fast, you would spend a lot of time polling devices which defeats the purpose here.
Finally we need to change one sysctl to actually enable this feature. You can either enable polling at runtime or at boot. If you want to enable it at boot, add this line to the end of your /etc/sysctl.conf:
* kern.polling.enable=1
The DEVICE_POLLING option by default does not work with SMP enabled kernels. When the author of the DEVICE_POLLING code initially commited it he admits he was unsure of the benefits of the feature in a multiple-CPU environment, as only one CPU would be doing the polling. Since that time many administrators have found that there is a significant advantage to DEVICE_POLLING even in SMP enabled kernels and that it works with no problems at all. If you are compiling an SMP kernel with DEVICE_POLLING, edit the file: /usr/src/sys/kern/kern_poll.c and remove the following lines:
#ifdef SMP
#include "opt_lint.h"
#ifndef COMPILING_LINT
#error DEVICE_POLLING is not compatible with SMP
#endif
#endif
Mail servers:
Mail servers typically have a very large number of network connections, which transfer a small amount of data for a short period of time, before closing the connection. Here is it useful for us to have a large number of small network buffers.
Network buffer clusters are assigned two per connection, one for sending and one for receiving. The size of the buffer dictates how fast data will be able to funnel through the network, and in the event of a network delay how much data will be able to backlog on the server for that connection before there is a problem. Having a network buffer too small means data will be backlogged at the CPU waiting for the network to clear. This causes greater CPU overhead. Having a network buffer too large means that memory is wasted as the buffer will not be used efficiently. Finding this balance is key to tuning.
When we discuss simultaneous network connections, we refer to connections in any network state: SYN_SENT, SYN_RECV, ESTABLISHED, TIME_WAIT, CLOSING, FIN_WAIT, FIN_WAIT_2, etc. Even if the network connection is in an ESTABLISHED state for only a few seconds, it can end up in any of the other states for a long time. I generally find that multiplying the number of ESTABLISHED connections by 8 leaves me with room to breath in the event that I see an abnormally high surge of traffic inbound or outbound. I've come to this number over time through trial and error. So if you expect to have a peak of 128 servers sending you mail, having 2048 network buffer clusters would be good (128 * 2 per connection * 8). Also remember that connections can take up to two full minutes or more to close completely. So if you expect more than 128 mails in any given two minute period, you also need to increase the number to accomodate that.
Another important value to control is the maximum number of sockets. One socket is created per network connection, and one per unix domain socket connection. While remote servers and clients will connect to you on the network, more and more local applications are taking advantage of using unix domain sockets for inter-process communication. There is far less overhead as full TCP packets don't have to be constructed. The speed of unix domain socket communication is also much faster as data does not have to go over the network stack but can instead go almost directly to the application. The number of sockets you'll need depends on what applications will be running. I would recommend start with with same number of network buffers, and then tuning it as appropriate.
You can find out how many network buffer clusters in use with the command netstat -m
You can specify the values you want, at the end of your /boot/loader.conf file as:
* kern.ipc.nmbclusters=2048
* kern.ipc.maxsockets=2048
Note: With any performance tuning, it is important to monitor your system after you make your changes. Did you go overboard, or underestimate what you would need? Always check and adjust accordingly. The numbers here might not be the exact ones that you need!
File servers:
Tuning the network for file servers is not unlike tuning mail servers. The main differences are:
* File servers generally have longer-lived network connections
* File servers usually transfer larger files than mail servers
* File servers mostly perform less transfers than mail servers
Again we come back to network buffer clusters. How many clients do you have? With file servers the chances of a spike in the number of connections is small, as the number of clients is fixed. Therefore we do not need to set aside large numbers of buffers to accommodate spikes. Multiplying the number of network buffers by two is good practice, and some admins prefer to multiply by four to accommodate multiple file transfers.
So if we have 128 clients connecting to the file server, we would set the number of network buffer clusters to 1024 (128 * 2 per connection * 4) in /boot/loader.conf:
* kern.ipc.nmbclusters=1024
* kern.ipc.maxsockets=1024
Note: With any performance tuning, it is important to monitor your system after you make your changes. Did you go overboard, or underestimate what you would need? Always check and adjust accordingly. The numbers here might not be the exact ones that you need!
Web servers:
Web servers are not unlike mail servers. Unless you are doing a lot of file serving over the Internet, you will have clients connecting to you for short periods of time. If you have more than one element on your web page, for example multiple images or frames, you can expect that the web browsers of clients will make multiple connections to you. Up to four connections per page served are certainly not uncommon. Also if your web pages use server-side scripting to connect to databases or other servers, you need to add a network connection for each of those.
Web servers again like mail servers, go through periods of highs and lows. While on average you might servers 100 pages a minute, at your low you might server 10 pages a minute and at peak over 1000 pages a minute. Whether you have 128Mb RAM, or 1Gb RAM, you should try and be as liberal as possible in allocating memory to your network stack. Using the above example, at a peak of 1000 pages per minute, your clusters and sockets should be around 16384 (1000 pages * 2 per connection * 4 connections * 2 for growth) in /boot/loader.conf:
* kern.ipc.nmbclusters=16384
* kern.ipc.maxsockets=16384
Tuning your Apache or other web servers is slightly outside the scope of this paper, as there is already a ton of excellent data availible on the internet which I could never hope to do justice in this paper. A starting point I would recommend is Aleksey Tsalolikhin's notes from his Nov 2001 presentation to the Unix Users Association of Sothern California on web server performance tuning: https://www.bolthole.com/uuala/webtuning.txt, it should lead you on to more wonderful things.
Note: With any performance tuning, it is important to monitor your system after you make your changes. Did you go overboard, or underestimate what you would need? Always check and adjust accordingly. The numbers here might not be the exact ones that you need!
Optimizing disk usage and throughput
Optimizing the the disk subsystem on FreeBSD also depends on what you want to do with your system. It is very much installation dependent, so what I've done below is list the various factors and what they do. You can decide what is best for you.
1. RAID:
RAID is a method of spreading your data over multiple disks. There two reasons why you might use RAID; for redundancy to prevent data loss, and for speed. The three most common types of RAID in use on small system installations are RAID0, RAID1 and RAID1+0 (sometimes referred to as RAID10).
With RAID1 (also called mirroring), you use only two disks per partition, and keep the data on both disks identical. In the event that one disk is lost, you have your data on another disk. The speed advantage from RAID1 comes when reading. Your system can send multiple read requests to the disks, which will be performed in parallel. The disk whose heads are closest to the requested space will get the request to fetch the data. Writes are no faster than on a single disk. When a write request is sent, both disks must acknowledge that the write has completed before the write is finished.
RAID0 (also called stripping) spreads the data evenly over two or more disks. Data on one disk is not replicated on the others, so there is no redundancy to prevent data loss. But reads and writes are significantly faster as they happen on multiple disks at the same time. This increases your throughput and your maximum disk operations relative to the number of disks you have. For example, 4 disks would give a 400% increase.
RAID10 offers the best of both worlds and requires at least 4 disks. Half of the disks are stripped with RAID0, and then both are replicated as a mirror on the remaining disks.
2. Queue splitting:
Is you are running a mail server and feel that your system is being slowed because of the speed of your disks, an alternative to RAID could be to split your queues. Most modern mail transfer agents (MTA's) have the ability to break up their large single queue directory into multiple smaller directories. These multiple directories can then be placed on different disks. There are several advantages to this:
* A disk failure will only take out a half or less of your queue
* Your throughput on mail will not be disk bound
* Opening 20 small directories is significantly faster than opening one huge directory
3. Partitioning:
Having separate partitions on separate disks can help a lot. For example, your system will always be performing different tasks at any one given time: writing log files, serving out data, and so on. The Unix directory structure is built around using different directories for partitions for different purposes. /usr is traditionally used for user data, /var is used for log and mail spools, etc. Arrange these on different disks to best suit your needs. If you have disks of varying speeds on your system, place the most frequently used partitions on the faster disks.
4. IDE vs SCSI:
Back in days of yore (in the early 1990's) when disk performance was crucial, the choice was quite obviously to go for SCSI disks. SCSI provided faster throughput, and less bottle-necking. SCSI disk sizes were significantly larger and more disks could fit in a single system. Times have changed and so have the requirements of most users, and the much sought after disk sizes and faster throughput's are now available on IDE disks. SCSI disk sizes have also grown but not as fast. SCSI disks still offer faster throughput's however. At the time of writing, the fastest IDE disks could push 133Mbyte/s, whereas the fastest SCSI disks could push 320Mbyte/s.
References:
This is a list of references I found when writing this paper. Most of them contain much more detail on their particular subject than I have provided here. Hopefully they will be as useful to you as they were to me.
* The FreeBSD handbook. A great source on information about FreeBSD. Have a read here if you want to learn something new on FreeBSD
* Google Groups. I used this extensively to search USENET for articles others may have posted in the past. You should too!
* htmlhelp.com is made by the Web Design Group to "promote the creation of non-browser specific, non-resolution specific, creative and informative sites that are accessible to all users worldwide." It was valuable in the creation of this site.
Optimising FreeBSD and it's kernel
A simple step by step guide, by Avleen Vig
This is a very simple step by step guide on optimising your FreeBSD server or workstation. It doesn't go into a great amount of detail, but after spending several months searching for one source of simple optimisation information and failing, I wrote this paper. All the suggestions listed here are known optimisations available to you if you know where to find them and have the time to do so. There is nothing secret, or special or amazing in this paper, just information on how you can optimise your system.
It can mostly be applied to the other BSDs too, but not Linux. There are plenty of Linux documents out there, so go find one of those. I'm sure there are several HOWTO's. This document is true as of the release of FreeBSD 4.8. Some parts of it, such as optimising your kernel, can also be applied to some previous releases.
Before we proceed any further you should know that as with any system tuning, we have to accept the possibility that something will break. If you're going to recompile the kernel, please read the following URL first. If possible print a copy of the page and keep it with you. It'll help you if your new kernel doesn't boot:
https://www.freebsd.org/handbook/kernelconfig-trouble.html
First we need to make sure we have the right source files downloaded. The best place to start, is the original source files that were intended for the release of FreeBSD you are using. We assume you have a fairly recent release - not more than 2 revisions (approx 6 to 8 months) old. Execute the following command and follow the steps to get the sources needed to recompile a kernel:
* # /stand/sysinstall
* Choose 'Configure'
* Choose 'Distributions'
* Choose 'src'
* Choose 'sys' and then choose 'OK', and 'OK' again.
* Choose an FTP site to download the sources from. If you're prompted to 'skip over the network configuration now', choose 'Yes'. After the install is complete, choose the 'Exit' options until you exit sysinstall.
Congratulations, you now have a know working kernel source tree installed in /usr/src/sys!
Now, cd /usr/src/sys/i386/conf and follow the next steps.
You should see two files in this directory, GENERIC and LINT. These are both kernel configuration files and contain all the data the kernel needs from the user, to compile. They are very easy to read and edit.
GENERIC is the Generic kernel configuration which should work with every system. LINT contains a list of all possible kernel configuration file directives. We won't worry about LINT just yet. First lets trim the GENERIC kernel down and get comfortable with that. Follow these steps to success:
* Copy the GENERIC file to a new file. Traditionally, this new file has the same name as the hostname of your machine.
* Edit this new file in your favourite text editor. I prefer vi and have written a cheat sheet for new vi users at:
https://www.silverwraith.com/papers/vi-quickref.txt
* There are only a few pitfalls and special cases to watch out for in this file. As you can see it just a plain text file and any line starting with a # is considered a comment and ignored by the compiler.
o The word 'GENERIC' in the line 'ident GENERIC' is the name of your kernel. This can be any single alphanumeric word with no spaces or punctuation. I recommend you keep it short. Again, it is traditional to name this to be the same as your machine hostname and kernel configuration file name but it is not required. It is informational only.
o The maxusers line does not actually limit the maximum number of users. It is used internally with an algorithm in the param.c file to determine the sizes and numbers of certain tables. This can remain at the default. As of FreeBSD 4.7 this is set to '0' by default, which causes the actual value to be auto-sized depending on the amount of memory that you have.
o Most, if not all items in your kernel config will have a comment toward the end of the line. Anything labelled with '[KEEP THIS!]' should not be removed. FreeBSD needs these things! Anything labelled '(required!)' should also be kept if you're going to use that type of device. For example, if you're going to use SCSI devices, don't comment out 'scbus'. If you're not using any SCSI devices, then you should comment this out. Some PCI network cards require the inclusion of 'device miibus'. These are noted in your kernel configuration file. If you don't use these NICs you can also comment this out.
o Now go through the entire file and comment out anything you don't think you'll need. Effectively every line contains a driver. Commenting it out will mean that particular piece of hardware will not work your system, even though it may be recognised as present in the system. Thus it is bad to comment out your own network card, but good to comment out any cards you don't have. Don't worry if you comment out something you will need later. You can always recompile fairly quickly and simply.
* After you've finished editing the configuration file, save it and exit from the editor.
* Issue the command: config
* cd to the directory that config gave and issue these commands in turn, each after the previous has finished:
o # make depend
o # make
o # make install
o Hopefully the above will all work without producing an error. If you get an error, see your local FreeBSD Guru. If you got no error, consider the installation of the new kernel a success!
That is it. Really! If something breaks and your new kernel will not boot, DON'T PANIC! Read the 'Kernel Does Not Boot' section of the URL at the top of the page.
Optimising compiling of code, the kernel
and debugging kernels
This section is for the slightly more advanced compilation of code and kernels. We will also briefly mention how to compile a kernel with the debugging symbols built in. The debugging kernel can be useful when your server or workstation is kernel panicing frequently and you want to find out why. There is a great article from OnLamp.com on how to debug a kernel, available at:
https://www.onlamp.com/pub/a/bsd/2002/04/04/Big_Scary_Daemons.html
Optimising code and kernel compilation
First lets look at optimising the compilation of C code itself. One of the key tasks when doing this is to start with as simple a configuration as possible. Hopefully if you've read everything above you'll be at this stage already :-)
You should set a few specific options in /etc/make.conf that will optimise the compilation of new code on your machine. This means all code will be compiled with these options. If you set the right ones, they can significantly improve the speed and efficiency with which code is compiled and executed. They will also help to reduce memory consumption. If you have installed the portupgrade package from /usr/ports/sysutils/portupgrade, you should execute this command after setting these options and updating your ports collection. It will cause every port you have installed, to have it's latest version downloaded and recompiled with the optimisations. I think it is worth it:
portupgrade -ra
Updating your ports collection en masse can have other consequences which are worth realising. If the current installed version of your port has undergone a major update (eg exim3 to exim4), a straight upgrade in this way could break your configuration. Use with care! The compilation process can take a while, depending on the speed of your CPU, the amount of memory you have, your internet connection and so on, so if you're on a slow link and wish to download the distfiles for each package first and do the updating offline, you can issue this command to download the distfiles for each port first:
portupgrade -Fra
So without further ado, the list of optimisations follows. Initially you won't have an /etc/make.conf, you can just start editing a file with that name (if you want to see every possible option to put in the file, reference /etc/defaults/make.conf):
CPUTYPE=cpu_type
where cpu_type is one of i386, i486, i586, i586/mmx i686, p2, p3, p4, k6, k6-2, or k7.
gcc v2, which comes with FreeBSD doesn't yet support the latest Athlon optimisations, so if you
have a Thunderbird or other such CPU, just set k7 for now. gcc v3 has better support and this
will be available in FreeBSD 5 when it is released toward the end of 2002.
NOTE: An important point to remember: Most CPU's of the same family are backward compatible.
That is, the K7 is backward compatible with K6 code. Also, Intel-CPU code is mostly universally
compatible across CPU families. However, if you compile code for a non-Intel family CPU type and
later upgrade to a newer Intel CPU, there is a good chance you may encounter problems unless you
recompile your code.
CFLAGS= -O3 -pipe -funroll-loops -ffast-math
-O3 sets optimisation level 3 where the largest number of practical optimisations can be made
to your code (everything except the kernel). It also does sacrifice binary size for speed.
-pipe causes code to be passed between processes using pipes during compilation rather than
using temporary files, which has obvious I/O advantages.
-funroll-loops causes iterating loops with a known number of iterations to be unrolled into
faster executions.
-ffast-math breaks IEEE/ANSI strict math rules. One way it does this is by assuming that the
square root of numbers are non-negative. This shouldn't be used if you're compiling code that
relies on the exact implementation of IEEE or ANSI rules for math functions. Unless you're
writing your own code that does just this you shouldn't have a problem with setting this. It
should help reduce your compile times.
COPTFLAGS= -O2 -pipe -funroll-loops -ffast-math
This is the same as the "CFLAGS" statement, except it's used on the kernel when you compile it.
We choose -O2 instead of -O3, because -O3 is known to produce broken kernels. Officially, only
-O is supported, but I have never had a problem with -O2. It should be noted at this point that
one difference between -O2 and -O3 is that -O3 produces slightly larger code during its
optimising. In normal situations this is OK, but we want to compact the kernel down it is
another reason to stick with -O2. This also has the same effect as adding the 'makeoptions
COPTFLAGS' lines to the kernel config as discussed below.
kernel optimisation
In you kernel configuration, add the following line after the 'machine' (i386, i486, etc) types near the top:
makeoptions COPTFLAGS="-O2 -pipe -funroll-loops -ffast-math"
This does two things. First the -O2 switch tells the compiler to optimise the compilation. This takes advantage of internal compiler tricks to do this. You could use -O3 to implement even more optimisation tricks, but these aren't supported and -O3 is known to cause many stability issues. -O2 may or may not work for you depending on how many things you have compiled into the kernel and how non-standard your hardware is.
TOP_TABLE_SIZE=number
where number is a prime number, at least twice the number of lines in /etc/passwd.
This statement sets the size of the hash that the top(1) uses for usernames when it
runs.
options CPU_WT_ALLOC
should be set if you have an AMD K5/K6/K6-2 or Cyrix 6x86 chip. It provides for the kernel to enable cache Write Allocation for the L1 cache, which was disabled by default on these chips.
options NFS_NOSERVER
If you are running a workstation or server when you know that you will not be acting as an NFS server, you can add the above line to your kernel configuration to disable NFS server code. NFS servers allow other servers and workstations to mount parts of their filesystems using the Network FileSystem protocol.
options NSWAPDEV=number
Another way of saving kernel memory is to define the maximum number of swap devices. Your kernel needs to allocate a fixed amount of bit-mapped memory so that it can interleave swap devices. I set the preceding parameter to 1 on my workstation and 2 on my servers. I rarely run out of swap space on a workstation but if I need to add more to a server, I can easily create another partition
Building a debugging kernel
Another option you have when compiling your kernel is to build with the debugging symbols. This can be fundamental in determining the reason your kernel panics, if it does. Be warned though - compilation time can increase slightly when doing this. To make a debug kernel, add the following line to your kernel configuration:
makeoptions DEBUG=-g
This doesn't actually install a kernel with full debugging symbols as /kernel. The /kernel that gets installed is the stripped down regular kernel, but a separate kernel.debug file is in /usr/src/sys/compile/Your_Kernel_Name/kernel.debug. If your kernel panics and leaves behind a core file, the kernel.debug file is used to get the debugging symbols when you actually do the debug. See the OnLamp article for more on this.
One final thing you need to do if you're going to be building a debug kernel, is to have your system actually dump the memory to the swap partition. You can do this by adding the following like to /etc/rc.conf and rebooting:
dumpdev="/dev/ad0s1b"
Where "/dev/ad0s1b" is your swap partition as defined in /etc/fstab.
NOTE: Your swap partition needs to be at least 1Mb (1024Kb) bigger than your total amount of memory. When your system crashes, the memory will get dumped to your swap partition. When your system returns, your swap partition will be enabled and your disks will be fsck'd before they are mounted. During this process, fsck uses a small amount of swap space. It would be preferable if you had twice as much swap space as memory in this situation.
References:
This is a list of references I found when writing this paper. Most of them contain much more detail on their particular subject than I have provided here. Hopefully they will be as useful to you as they were to me.
* OnLamp.com article on debugging FreeBSD kernels. It helped me debug and fix my first kernel.
* The FreeBSD handbook. A great source on information about FreeBSD. Have a read here if you want to learn something new on FreeBSD
* Google Groups. I used this extensively to search USENET for articles others may have posted in the past. You should too!
* htmlhelp.com is made by the Web Design Group to "promote the creation of non-browser specific, non-resolution specific, creative and informative sites that are accessible to all users worldwide." It was valuable in the creation of this site.
December 10, 2003
blog版面修改完成
花了一些時間修改成現在的版面，您有興趣的話可以參考看看
把一些在看起來太小的字體放大了，還有一些顏色上的搭配也改了
css檔如下：
body {
margin:0px 0px 10px 0px;
background:#FFFFFF;
}
A { color: #999966; text-decoration: none; font-weight:normal; }
A:link { color: #003366; text-decoration: none; }
A:visited { color: #003366; text-decoration: none; }
A:active { color: #003366; }
A:hover { color: #003366; }
h1, h2, h3 {
margin: 0px;
padding: 0px;
}
#banner {
font-family:verdana, arial, sans-serif;
color:#FFF;
font-size:x-large;
font-weight:normal;
border-bottom:1px dotted #FFF;
border-top:3px solid #99CCFF;
background:#336699;
padding:15px;
text-transform:uppercase;
letter-spacing: .2em;
}
#banner a,
#banner a:link,
#banner a:visited,
#banner a:active,
#banner a:hover {
font-family:verdana, arial, sans-serif;
font-size: x-large;
color: #FFF;
text-decoration: none;
}
.description {
font-family:verdana, arial, sans-serif;
color:#99CCFF;
font-size:x-small;
font-weight:bold;
background:#336699;
text-transform:none;
letter-spacing: none;
}
#content {
float:left;
width:65%;
background:#fff;
border-right:1px dotted #999;
margin-right:15px;
padding-bottom:20px;
}
#links {
background:#fff;
padding-right:15px;
}
.blog {
padding-left:15px;
padding-top:15px;
padding-right:15px;
}
.blogbody {
font-family:georgia, verdana, arial, sans-serif;
color:#666;
font-size:small;
font-weight:normal;
background:#FFF;
line-height:140%;
padding-left:10px;
padding-right:10px;
padding-top:10px;
}
.blogbody a,
.blogbody a:link,
.blogbody a:visited,
.blogbody a:active,
.blogbody a:hover {
font-weight: normal;
text-decoration: underline;
}
.title {
font-family: verdana, arial;
font-size: small;
color: #003366;
text-transform: uppercase;
font-weight:bold;
}
.menu {
margin-bottom:15px;
color: #003366;
background:#99CCDD;
}
.date {
font-family:georgia, verdana, arial, sans-serif;
font-size: small;
color: #999;
border:1px solid #999;
padding:5px;
margin-bottom:10px;
font-weight:normal;
}
.posted {
font-family:verdana, arial, sans-serif;
font-size: normal;
color: #003366;
margin-bottom:15px;
}
.calendar {
font-family:verdana, arial, sans-serif;
color:#AAAAAA;
font-size:small;
font-weight:normal;
background:#FFF;
line-height:140%;
padding:2px;
text-align:center;
}
.calendarhead {
font-family:verdana, arial, sans-serif;
color:#AAAAAA;
font-size:small;
font-weight:normal;
background:#FFF;
line-height:140%;
padding:2px;
}
.side {
font-family:verdana, arial, sans-serif;
color:#99CCDD;
background:#99CCDD;
font-size:small;
font-weight:normal;
background:#FFF;
line-height:140%;
padding:2px;
}
.sidetitle {
font-family:verdana, arial, sans-serif;
color:#FFFFFF;
font-size:small;
font-weight:normal;
background:#99CCDD;
line-height:140%;
padding:2px;
margin-top:10px;
text-align:center;
text-transform:uppercase;
letter-spacing: .2em;
}
.syndicate {
font-family:verdana, arial, sans-serif;
font-size:small;
font-weight:normal;
color:#99CCDD;
background:#FFFFFF;
line-height:140%;
padding:2px;
margin-top:10px;
text-align:center;
}
.powered {
font-family:verdana, arial, sans-serif;
color:#99CCDD;
background:#FFFFFF;
font-size:small;
font-weight:normal;
border-top:1px solid #CCC;
border-bottom:1px solid #CCC;
line-height:140%;
text-transform:uppercase;
padding:2px;
margin-top:10px;
text-align:center;
letter-spacing: .2em
}
.comments-body {
font-family:verdana, arial, sans-serif;
color:#666;
font-size:small;
font-weight:normal;
background:#FFF;
line-height:140%;
padding:10px;
}
.comments-post {
font-family:verdana, arial, sans-serif;
color:#666;
font-size:x-small;
font-weight:normal;
background:#FFF;
}
.trackback-body {
font-family:verdana, arial, sans-serif;
color:#666;
font-size:small;
font-weight:normal;
background:#FFF;
line-height:140%;
padding:10px;
}
.trackback-url {
font-family:verdana, arial, sans-serif;
color:#666;
font-size:small;
font-weight:normal;
background:#FFF;
line-height:140%;
padding:10px;
border:1px dashed #CCC;
}
.trackback-post {
font-family:verdana, arial, sans-serif;
color:#666;
font-size:x-small;
font-weight:normal;
background:#FFF;
}
.comments-head {
font-family: georgia, verdana, arial, sans-serif;
font-size: small;
color: #666;
border:1px solid #999;
padding:5px;
font-weight:normal;
margin-top:10px;
}
#banner-commentspop {
font-family:georgia, verdana, arial, sans-serif;
color:#FFF;
font-size:large;
font-weight:bold;
border-bottom:1px dotted #FFF;
border-top:3px solid #99CCFF;
background:#336699;
padding:15px;
}
December 09, 2003
The R In R&B Collection, Vol. 1
我最喜歡的R&B歌手之一R. Kelly推出了個人精選集，不過只有一首新歌，如果以前沒有買過的話，可以考慮買來聽聽看，可是收錄的歌曲有些其實我個人覺得還有更好的可以收錄，應該還有更好的選擇，anyway個人選擇吧
您可以在這邊找到一些試聽的片段(美國版)，雖然大部分都是舊歌
不過要注意的是，台灣版的有多了五首歌，至於是哪五首，我就不查了
https://www.towerrecords.com/product.aspx?pfid=82876552142&from1=BMGRK
December 08, 2003
ArcServe vs CA
上各星期發mail到CA詢問兩個技術問題
1.一切都照的說明書安裝的oracle agent for linux跟ArcServe v9 for linux為什麼在server端會找不到db
2.ArcServe v9 for linux跑起來之後，大約開了30各port，公司需要透過firewall連線遠端管理，哪些需要開啟，哪些不需要
今天收到回覆了
問題一：只是好聽一點的RTFM
回覆大概如下：
01.please check the oracle service is running
02.please turn the archive log mode on and restart oracle and oracle agent
03.please check if anything wrong in instance.cfg
問題二：大概是他們也不會，或是不想回答，或是OOXX理由，不回就對了
問問題的時候還需要填一些表格，我連我下過哪些指令的log都附上了，結果得到的是RTFM，如果manual上的是有用的，我還需要問嗎？
manual上沒有的東西，直接不答，好樣的
CA的經銷商更神，還附註說：如果都看不到db的話，可能是oracle agent安裝不完整
完整的照的CA偉大的manual安裝的，還附上所下的所有指令，哪裡不完整？
最後決定退貨，47K的oracle agent，卻是這樣的售後服務，如果這輩子我還會考慮使用CA的產品的話，那我一定是瘋了
附帶一題，現在對non free software越來越討厭了，真希望CA這種爛公司，快點倒吧，這些爛工程師，爛客服人員，就讓市場自然淘汰他們吧
December 07, 2003
這一篇是non free software的:(
View image
View image
View image
View image
今天玩一下非常不常玩，大約一年半前滿常玩的遊戲，發現一些有趣的現象XD
從圖中可以看出，在同一個場景下，自己看的到手上的裝備(這東西是交易來的)，但從其他玩家的畫面上卻是手上甚麼都沒有，不過可能是bug，不管他，不太想花時間去研究non free software
Debian unstable update服務恢復
經過前一陣子被crack的問題發生之後，debian unstable在stable了一段時間之後終於重新online了，有在使用debian unstable的朋友，衝阿
您可以在這邊找到整個被crack的過程與說明，如果您用的是有問題的kernel，儘快更新吧
https://moto.debian.org.tw/viewtopic.php?t=2446
FreeBSD 5.2 beta available
經過了長時間的等待，FreeBSD 5.2 release終於快要release了，您可以在這邊找到大約會有那些新功能
https://www.freebsd.org/releases/5.2R/todo.html
至於那時候會出release，您可以到這邊參考看看，不過通常都是會delay，delay多久大概只有天知道XD
https://www.freebsd.org/releases/5.2R/schedule.html
不怕死的FreeBSD愛用者，衝阿
December 06, 2003
suse linux試用感想
最近試用了朋友那邊借來的suse 9 professional，試用了一下
安裝介面作的還不錯，但有一套自己的思考方式在做這些東西，所以跟一般的不太一樣
安裝介面有中文，不過你大概也看不太懂他的中文
繁體中文翻譯翻到我看都看不懂這是他厲害的地方，除此之外，安裝程式作的其實不錯
ok是翻譯成"行"，eject翻譯成"吐出":D
果然跟傳聞中的印象相符，中文不怎麼樣，但其他方面不錯XD
安裝完之後的一些系統設定工具也有gui介面，雖然我還是習慣自己改設定檔，但這些工具作的也滿不錯的，所以可以採用英文介面但正常顯示中文這樣的方式來使用，雖不滿意但還可以接受這樣，美中不足的地方是xcin沒有把酷音輸入法包進去，這部份跟rh一樣
但我想對於英語系國家的使用者來說，suse在各方面都不輸給rh，也難怪suse在歐洲佔有率不錯