FastTrak SX4000/SX4000 lite Motherboard CompatibilityList
Vendor Intel Intel Intel Intel Intel Intel Tyan Tyan Tyan Tyan Tyan Asus Asus Asus Asus Asus Asus Asus Asus Supermicro Gigabyte Gigabyte Gigabyte DFI DFI MSI MSI MSI MSI MSI NEC Model SE7505VB2 SHG2 SE7501HG2 D875PBZLK D845WN D845BG S2721GN-533 S2668ANR S2665ANF S2662AN S2266 P4G8X P4S8X P4C800 P4T533-C A7V266-E/AA A7N8X PR-DLS/U320 A7V333 X5DAL-TG2 GA-8INXP GA-7VAXP GA-7VRXP LanParty KT400A LanParty Pro875 MS-6590 (KT4 Ultra) MS-6570 (K7N2) MS-6330 (K7T Turbo2) 694T PRO MS-6380E(KT3 Ultra) Express5800 120/Ef Chipset Intel E7505 SW GC-LE Intel E7501 Intel i875P Intel i845 Intel i845 Intel E7501 Intel E7505 Intel E7505 Intel E7205 Via P4X266 Intel E7205 SiS 648 Intel i875P Intel i850E SiS 740 nForce2 SW GC-LE VIA KT333 Intel E7505 Intel E7205 VIA KT400 VIA KT333 VIA KT400A Intel i875P VIA KT400A nForce2 Ultra 400 VIA KT133A SiS 694X VIA KT333 SW GC-LE CPU Dual Xeon Dual Xeon Dual Xeon P4 P4 P4 Dual Xeon Dual Xeon Dual Xeon P4 P4 P4 P4 P4 P4 AMD AMD Dual Xeon AMD Dual Xeon P4 AMD AMD AMD P4 AMD AMD AMD P3 AMD Dual Xeon BIOS Type Phoenix Phoenix Phoenix Award Intel Phoenix Intel Phoenix AMI Phoenix Phoenix Phoenix Award Award Award AMI Award Award PhoenixAward Award Award Phoenix Award Award AMI PhoenixAward PhoenixAward PhoenixAward Award AMI Phoenix BIOS Version P02 P05 P01 P07 P12 P06 08.00.07 v1.01 v1.08 v1.06 v6.00PG 1006 1001.G 1009 1.281 v1.10 v6.00PG v6.00PG v2.00 v6.00PG v6.00PG

v3.2 v3.6

Hard disk drive compatibility software FastTrak BIOS: 1.02.0.5 FastTrak Windows Driver: 1.02.0.6 Promise Windows PAM: 4.0.0.22
Errata#1 Invalid system disk when booting to USB floppy disk drive with FastTrak present. Tyan S2721GN-533

1 of 2

Errata#2 LSI 22915A SCSI controller resource conflict with FastTrak SX controller (SCSI cannot boot). SuperMicro X5DAL-TG2 Tyan S2721GN-533 MSI 694T Pro Intel D845WN Errata#3 Adaptec ASC-39320 SCSI controller resource conflict with FastTrak SX controller (SCSI cannot boot). SuperMicro X5DAL-TG2 NEC Express5800/120ef Server Asus A7N8X Tyan S2662AN MSI MS-6330 (K7T Turbo2) MSI MS-6730 (655MAX)
All information contained herein is for information only, and is provided "as is" with no warranties whatsoever, including any warranty of merchantability, noninfringement, fitness for any particular purpose or any other warranty otherwise arising from it. Promise Technology, Inc. disclaims all liability for any errors or omissions. This compatibility list does not imply endorsement of a particular 3 rd party product by Promise Technology, Inc. Due to the wide variety of system configurations, Promise Technology, Inc. cannot guarantee that a specific device will work properly on your system. Each user must make their own determination as to which third-party products are appropriate for their individual need. Users should back up their computer or otherwise save important data before installing any Product and continue to back -up their important data regularly.

2 of 2

D u r i n g t h e m a s t e r s p r o g r a m at

Jarle Bjrgeengen

