sys_basher

<body topmargin=0 leftmargin=0 marginheight=0 marginwidth=0> <table cellpadding=0 cellspacing=0 border=0><tr> <td valign="top" colspan=2 height=90 BGCOLOR="#CC9900" TEXT="#080000" bgproperties="fixed" background="044005a0dwnjzk.gif"> <div> <B>sys_basher</B></div> <bR> <div> </div> </td> </tr><tr> <td valign="top" width=210 BGCOLOR="#FFFFFF" TEXT="#080000"> <div> <B><IMG SRC="03f69830.gif" border=0 width="105" height="131" ALIGN="BOTTOM" HSPACE="0" VSPACE="0"></B></div> <div> <A HREF="http://www.polybus.com" TARGET="_top" TITLE="http://www.polybus.com"><U><B>Polybus Systems Corp</B></U></A></div> <div> <B>23 Providence Rd</B></div> <div> <B>Westford, MA 01886</B></div> <div> <B>(978) 828-0944</B></div> <div> <A HREF="mailto:bjrosen@polybus.com" TARGET="_top" TITLE="mailto:bjrosen@polybus.com"><U><B>bjrosen@polybus.com</B></U></A></div> <bR> <div> <A HREF="http://www.polybus.com/ib_link_layer_website" TARGET="_top" TITLE="http://www.polybus.com/ib_link_layer_web"><U><B>InfiniBand Cores</B></U></A></div> </td> <td valign="top" height=390 BGCOLOR="#FFFFFF" TEXT="#080000"> <div> <B>Sys_basher is offered free of charge by Polybus Systems corporation under a BSD style open source</B><B> </B><A HREF="id17.htm" TARGET="_top" TITLE="License"><U><B>license</B></U></A><B>.</B></div> <div> Polybus offers Intellectual Property including InfiniBand Link Layer and Transport Layer cores. Polybus also provides FPGA and ASIC design services.</div> <div> Polybus is the leading supplier of InfiniBand cores for use in Xilinx 7 Kintex7/Virtex7 and Altera Stratix V FPGAs as well for ASICs. We offer SDR, DDR and QDR Link Layer and Target Channel Adapter Cores.</div> <div> <A HREF="http://www.polybus.com/ib_link_layer_website" TARGET="_top" TITLE="http://www.polybus.com/ib_link_layer_web"><U>http://www.polybus.com/ib_link_layer_website</U></A>.</div> <bR> <div> If you are looking for FPGA or ASIC design consulting or would like more information about our cores please contact Joshua Rosen <A HREF="mailto:bjrosen@polybus.com" TARGET="_top" TITLE="mailto:bjrosen@polybus.com"><U>bjrosen@polybus.com</U></A>, (978) 828-0944.</div> <bR> <div> Sys_basher is a Linux hardware stress tester and diagnostic. It is designed to place a maximum load on a system by running memory, CPU and disk tests on all cores simultaneously. A typical time to run the full test suite on an iCore7 with 32G of RAM is about 5 hours, however you can increase the test time with the -ho switch, for example if you want to run sys_basher for at least 12 hours specify -ho 12.</div> <bR> <div> The purpose of sys_basher is to determine if a system is reliable under load and to diagnose hardware failures. It's a good idea to run sys_basher on a new system before putting the box into service. For overclockers sys_basher is an excellent tool for finding the limits of your box. </div> <bR> <div> When running sys_basher you should do it on a freshly booted system and you should kill all virtual machines. Sys_basher needs to grab as much of the RAM as possible to do the best possible job of RAM testing which is why you want as little else running as possible. Generally you will want to minimize paging, this is done with the -t switch which reserves a certain amount of RAM for the system. For example if you want to reserve 256M for the system do,</div> <bR> <div> sys_basher -t 256</div> <bR> <div> The number 256 is a good choice for reserved memory, however you can use larger or smaller numbers. Any value > 128 will cause sys_basher to lock the memory so there should be no paging while the program is running. If you suspect that you have a problem in the I/O system you might want to maximize paging, in that case it is recommended that you set the -t value to 0.</div> <bR> <div> As of version 2.0.1 sys_basher can identify individual DIMMs depending on the capabilities of the system's BIOS. Most BIOSs will report the physical memory maps of the individual DIMM which allows sys_basher to localize a memory test failure to a specific DIMM. Unfortunately bad BIOSs that report incomplete DIMM information are not uncommon, in those circumstances you can still run sys_basher but you will have to interpret the failure information yourself. The program dmidecode is used to dump the bios information into a binary file that sys_basher uses to determine DIMM positions. The RPM sets up a script that runs dmidecode on boot up and puts the BIOS information into /var/sys_basher/bios.bin. If you installed from source then you will have to run the script, sys_basher_setup by hand as root (dmidecode requires root privileges to get the DMI tables from the BIOS). You do not need to run sys_basher as root, you should run it as a user program.</div> <bR> <div> To run all tests do,</div> <bR> <div> sys_basher -t 256 >& log &</div> <bR> <div> To run just memory tests do,</div> <bR> <div> sys_basher -t 256 -m >& log &</div> <bR> <div> or</div> <bR> <div> sys_basher -t 256 -m -vv >& log &</div> <bR> <div> If you are trying to diagnose memory problems you may want to use the -vv (very verbose) switch. When the -vv switch thrown sys_basher will run two read passes on every memory tests, if it gets different results on each pass that would indicate that the problem is a read problem rather than an internal storage problem. The most common RAM problems are interface issues, that is to say the DIMM may be incompatible with your motherboard or it can't handle the load when it shares a bus with another DIMM. To determine the type of memory failure you should try the following things,</div> <bR> <div> 1) Reduce the number of DIMMs in the system from four to two (make sure that the two DIMMs are on separate buses, see the user guide for you motherboard to determine this).</div> <div> 2) Swap DIMMs around to see if the errors found by sys_basher move with the DIMM</div> <div> 3) Change the clock speed on the DIMMs. This will be BIOS dependent, generally you can control the DIMM parameters in the Overclocking section of the BIOS. BTW even though most BIOSes will use the term "Overclocking" you can reduce clock rates also (i.e. underclock).</div> <bR> <div> To run just disk tests do</div> <bR> <div> sys_basher -d >& log &</div> <bR> <div> Sys_basher generates a set of log and report files as well as a set of comma separated report files that can be loaded into a spreadsheet. The default file names are,</div> <bR> <div> sys_basher_1_threads.csv</div> <div> sys_basher_2_threads.csv</div> <div> sys_basher_3_threads.csv</div> <div> sys_basher_4_threads.csv</div> <div> sys_basher_5_threads.csv</div> <div> sys_basher_6_threads.csv</div> <div> sys_basher_7_threads.csv</div> <div> sys_basher_8_threads.csv</div> <div> sys_basher_all_threads.csv</div> <div> sys_basher.log</div> <div> sys_basher.rpt</div> <div> sys_basher_summary.csv</div> <bR> <div> The log file is synced after each test so that information is preserved in case of a system crash. The log file records the CPU and system temperatures and the fan speeds which will help to determine if there is a cooling problem. The sensor information comes from lmsensors. The RPM will install lmsensors, if you installed from source then make sure that you have sensors installed. To get a complete set of sensor readings it's a good idea to run lmsensors setup program, sensors_detect. You must run sensors_detect as root and you should accept all of it's defaults.</div> <bR> <div> <B>sys_basher may be downloaded here,</B> (revision 2.0.2, Jan 2, 2015)</div> <bR> <div> <A HREF="http://www.polybus.com/sys_basher/sys_basher-2.0.2-1.fc21.x86_64.rpm" TARGET="_top" TITLE="http://www.polybus.com/sys_basher/sys_ba"><U><B>Fedora 21 RPM</B></U></A></div> <div> <A HREF="http://http://www.polybus.com/sys_basher/sys_basher-2.0.2-1.fc21.src.rpm" TARGET="_top" TITLE="http://http://www.polybus.com/sys_basher"><U><B>Fedora 21 SRPM</B></U></A></div> <div> <A HREF="http://www.polybus.com/sys_basher/sys_basher-2.0.2-1.x86_64.rpm" TARGET="_top" TITLE="http://www.polybus.com/sys_basher/sys_ba"><U><B>RHEL5/CentOS5/SL5 RPM</B></U></A></div> <div> <A HREF="http://www.polybus.com/sys_basher/sys_basher-2.0.2-1.src.rpm" TARGET="_top" TITLE="http://www.polybus.com/sys_basher/sys_ba"><U><B>RHEL5/CentOS5/SL5 SRPM</B></U></A></div> <div> <A HREF="http://www.polybus.com/sys_basher/sys_basher-2.0.2-1.el6.x86_64.rpm" TARGET="_top" TITLE="http://www.polybus.com/sys_basher/sys_ba"><U><B>RHEL6/CentOS6/SL6 RPM</B></U></A></div> <div> <A HREF="http://www.polybus.com/sys_basher/sys_basher-2.0.2-1.el6.src.rpm" TARGET="_top" TITLE="http://www.polybus.com/sys_basher/sys_ba"><U><B>RHEL6/CentOS6/SL6 SRPM</B></U></A></div> <div> <A HREF="http://www.polybus.com/sys_basher/sys_basher-2.0.2-1.el7.x86_64.rpm" TARGET="_top" TITLE="http://www.polybus.com/sys_basher/sys_ba"><U><B>RHEL7/CentOS7/SL7 RPM</B></U></A></div> <div> <A HREF="http://www.polybus.com/sys_basher/sys_basher-2.0.2-1.el7.src.rpm" TARGET="_top" TITLE="http://www.polybus.com/sys_basher/sys_ba"><U><B>RHEL7/CentOS7/SL7 SRPM</B></U></A></div> <div> <A HREF="http://www.polybus.com/sys_basher/sys_basher-1.1.25.tar.gz" TARGET="_top" TITLE="http://www.polybus.com/sys_basher/sys_ba"><U><B>sys_basher-1.1.25.tar.gz</B></U></A></div> <div> <A HREF="http://www.polybus.com/sys_basher/sys_basher-2.0.2.tar.gz" TARGET="_top" TITLE="http://www.polybus.com/sys_basher/sys_ba"><U><B>sys_basher-2.0.2.tar.gz</B></U></A></div> <bR> <bR> <div> <B>SYS_BASHER(1)                    User Commands                   SYS_BASHER(1)</B></div> <bR> <div> NAME</div> <div>        sys_basher - manual page for sys_basher version 2.0.2</div> <bR> <div> SYNOPSIS</div> <div>        sys_basher [OPTIONS]</div> <bR> <div> DESCRIPTION</div> <div>        sys_basher (c)2006-2015 Polybus Systems Corp., Westford, MA, USA</div> <bR> <div>               Sys_basher  is  a  multithreaded  hardware exerciser. Sys_basher</div> <div>               tests CPU, memory and disk I/O reliability.   It  also  measures</div> <div>               low level system performance.</div> <bR> <div>    options:</div> <div>        -d,--disk</div> <div>               Run disk tests</div> <bR> <div>        -dmi filename</div> <div>               DMI  binary  file generated by dmidecode --dump-bin filename The</div> <div>               DMI (BIOS) file allows sys_basher to determine which DIMM is bad</div> <div>               The default DMI file is in /var/sys_basher/bios.bin</div> <bR> <div>        -du,--dutycyle</div> <div>               Dutycycle  n  Duty  cycle in percent, the default is 100 Inserts</div> <div>               Sleeps between tests to reduce the overall CPU duty cycle</div> <bR> <div>        -f,--fast</div> <div>               Skip the memory tests, just run the disk, fp  and  memory  bandâ</div> <div>               width tests.</div> <bR> <div>        -fp,--fp</div> <div>               Run floating point tests</div> <bR> <div>        -h,--help</div> <div>               Print this help message</div> <bR> <div>        -ho #,--hours #</div> <div>               Run for at least # hours.</div> <bR> <div>        -i,--int</div> <div>               Run integer tests</div> <bR> <div>        -l #,--loops #</div> <div>               Number of iterations.</div> <bR> <div>        -mb,--mbandwidth</div> <div>               Run memory bandwidth</div> <bR> <div>        -m,--mem [abprwv]</div> <div>               Run memory tests</div> <bR> <div>        No argument</div> <div>               Run all memory tests</div> <bR> <div>        a      Address = Data tests</div> <bR> <div>        b      Bank tests</div> <bR> <div>        p      Fixed pattern tests</div> <bR> <div>        r      Random data tests</div> <bR> <div>        w      Walking Ones/Zeros data tests</div> <bR> <div>        v      Bit reversed address tests</div> <bR> <div>        -mi,--minutes #</div> <div>               Run for at least # minutes.</div> <bR> <div>        -p n0..nx,--path n0..nx</div> <div>               Directory path(s) for the disk tests, upto 32 paths maybe speciâ</div> <div>               fied. The default path is ./</div> <bR> <div>        -r name,--report name</div> <div>               Report file name, generate name.rpt and name_xx.csv. Default  is</div> <div>               sys_basher.rpt and sys_basher_xx.csv</div> <bR> <div>        -s,--swap</div> <div>               Force use of swap space. This option is incredibly slow.</div> <bR> <div>        -st,--stop</div> <div>               Stop on Error, Exits if error found.</div> <bR> <div>        -t,--totalmem #</div> <div>               Allocate  total  ram - (n * 1M) for testing. If -totalmem is not</div> <div>               called then the free space is used.</div> <bR> <div>        -th #,--threads #</div> <div>               Maximum number of threads. Spawn 1-n threads, the default is the</div> <div>               number of CPUs.</div> <bR> <div>        -ts #,--tstart #</div> <div>               Starting  thread  count, after the initial calibration pass loop</div> <div>               from tstart to threads, the default is 1</div> <bR> <div>        -v,--verbose</div> <div>               Verbose, print detailed results, for memory tests prints address</div> <div>               and  data  info  for  the  first 16 errors, default is PASS/FAIL</div> <div>               only.</div> <bR> <div>        -vv,--vverbose</div> <div>               Very Very verbose, for memory tests run a second check  pass  to</div> <div>               help determine if it's a read or write problem</div> <bR> <div>        -ve,--version</div> <div>               Version</div> <bR> <div>        The  default  is  to  run all tests unless at least one individual test</div> <div>        group is selected.  Report and log files:</div> <bR> <div>               The  default  report  and  log  names  are  sys_basher.rpt   and</div> <div>               sys_basher.log  The  the default name can be overridden with the</div> <div>               -r switch.</div> <bR> <div>        report_name.log</div> <div>               Running log. Syncs are executed after each  test  so  that  this</div> <div>               file can be preserved up to the point of a crash.</div> <bR> <div>        report_name.rpt</div> <div>               Summary report file.</div> <bR> <div>        report_name_#_threads.csv</div> <div>               Comma  separated report files for each thread count. These files</div> <div>               can be read into a spreadsheet.</div> <bR> <div>               RHEL7/CentOS7/SL7 systems have an aggressive  OOM  killer  which</div> <div>               sometimes interferes with sys_basher.</div> <bR> <div>               You  can  disable  the  OOM killer for sys_basher by running (as</div> <div>               root) sys_basher_disable_oom after starting sys_basher</div> <bR> <bR> <bR> <div> sys_basher version 2.0.2         January 2015                    SYS_BASHER(1)</div> <bR> <bR> </td> </tr></table></body>