Puppet and Cfengine compared: time and resource consumption
Jarle Bjrgeengen has been working with UNIXes, storage, and HA clusters for about a decade. He is now a masters student at Oslo University College, and works for the UNIX group of the central IT department (USIT) of the University of Oslo. jarle.bjorgeengen@usit.uio.no
Oslo University College, I was required to define and carry out a set of scientific experiments. As both graduate student and member of a project evaluating configuration management tools for the University of Oslos IT department [9], I was looking for an experiment that would serve both of these roles. The project was about evaluating Cfengine [3] and Puppet [5] against our existing script-based solution.
My experiment needed to fulfill the criteria of scientific measurability and bringing a new and valuable approach to the decision-making process. I chose to compare time and resource consumption in Puppet and Cfengine 3 tools when carrying out identical configuration checks and actions. This would be useful information to have for a tool to be used on a large scale, since the time and resources used limit the scope of managed configuration during a certain period. Time usage for the state compliance verification process is of particular interest, since it will affect the frequency and/or scope of the configuration verified.

Equipment and Tool Setup

The experiment was run on a PC with the following specifications:
CentOS 5.2 , 2.6.18-92.1.22.el i686 MSI MS-6380E (VIA KT333 based) motherboard 1024 MB RAM AMD Athlon XP2200 (1.8GHz / 266MHz FSB) 256KB cache Quantum fireball 7200 rpm / 30GB / 58169 Cyl / 16 Head / 63 sectors
In both tools it is the configuration agent that does the job of converging to desired state. In Puppet a server component is mandatory, since it is the server that provides the agent with its configuration. The latest stable version of Puppet at the time the experiment was done was version 0.24.7 and that is the version used in the experiment. Cfengines configuration agent is independent of a server component, but can be configured to be used with a server component if desired. Cfengine version 3.0.1b3 was downloaded and was compiled according to the installation part of the reference manual [2].
; L O G I N : VO L. 3 5, N O. 1
Installing Puppet is easy on CentOS 5 using the EPEL [1] yum repository.
# rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm # yum install puppet # yum install puppet-server # service puppetmaster start # chkconfig puppetmaster on
This also automatically resolves and installs the dependencies needed for Puppet to work (ruby-libs, ruby, facter, ruby-shadow, augeas-libs, rubyaugeas). Installing Cfengine 3 took a bit more effort: Dependencies:
# yum install db4-devel # yum install byacc # yum install openssl-devel # yum install flex # yum install gcc

Cfengine:

# wget http://www.cfengine.org/downloads/cfengine-3.0.1b3.tar.gz # tar zxvf cfengine-3.0.1b3.tar.gz # cd cfengine-3.0.1b3 #./configure && make && make install && cp /usr/local/sbin/cf-* /var/cfengine/ bin/

Methodology

The workload chosen for the measurements reflects comparable activities of a configuration management tool. There are three main categories of work:

File permissions File contents /etc/hosts entries
The host entries measurement differs a little bit from the file permission and file content workloads. This is because, in Puppet, host entries means a special type of resource, which ends up as file edits to the /etc/hosts file in the end. In Cfengine this is just one form of file-editing operation directly in the configuration language. This difference might make the /etc/hosts entries workload less directly comparable than the file permission and content workloads. Each type of work was measured in two ways: 1. With a known deviation from the tools configuration applied up front. Hence the tool will need to converge the deviation to compliance. 2. With the tools configuration applied up front. Hence the tool will do verification only. This expands to six measurements for each tool, and each measurement was repeated 40 times. All measurements and application of preconditions for each measurement were done in a shell script which ran the same measurements 40 times. All workload combinations measured are summarized in the following table:
; L O G I N : F e b rua ry 1 0
P u pp e t a n d C f e ngin e Co m pa r e d

No. 11 12

Type Permissions Permissions Content Content Hosts records Hosts records Permissions Permissions Content Content Hosts records Hosts records
Converge or Verify Converge Converge Converge Converge Converge Converge Verify Verify Verify Verify Verify Verify
Tool cf3 puppet cf3 puppet cf3 puppet cf3 puppet cf3 puppet cf3 puppet
configfile cf3-perms.cf puppet-perms.cf cf3-content.cf puppet-content.cf cf3-hosts.cf puppet-hosts.cf cf3-perms.cf puppet-perms.cf cf3-content.cf puppet-content.cf cf3-hosts.cf puppet-hosts.cf
Each amount of work was scaled up such that it was possible to actually measure some resource and time consumption for both tools. For the file permissions and file content tests, a file tree with known content and permissions was created under a test directory /var/tmp/file_tests. The test file tree was made each time as follows:
TESTDIR=/var/tmp/file_tests if [[ -d $TESTDIR ]] then rm -rf $TESTDIR fi for i in `seq 1 10` do mkdir -p $TESTDIR/dir_$i for j in `seq 1 10` do echo Some testline > $TESTDIR/dir_$i/file_$j done done
Run as root, this creates directories with ownership root:root and mode 755 and files with ownership root:root and mode 644. For the file permissions, the tools work was to converge from the default permissions to ownership root:bin and mode 755 for all files and directories. Heres the Puppet configuration for applying file permissions (puppet-perms. cf):
class fix_perms { file { /var/tmp/file_tests: owner => root, group => bin, mode => 0755, recurse => inf, backup => false, } }

18 ; L O G I N : VO L. 3 5, N O. 1
node localhost { include fix_perms }
And heres the Cfengine configuration for applying file permissions (cf3-perms.cf):
body common control { bundlesequence => { perms }; } bundle agent perms { files: /var/tmp/file_tests/ pathtype => literal, perms => passthrough(0755,root,bin), depth_search => recurse(inf); } body depth_search recurse(d) { depth => $(d); } body perms passthrough(m,o,g) { mode => $(m); owners => { $(o) }; groups => { $(g) } ; }
For file content, the tools work was to ensure some particular content in the same files. Heres the Puppet configuration for applying file content (puppet-content.cf):
class fix_contents { file { /var/tmp/file_tests: content => Trallala\n, recurse => inf, backup => false, } } node localhost { include fix_contents }
And heres the Cfengine configuration for applying file content (cf3-content.cf):
body common control { bundlesequence => { content }; } bundle agent content { files:
/var/tmp/file_tests/.*/.* edit_defaults => no_backup, edit_line => en_liten_trall; } bundle edit_line en_liten_trall { delete_lines: .*; insert_lines: Trallala; } body edit_defaults no_backup { edit_backup => false; }
For host entries, the tools work was to ensure that all specified host-to-IP mappings were present in /etc/hosts. Heres the Puppet configuration for applying host entries (puppet-hosts.cf):
class my_hosts { host { private1.localdomain.com: ip => 10.0.0.1, ensure => present, } host { private2.localdomain.com: ip => 10.0.0.2, ensure => present, } (.) host { private254.localdomain.com: ip => 10.0.0.254, ensure => present, } } node localhost { include my_hosts }
And heres the Cfengine configuration for applying host entries (cf3-hosts.cf):
body common control { bundlesequence => { hosts }; } bundle agent hosts { vars: my_hosts slist => { 10.0.0.1 private1.localdomain.com, (.)
10.0.0.253 private253.localdomain.com, 10.0.0.254 private254.localdomain.com
20 ; L O G I N : VO L. 3 5, N O. 1
}; files: /etc/hosts edit_defaults => no_backup, edit_line => host_ensure(@(hosts.my_hosts)); } bundle edit_line host_ensure(record) { insert_lines: $(record); } body edit_defaults no_backup { edit_backup => false; }
When measuring verification time, the script converged configuration of the tool before taking the measurements. This way it is unlikely that the precondition is anything other than the desired state in the tool configuration; hence the measured values when doing this are verification only. Application of the configurations with Puppet was done like this:

/usr/sbin/puppetd --no-daemonize --onetime
Application of the configurations with Cfengine was done like this:
/var/cfengine/bin/cf-agent --no-lock
To have as close to equal starting points as possible for the tests, all block device buffers were dropped before each test by using:
sysctl -w vm.dropcaches = 3

The Scientific Method

When measuring alternatives there will be uncertainty in the measurements. The uncertainty is defined as error, or noise. The total error was quantified using repeated measurements and statistical methods for finding the confidence intervals of the differences between alternatives. Confidence intervals of the differences comes with a probability of the true value being inside the interval. For the confidence interval to have any utility, the probability that the true value is inside the interval must be high. Higher probability widens the confidence interval, and vice versa. A commonly chosen value of this probability is 0.95. If confidence intervals of the two alternatives overlap, it is impossible to say that the difference is not caused by random fluctuations. If they dont overlap, there is no evidence to suggest that there is not a statistically significant difference. The chosen probability quantifies the certainty of being right in assuming there is a true difference [10, p. 43].
Plotting the values shows random variations, but the true standard deviation of the underlying population is not known. The students t distribution takes this into account and is commonly used for detecting statistically significant differences between two alternatives [8]. The students t distribution, or more precisely the t-test, was used to identify any statistically significant differences in the experiment results. The tool gnu time [4] (version 1.7 release 27.2.2) was used for measuring time and resource consumption of each operation. For each measurement, three metrics were logged:
Total time used Number of CPU seconds (system + user) Number of involuntary context switches
The values were logged in semicolon-separated files, one for each $measurement-$tool containing 40 lines of data. Each column of measurements then represents one metric (time, CPU, or CSWITCH) measurement repeated 40 times. These vectors were used for calculating sample means and confidence intervals using the free statistic program R [6]. For all 12x3 metrics, the t-test functions of R were used to compare pairs of vectors of 40 numbers, each representing the measured values of each tool, respectively. The outcome of each comparison is the sample mean of the difference between vectors and its confidence interval given a certain probability that the true value is within the interval. The probability used for the tests was 0.99, meaning there is 99% probability that the true value of the sample mean of the differences is within the confidence intervals produced by the t-tests. All t-tests were done as follows:

diff = t-test(puppet_vector,cfengine_vector,conf.level = 0.99)
and the return values are fetched out as follows in R:
c(diff$estimate[1],diff$estimate[2],diff$conf.int[1],diff$estimate[1] diff$estimate[2] , diff$conf.int[2])
The five values produced from the two statements above correspond to columns 37 in the results table.

Results

The output of the eighteen t-tests in R is summarized in the following table. Table legend: 1. Type of workload: Permission/Content/Host Converge/Verify 2. Resource/time measurement 3. Sample mean value for Puppet 4. Sample mean value for Cfengine 5. Start of the confidence interval of the sample mean difference (C1) 6. Sample mean difference 7. End of the confidence interval of the sample mean difference (C2)
Workload Permissions conv. Content conv.e Hosts conv. Permissions ver. Content ver. Hosts ver. Permissions conv. Content conv. Hosts conv. Permissions ver. Content ver. Hosts ver. Permissions conv. Content conv. Hosts conv. Permissions ver. Content ver. Hosts ver.
Measurement Execution time Execution time Execution time Execution time Execution time Execution time cpu seconds cpu seconds cpu seconds cpu seconds cpu seconds cpu seconds forced cswitch forced cswitch forced cswitch forced cswitch forced cswitch forced cswitch
Puppet mean 14.80s 14.85s 28.44s 14.28s 14.32s 21.52s 11.03s 11.03s 10.50s 11.04s 11.03s 17.97s 1967 3186
Cf. mean 1.18s 1.43s 1.21s 1.25s 1.23s 1.11s 0.24s 0.36s 0.32s 0.23s 0.34s 0.32s 160 159
C1 13.54s 13.24s 26.19s 12.82s 12.92s 20.30s 10.77s 10.64s 10.16s 10.78s 10.67s 17.61s 1708 2913
Mean difference 13.63s 13.42s 27.23s 13.04s 13.09s 20.41s 10.79s 10.67s 10.18s 10.8s 10.69s 17.65s 1808 3027
C2 13.72s 13.6s 28.27s 13.25s 13.27s 20.53s 10.81s 10.69s 10.19s 10.8s 10.72s 17.68s 1907 3142
The following graphs are produced by the package Sciplot [7] in R. The error bars show the 99% confidence interval of each sample mean.
F i g u r e 1 : T i m e u s a g e fo r t h e s i x t a s k s
F i g u r e 2 : C P U s e co n d s u s e d
F i g u r e 3 : N u m b e r of i n vol u n t a r y co n t e x t s w i tc h e s

Conclusion

The results show that Puppet uses considerably more time and resources than Cfengine3 for all the measurements included in the experiment. Time and resource usage is important, particularly in the verification phase. Verification is done every time the agent runs, regardless of compliance. The maximum frequency of verifications will be affected by time usage for each verification. The scope of the verified configuration in the experiment is small compared to what can be the case in real production environments. Clearly, time usage of verifications will limit the frequency of verifications when the scope increases. Generally it is also desirable to have low resource consumption on administrative processes that run regularly, both from an environmental and from a capacity point of view.

The experiment shows that usage of Puppet involves a major tradeoff with respect to time and resource consumption compared to Cfengine3 for the operations that were measured. Of course, there are many factors to consider when choosing configuration management tools. The differences of time and resource consumption might be ignorable to some. The results of this experiment serve as a supplement, broadening the understanding of the differences between these two popular configuration management tools.

references

[1] http://fedoraproject.org/wiki/EPEL. [2] http://www.cfengine.org/manuals/cf3-reference.html. [3] http://cfengine.com/pages/whatIsCfengine. [4] http://www.gnu.org/software/time/. [5] http://reductivelabs.com/products/puppet/. [6] http://www.r-project.org. [7] http://cran.r-project.org/web/packages/sciplot/index.html. [8] http://en.wikipedia.org/wiki/Students_t-distribution. [9] http://www.usit.uio.no. [10] D.J. Lilja, Measuring Computer Performance: A Practitioners Guide (Cambridge University Press, 2000).