Hardware Testing/Repair

This probably should often be able to be done rather automatically, and so this documentation is part of the section of tasks that may be performed behind the scenes. For further details about hardware, see section about hardware.

[#tstbrkhw]: WARNING! Tests may damage hardware

Hardware testing can cause permanent damage to hardware. As one example, a note, which is shown in the documentation of the cpuburn utilities, warns about possible “data loss (filesystem corruption) and ” ... “permanent damage to electronic components”. (This may be visible via the Wayback Machine @ Archive.org's archive of the cpuburn Homepage.) The documentation particularly cites “weak systems”, including “Undercooled” and “overclocked” systems, as systems that may experience such problems.

Not all software of this nature contains such a warning, but even those that don't have the warning may still perform actions that may have noteworthy risk of permanent damange.

As another example of such a warning, AleGr MEMTEST states, “There is no guarantee of any kind. On some low-power systems, the program may cause excessive current consumption, and trigger overcurrent protection or cause permanent damage. When the program is run under Windows, it can cause a marginally stable system to crash with possible loss of data or OS damage.”

Some of these tests may cause issues after a test has been running for some time, and possibly on another iteration after the first test is completed. Sometimes the issues may be temporary, at least temporarily (until things worsen and permanent damage ends up resulting). Referring to cpuburn's documentation again, the documentation notes, “If sub-spec, your system may lock up after 2-10 minutes. It shouldn't.” If a problem occurs, it may often be caused by thermal issues or “some other deficiency. A power cycle should reset the system. But you should fix it.”

Note that even if permanent damage does not occur, there may be some other affects to running tests. Most notably, the tests may often utilize hardware fairly fully, resulting in the hardware being less available for other tasks. For instance, doing a speed test on networking equipment may result in heavily bandwidth utilization, causing the same hardware to be able to provide less effective speed for other network traffic.

[#mlthwtst]: Multiple component testing

No strong recommendations of specific software are being made. Here may be some options broken down by operating system. (This may currently be very preliminary. There certainly may be additional options than what is currently mentioned in this section.)


There are some customized operating system distributions that are designed to test hardware. Some of these software solutions may test multiple components simultaneously. Often, the software contained in these distributions may be readily available to be used in other distributions as well. For details about these distributions, see: operating systems for testing systems

Microsoft Windows
AleGr MEMTEST version 2.00 (information about running the software in Microsoft Windows) is a memory tester that also mentions testing the disk, in the section of documentation about running the program under Windows. (It very well might be true that this software might not support that same functionality in other environments.)
Specific testing software

The program called “stress” is for POSIX.

Software called stress may test multiple components.

Perhaps this program was where StressLinux got its name, as that operating system does come with this software called stress or perhaps the operating system distribution's name was just meant to reference the general concept of stress, rather than this software. (There is available documentation about the StressLinux operating system.) Regardless, it does seem likely that this program was named after the concept of stressing out hardware.

One option is to run stress --help which will show an example command:

stress --cpu 8 --io 4 --vm 2 --vm-bytes 128M --time-out 10s

The program will output very little. To see much more output, add a -v switch. An example couple of command lines may be:

stress -v -c 8 -i 4 -m 2 --vm-bytes 128M -t 10s echo $?
nbench (Linux/Unix benchmark)

This software is included in StressLinux.

Threaded I/O tester (tiobench)
Threaded I/O tester (project page at SF.net)
Checking a disk
[#isdiskok]: Disk reliability

The task of checking a disk was large enough to be its own section.

Disk speed

No strong recommendations of specific software are being made. Here may be some options broken down by operating system. (This may currently be very preliminary; far from complete. There certainly may be better options than what is currently mentioned in this section.)

Bonnie++ is described, by its home page, as “a benchmark suite that is aimed at performing a number of simple tests of hard drive and file system performance.”
[#ramtest]: RAM testing
Testing memory while the operating system is running

This approach can seem more convenient than stand-alone testers, especially with modern operating systems since multitasking allows the computer to perform additional tasks (including additional hardware testing). However, this approach might be less thorough: if the memory tester only checks segments of RAM provided by the operating system, and if the operating system does not provide access to all of the RAM, then the test of the memory may be more limited using this approach.

Historically, the operating systems have been treated like a boss of the computer. Memory testers would be subject to the whims of the operating system like any other program. Hopefully, as time progresses, operating systems will start to support cooperating with tasks (like memory testing, and replacing/upgrading the memory manager without requiring rebooting) that may have a legitimate need to move the operating components (like the memory manager and the kernel) to different segments of memory. If an operating system does not provide that sort of flexibility, then more thorough testing might be available using a stand-alone tester. So, in such cases, using a stand-alone tester may really be more more likely to find a problem that may exist.

(However, memory testing done within an operating system might be able to find some problems, and may be far more convenient to start pulling off on a scheduled basis. Starting such a scan may be an early troubleshooting step that can be performed during other troubleshooting. This sort of memory test may be able to be started, and then be running for some time, before a convenient opportunity to shut down the running operating system and leaving that operating system in a non-running state for some time as the memory is tested.)

Memory testing in Unix

Software, generally available as a downloadable package, called memtester may perform this sort of functionality.

Memory testing in Windows
[#alegrmem]: AleGr MEMTEST version 2.00

This software may run while Microsoft Windows is running.

AleGr MEMTEST version 2.00 notes, “The MEMTEST version 2.0 program is free for personal (non-business) use. For business use, send email to alegr@earthlink.net for information about buing a licence and support. Source code can also be purchased.”
This is one of the hardware testing software offerings which had documentation that included a warning about problems including “permanent damage”.
AleGr MEMTEST states, “Maximum size of memory the program is able to test is 3 gigabytes under DOS and less than 2 gigabytes under Windows. If you have 4 GB or more, you can start several test sessions under Windows, to cover all the memory.” The page also notes, “The program cannot test less than 8 megabytes.”

AleGr MEMTEST states (when discussing running under Windows): “Max total allowed memory size is about 2000 MB.” This may be done with:

memtest.exe /mem:1024 /mem:976 /re /log:+memtest.log

This software is linked to from (English web page for) Utilities (web page by Uwe Sieber). Uwe Sieber has become a memory master! Key evidence of this is his memory manager which had chipset-specific support continually added over time.

Memory testing in DOS
[#alegrmmd]: AleGr MEMTEST version 2.00
This software may be started from within DOS. Command line parameters may differ from running within Windows. Once the test is started, the program offers no way to quit the software (so the system will need to be restarted to become useful again). For further information, like licensing and limits, see AleGr MEMTEST version 2.00 (information about running the software in Microsoft Windows). The home page for the software provides information about the syntax to use to start running this from within DOS.
Stand-alone memory testing

This software does not require starting an operating system before running any of the test(s).


At one time, it seemed that Memtest86+ was getting updated much more often that the older Memtest86 software, which just wasn't getting updated hardly at all. Since then, Memtest86 has released some more updates. Both projects have a published history that credits the other project as being the source of an improvement, so there may currently be some less distinction between the two.

If in doubt, using Memtest86+ may have one key advantage: the claim of the developer(s) to have access to lots of new types of motherboards to assist with ensuring compatibility.

[#memts86p]: Memtest86+

Memtest86+ (“An Advanced Memory Diagnostic Tool”, according to the main page), was based on the Memtest86 program and may support newer hardware. Running this software involves executing specific boot code during the system's boot sequence (using a floppy disk, bootable CD, or USB ???).

Memtest86+ history explains that “the chief-editor of a french hardware website (www.x86-secret.com” which is “now integrated into www.canardpc.com)” has “access to lot of recent hardware and” “can test and debug on quite all available motherboards on the market.”

The first version was based on memtest86 v3.0 but had a lower version number. As an example, Memtest86+ v2.11 (which is not the newest version) is newer than memtest86 v3.0. So comparing the version numbers of these projects, which have been developed separately, is not likely to be useful. Memtest86+ may show a plus sign with the blink/bright text attribute enabled.

For further details, check out the documentation online for this program, or read about Memtest86 which is similar.

In NetBSD, the package name for this is memtestplus.

The “Memory test” options on an Ubuntu install CD may run Memtest86+.


Running this software involves executing specific boot code during the system's boot sequence (using a floppy disk, bootable CD, USB ???, or a partition loaded by a boot manager). It may output errors in a format that is usable by the Linux BadRAM patch which allows portions of the memory chip (which might still be good) to be used. (The information provided for use with the Linux BadRAM patch may be system-specific, with numbers that will not work with other systems that may access RAM differently due to chipset differences (and possibly other things???)).

[#wmemdiag]: Microsoft Windows Memory Diagnostic/Tester (Tools)

Microsoft Windows may come with some software. The installer for such software may be run from within Microsoft Windows, but then the test is done when Windows is not running. In Windows Vista, the installer may be launched using an icon within Administrative Tools: The name of the icon may be “Memory Diagnostics Tools” and may run “ %SystemRoot%\system32\MdSched.exe ”.

The downloadable copy of Windows Memory Diagnostic/Tester (Tools) (as archived by the Wayback Machine @ Archive.org) may be found from a hyperlink found on Online Crash Analysis web page about Windows Memory Diagnostic, Archived from the Online Crash Analysis site, by the Wayback Machine @ Archive.org.

The Windows Memory Diagnostic/Tester (Tools) installation program allows one to read and/or save and/or reject the EULA (which, in a download obtained by Microsoft in late 2009, said all copies of the software must be destroyed upon termination which happens no later than 2003) and/or accept the EULA. Accepting allows one to create a floppy disk image or bootable CD image so the actual testing software may later be started.

Technet's “Free Utility: Windows Memory Diagnostic” page discusses the software a bit further.

Windows Memory Diagnostic (Scheduler)

You may press F1 during the test to set options.

Event viewer results may include:

  • Event 1101, Information, MemoryDiagnostics-Results (“The Windows Memory Diagnostic tested the computer's memory and detected no errors”)
  • Event 1102, Error, Microsoft-Windows-MemoryDiagnostics-Results (“The Windows Memory Diagnostics Tool tested the computer's memory and detected hardware errors. To identify and repair these problems, contact the computer manufacturer”) e.g. report from http://forum.corsair.com/v3/showthread.php?t=75438
  • Event 1201, Information, MemoryDiagnostics-Results (“The Windows Memory Diagnostic tested the computer's memory and detected no errors”)
  • Event ID 1201 indicates that the memory test ran. It doesn't indicate results.
  • Event 6013, Information, MemoryDiagnostics-Results

You may also get a disappearing “balloon” message from the “system tray”/“message notification area” upon success, or a pop-up in case of failure (based on here). The disappearing balloon message on success may take a few minutes to appear.

Using a RAM drive

Some operating systems support what MS-DOS calls a “RAM drive”. (Unix filesystems may use another term, such as “memory filesystem” (“mfs”).) One option, which may not be the best (due to possibly being less than 100% thorough, but which might effectively accomplish the goal for much of the RAM) may be to allocate huge amounts of memory for a “RAM drive”/“memory filesystem”, and then perform disk testing

Responding to bad memory

If your computer is going to store data that you care about, which is the case for most desktops that people use, then, by all means, replace the memory. The strongest consensus seems to be that a bad memory stick may be rather prone to having physical damage spread, causing more bad sectors.

However, if the memory may be used in a computer where bad bits are tolerable, it might still be usable. The best example I've heard is a computer that outputs streaming video. Chances are that the bad memory might cause a pixel to be an incorrect color. With some displays showing over a million pixels per frame and 25-60 frames per second, a single bad pixel may truly be unnoticeable.

However, for a computer that is ever used for keeping track of information, including fincancial figures, or even printing documents that you want to be free of errors, just don't risk it. Even short term usage is unrecommended, because incorrect data could be written to the disk, and that incorrect data could include long term damage. For instane, a filesystem could be corrupted. So, just remove a bad memory stick as soon as possible.

There is some possibility that the memory sticks are fine and so are the memory slots on the motherboard. Errors can creep up due to a bad connection, which may be due to oxidization. Simply removing and re-inserting the memory chips may truly fix the issue. However, in practice that seems rare.

Usually the issue is with the memory sticks, not the motherboard.

Unfortunately, there is typically no surefire way to be able to tell which component is causing the issue without further testing. There is enough difference in memory mapping controller components that computers with different motherboards and/or memory stick models (or perhaps even CMOS settings?) might even have the same amount of memory, but could still have that bad memory address being used on one memory slot for one computer, and a different memory slot on a different computer.

Once you've figured out which memory stick seems likely (by still having errors when other memory sticks are removed), the recommendation is to permanently remove that memory stick. (Then test memory again to confirm that no errors seem to remain.) However, if you really which to tinker with using the memory anyway, there is the Linux BadRAM kernel patch, or for Microsoft Windows, there is the GPLv3'ed BadMemory driver.

Network speed/reliability testing
[#netspeed]: Speed testing

This may currently be partially, but not fully, redundant with another section about checking network speed.

No strong recommendations of specific software are being made. Here may be some options broken down by operating system. (This may currently be very preliminary; far from complete. There certainly may be better options than what is currently mentioned in this section.)

The following might be useful in helping to measure speed: uploading/downloading files (perhaps with file transfer software, Using pv in Unix, NirSoft Download Speed Tester, Speedtest.net (speed tester that uses Flash) and/or Speakeasy.net speed test

Note that all of those techniques may measure what the currently available effective speed is. They measure communications between two points. Slowness may be the result of a remote problem, rather than on-site equipment. This is different than testing what currently used bandwidth is.

For measuring bandwidth, perhaps logs of a firewall, or other routing device, may be a sensible point to measure used bandwidth? The following may also be some sort of option(s) that may work:

Software for Unix
nepim - network pipemeter
May help to measure bandwidth. nepim - network pipemeter: section about supported platforms says, “nepim has been tested under Linux, Solaris and FreeBSD, though it should work under other platforms as well.”
The Netperf Homepage (at http://www.netperf.org/netperf/NetperfPage.html) may be an option.
[#iperf]: Iperf
Command line

iperf3 FAQ states, “As of this writing (2017), both iperf2 and iperf3 are being actively (although independently) developed.” “iperf3 is not officially supported on Windows, but iperf2 is. We recommend you use iperf2.” “Some people are using Cygwin to run iperf3 in Windows, but not all options will work.”

FAQ: binary distributions has some hyperlinks for getting the software.


iperf3 is available for multiple platforms, including Cygwin, from iPerf downloads. (Get a file that has a version number starting with 3 if you want to use iPerf3.) One great benefit of iPerf3 over older iPerf versions is that there are some known publicly available iPerf3 servers.

  • Without parameters, iperf3 shows help.
  • To use a public server:
    iperf3 -c iperf.he.net -V -u -b 0 -k 2k -p 5201 --get-server-output
    • -c specifies to act as a client. (Use -c or -s.)
    • Right after -c, specify the server name
    • -V specifies verbose
    • -b specifies bandwidth-testing mode. It requires a parameter: 0 (zero) specifies to not be limited.
    • The optional -u specifies to use UDP instead of the default of TCP
    • -k specifies to test for a certian number of blocks/packets/datagrams/segments/whatever. 2k means 2000 blocks/packets/datagrams/segments/whatever.
    • -p 5201 specifies the either the TCP port number or the UDP port number (naturally, depending on which protocol is being used).
    • --get-server-output shows more output
  • To run your own server:
    iperf3 -s -V -1 -p 5201

    The -s specifies to run as a server. The -V specifies to run verbosely. The -1 (that is a one, not a lowercase L) specifies to only allow one connection (and then exit once that connection is done). The default is to listen to TCP and UDP ports 5201. There doesn't seem to be a command line parameter that specifies whether to listen for only TCP or only UDP ; the server will respond to either type of connection (if the traffic reaches the server; of course a firewall could affect whether such traffic reaches the server.)

iPerf download page states, “Source of the IPERF 3 project can be found at https://github.com/esnet/iperf”.

iperf2 and iperf
  • Without parameters, iperf shows minimal help, including mentioning that using “iperf --help” shows more help.
  • Running as a client:
    iperf -c -u
    • -c specifies client mode. The next parameter should be a system to connect to. (Using an IPv4 address seemed to work better than a DNS host name... possibly just because IPv4 worked better than IPv6?)
    • -u specifies UDP
  • Running a server:
    iperf -s -u -C -p 5001
    • -s specifies server mode
    • -u specifies UDP
    • -C increases compatibility with older servers. It is incompatible with -d (--daultest), although -d didn't seem to work very well anyway (tested on Microsoft Windows). If used on a server, and if the client is using the -X option (introduced with version 2.0.10), the client will report “(server version is old)”.
    • -p 5001 specifies which TCP port number or UDP port number will be listened to. (That entire parameter is shown as an example, but is unnecessary because 5001 is the default.)

iPerf download page identifies the project home pages. They can be reached at IPERF 2 project page and IPERF (1) project page.

An article about system performance mentions “iperf -s”.

Graphical front-ends available
Graphical front-ends, which use Java, may include: JPerf and xjperf

StressLinux software provides a list of some software, some of which may be software that may test multiple components. (At least some of the software in this list may have been discovered by looking at the list of software used by StressLinux.) For further details on StressLinux and similar software, see system testing.

If network speed does not seem up to par, perhaps see also: network troubleshooting.

A related standard: RFC 2544: “Benchmarking Methodology for Network Interconnect Devices” utilizes the 198.18/15 address range.

Software for Microsoft Windows
Overview, & different modes

The PsPing home page (@ TechNet) says “PsPing implements Ping functionality” (which essentially means using ICMP to check reliability and to perform a speed test), “TCP ping, latency and bandwidth measurement.”

Those are different 5 modes of the program. The official documentation doesn't seem to use the word “mode”, unlike the Unix vi command which is very famous for having different “modes” which are part of the official documentation. The usage of the word “mode” was chosen by the author of this documentation, as this seemed to describe how the program operates. PsPing does different things based on which “mode” the program is using.

Running PsPing with invalid parameters, including with no parameters, will display the most basic help screen. The -? parameter specifies that the next parameter will determine what help screen to show. The main help screen specifies that you can run “PsPing -? i” for details about the parameters that the program uses when it uses “ICMP ping”, or the letter after the space following the -? could be “t to specify details about how the program operates when it uses “TCP ping”, “t to specify details about how the program operates when performing a latency test, and “b to specify details about how the program operates when it performs bandwidth testing.

One might think that these letters are used to specify the mode of the program. For instance, a person might think that i or -i might be used to specify the program's ICMP test mode.

That would be incorrect. The only place where i is documented as specifying ICMP ping is as a required second parameter to the -? parameter. So, in this case, using i identifies which help will get shown. However, when the program is not showing help, trying to use i to specify “ICMP ping” is invalid and likely to cause the program to recognize an invalid syntax (and show help). The -i parameter has a different meaning depending on what mode the program is in. So, that is not how the program determines what mode to use.

There doesn't seem to be a single parameter that completely identifies what mode the program will use. Instead, the program seems to determine the mode by intelligently looking at one or more of the parameters, as needed.


The following shows using the WebDAV client built into Microsoft Windows.

net start WebClient
:: ICMP Test is coming up next
\\live.sysinternals.com\Tools\psping.exe -accepteula -l 8k -n 15 -i 0 -h 16 -w 0 example.com -nobanner
:: TCP Latency Test is next
\\live.sysinternals.com\Tools\psping.exe -accepteula -l 32k -n 15 -h 13 live.sysinternals.com:80 -nobanner
:: (TCP) Bandwidth Test is next
\\live.sysinternals.com\Tools\psping.exe -accepteula -b -l 32k -n 15 -h 13 live.sysinternals.com:80 -nobanner
  • Outgoing web proxies can break this. If that seems to be a problem, you may want to try some other protocols, like a public TELNET server.
Sample output

(This sample output has not yet been fully formatted here...)

C:\> psping.exe -accepteula -b -l 32k -n 15 -h 13 live.sysinternals.com:80

PsPing v2.10 - PsPing - ping, latency, bandwidth measurement utility
Copyright (C) 2012-2016 Mark Russinovich
Sysinternals - www.sysinternals.com

Setting warmup count to match number of outstanding I/Os: 8
TCP bandwidth test connecting to Connected
23 iterations (8 warmup) sending 32768 bytes TCP bandwidth test: 1199326100%


Bandwidth       Count

C:\>psping.exe -accepteula -b -l 32k -n 15 -h 13 live.sysinternals.com:80

PsPing v2.10 - PsPing - ping, latency, bandwidth measurement utility
Copyright (C) 2012-2016 Mark Russinovich
Sysinternals - www.sysinternals.com

Setting warmup count to match number of outstanding I/Os: 8
TCP bandwidth test connecting to Connected
23 iterations (8 warmup) sending 32768 bytes TCP bandwidth test: 1199326100%

TCP sender bandwidth statistics:
  Sent = 15, Size = 32768, Total Bytes: 720896,
  Minimum = 479.95 KB/s, Maximum = 641.60 KB/s, Average = 923.96 KB/s

Bandwidth       Count
491470.94       2
505264.97       0
519059.03       0
532853.06       0
546647.13       0
560441.13       0
574235.19       0
588029.25       0
601823.25       0
615617.31       0
629411.38       0
643205.38       2
656999.44       1

C:\>psping.exe  -b -l 32k -n 15 live.sysinternals.com:80 -nobanner
Setting warmup count to match number of outstanding I/Os: 8
TCP bandwidth test connecting to Connected
23 iterations (8 warmup) sending 32768 bytes TCP bandwidth test: -1749438100%

TCP sender bandwidth statistics:
  Sent = 15, Size = 32768, Total Bytes: 720896,
  Minimum = 479.83 KB/s, Maximum = 921.24 KB/s, Average = 921.24 KB/s

(Hmm... two highly questionable averages, when comparing to the minimum and maximum.)
Possible bugs?

At the time of this writing, this seemed worth noting, even though some of this may not have been completey verified yet.

Invalid interpretation of replies
Claimed here: https://forum.sysinternals.com/psping-misinterprets-router-replies_topic28619.html says that a site which was getting “Destination host unavailable” was reporting as valid responses, so 0% loss. (ping seemed to have the same problem.)
Invalid numbers
Averages cannot equal maximums when the minimum is smaller.
  • During a bandwidth test, some text may seem to be overwritten? (By the progress indicator.)
  • There may not be a space reserved before the percentage, so reaching 100% may mix with earlier numbers (appearing to be a very large number.)
Analyzing different modes/parameters

Following are some ways the program probably does this. (This is based on observation, rather than something found in official documentation.)

-s specifies server mode

The help screen for “latency usage” (specified with “-? l”) and the help screen for “bandwidth usage” (specified with “-? b”) both specify the exact same syntax for having the program operating as a “server”.

Note that the rest of this commentary on server mode is speculation. The support command line syntax probably means that PsPing simply operates in server mode when -s is used, and when PsPing is in that mode, it supports either type of test, so the command line doesn't need to be used to specify any soft of difference between “latency test” mode or “bandwidth test” mode. (Either there is no difference between such modes, because the server simply supports them both, or the server figures it out based on incoming network traffic.)

Specifying ICMP ping

ICMP ping is the only option that doesn't involve TCP or UDP. When TCP gets used, a TCP port number is required. When UDP is used, a UDP port number is required. So PsPing probably checks the remote system, and if it looks like there is a colon and a port number, then the program doesn't use “ICMP ping” mode. If the program doesn't recognize a colon followed by a port number, then the program does use the “ICMP ping”.

Determining this seems potentially error-prone if an IPv6 address is used, but would be more straightforward if specifying an IPv4 address or a DNS name.

-b specifies bandwidth testing

-b specifies bandwidth testing. The only differences between the documented parameters shown by the “latency test” help screen and the “bandwidth test” help screen are the “bandwidth test” mode having the -b option and the “bandwidth test” mode also having the -i option. However, -i is also used by “ICMP ping” mode, so checking for the presence of -b is probably the easier way for the program to recognize that it needs to go into “bandwidth test” mode.

TCP ping” mode, or “latency test” mode

In practice, it seems like -l, which is documented to specify a size, ends up causing the program to be in “latency test” mode.

Some Misdocumentation

Based on the PsPing home page (@ TechNet), the -l parameter is also supported by the “TCP ping” mode. However, -l does not show up in the program's online help when running “PsPing -? t”.

Before identifying that error, some comparison was made between the web page's documented parameters supported by “TCP ping” mode, or “latency test” mode. Now, that the misdocumentation has been identified, it appears that the only parameter the program needs to check is -l. In practice, it seems that is what the program does.

Testing showed that using “-f” was not sufficient to place the program “latency test” mode; PsPing was happy to operate in “TCP ping” test mode when “-f” was specified, even though the parameter is not documented as being supported by “TCP ping” test mode. At the time of this writing, tests have not been performed to see if the “-f” was simply ineffective, or if it had the expected effect despite being undocumented.)

Despite this section of documentation appearing to be less useful (as it does not seem to determine which mode is being used), this documentation remains in case it is still useful, as this documentation does provide a comparison of documented parameters.

Parameters that would help to indicate “latency test” mode instead of “TCP ping” mode
  • -s clearly specifies “server mode”, and is not documented in the “TCP ping” mode. (It is documented in both the “latency test” mode and the “bandwidth test” mode, and so this documentation likes to think of -s as specifying an entirely different mode, which this documentation calls “server mode”.)
  • -r is also documented in both the “latency test” mode and the “bandwidth test” mode, but not “TCP ping” mode.
  • -u clearly specifies the program is using UDP, so the program would be using “latency test” mode (unless the command line also specified “-b”, in which case the program would be using UDP to perform a bandwidth test).
  • -f is supported by “latency test” mode and “bandwidth test” mode, but not “TCP ping” mode.
Parameters that would specify “TCP ping” mode instead of “latency test” mode
  • -q and -t are both supported by only “TCP ping” mode and “ICMP ping” mode. So, seeing either of those parameters would specify that the program should not use “latency test” mode.
  • -i is not documented as being part of “latency test” mode (making it as useful indicator, like -t or -q).
    • The -i parameter is supported by all other modes, and -i has a different meaning when the program is in “bandwidth test” mode compared to the meaning that -i has when in “ICMP ping” mode or “TCP ping” mode.
    So, simply seeing -i might not be a fast indicator that “TCP ping” is being used, but if the possible choices are down to using either “latency test” mode or “TCP ping”, then this would be enough to make that determination.

This approach of determining the program's mode might not work if only parameters used are the destination and one or more of -f, -h, -l, -n, -w, and/or either -6 or -4.

Some more info

You can get this program from Microsoft/Sysinternals by using any of these methods: download it (https://live.sysinternals.com/psping.exe 32-bit or the less compatible https://live.sysinternals.com/psping64.exe 64-bit), obtain it in a package (https://download.sysinternals.com/PsTools.zip, or run it using WebDAV.

The following shows using the WebDAV client built into Microsoft Windows.

net start WebClient
\\live.sysinternals.com\Tools\psping.exe -accepteula -b -l 8k -n 100 -h 13 -w 0 example.com:80

Note: This does not use -i to specify iterations, because when a TCP port is used (as shown above) or a UDP port is used (by adding -u to the above), then -i is treated as an interval. (When using that mode, -n specifies the number of iterations.)


The -accepteula writes a registry entry, which could also be created with:

REG QUERY HKCU\Software\Sysinternals\PsPing /v EulaAccepted
REG ADD HKCU\Software\Sysinternals\PsPing /v EulaAccepted /t REG_DWORD /d 1

(If that registry entry doesn't exist, then the software prompts the user.)


Reduces output. This does not show up in the program's internal mode-specific help, because the effect is identical no matter which one of the four modes gets used.

psping -?

However, despite being documented, it seems this parameter can break things. If placed towards the beginning of the command line, this can result in the program complaining about an invalid syntax). Things may work better if -nobanner is the very last parameter, but some runs have seemed to provide clearly incorrect statistics (with Average matching Maximum) in that case. If you're struggling with this, consider making -nobanner the very last parameter, or trying just entirely leaving off the -nobanner parameter.


The presence of this command line is one of the key flags that determines that a bandwidth test is being used. A TCP port needs to be specified, unless -u is also used, which causes a need for a UDP port to be specified.

This seems to work well with TCP port 80 (HTTP), and less well with some other ports like TCP port 443 (HTTPS) or UDP port 53 (DNS).

-h 13
Understanding the syntax

Specifying -h indicates that a latency histogram will show. The histogram's output will use a number of lines specified, which appears to default to 20.

The histogram will ignore any “warm-up” packets. By default, it will show a minimum time which is the time of the fastest packet, and it will also show a maximum time which is the time of the slowest packet. Then, the remaining amount of lines will show times that are evenly divided between the minimum and maximum times. Each of these lines of output corresponds to what PsPing's documentation calls a “bucket”. To understand this program, you can safely think of a “bucket” simply refers to one of the lines of this histogram output.

When a packet is received, PsPing will check whether a network communication took longer than the time shown on one of the histogram lines. If so, the packet will be counted as belonging to that line, unless the response was slow enough to take longer than the time shown on a later line of the histogram output. By performing this process, the histogram output effectively shows how many packets were rather quick and how many packets were rather slow.

If the parameter to -h is a comma-separated list of times, then the histogram will use those times as the bucket boundaries, and will have one more output line for “#INF (referring to infinity). Documentation shows times specified as precise as centiseconds (using two numbers after a decimal point), while experimentation suggests that specifying a number like 25.005 will simply round to the nearest centisecond (rounding down if exactly .005).

Recommended values

Specifies how many lines of histograms to show. -h 13 seems to work well for a 25-row window, if -nobanner is also used. (Without using the -nobanner option, -h 8 would fill the screen similarly.)

More misdocumentation

PsPing home page (@ TechNet) has some more misdocumentation, at the time of this writing. The page says, “This command tests bandwidth to a PsPing server listening at the target IP address for 10 seconds”.

The sample command line then specifies -n 10000, like the prior sample command line (shown on the PsPing home page (@ TechNet)). That is incorrect, it should be -n 10s. Using -n 10000 would specify 10,000 “sends/receives”, which might take more or less than 10 seconds.


A common approach is to use the CPU heavily. A section about maximizing CPU usage is available to discuss how this may be done. (No statements are hereby being made about whether this approach typically results is a supremely useful, effective test.)

There may be some other software, which might perform testing a bit more thoroughly. Also, check out the section about multi-component testing.

[#cpuburn]: cpuburn

Note: Before running this software or any other software similar to it, be familiar with the risks. (Read #tstbrkhw.)

The cpuburn software is a collection of software using commands that start with the word “burn”.

The Wayback Machine @ Archive.org's arcthive of the cpuburn Homepage references a version for “Linux/*BSD” and a separate version for Win95/NT. The cpuburn Homepage had hyperlinks to download the software.

This is one of the hardware testing software offerings which had documentation that included a warning about problems including “permanent damage”, including possible “data loss (filesystem corruption) and ” ... “permanent damage to electronic components

Since there's a number of commands provided by the cpuburn suite, knowing which software to run may take a bit of reading to feel comfortable that the best decision is being made. The best choice may be: multiple. The documentation notes, “If sub-spec, your system may lock up after 2-10 minutes.  It shoudln't.” So maybe the best choice is to run one of the testers for 10 minutes or longer, and then switch to another tester.

To elaborate in more detail, the cpuburn documentation on the website notes, “In spite of it's name, burnBX can be run on any chipset [RAM controller] and tests alot more than the RAM controller. Unfortunately, burnBX is not optimal on AMD processors.

So, some speculation/advice is available regarding which software to try using first:

Order of executables for non-AMD chips
So, for Intel CPUs (or perhaps any other CPUs that aren't AMD), consider starting with burnBX. Then, although the documentation suggests that burnMMX may be preferable for MMX-capable chips, it seems more sensible that burnMMX is meant primarily for Pentium chips which support MMX but which do not support the features of the more specific testers for burnP6. So perhaps a most thorough test would start with P6, then use the alternate tester for BX, follow that up with MMX, and to be super thorough, use P5 as well. Clearly, the P6 step should be skipped for older systems that use Pentiums (instead of Pentium Pro, Pentium 2, or newer Intel processors). The MMX test should probably be skipped on any system which doesn't use MMX.
Order of executables for AMD chips
For AMD chipsets, it would make sense to start with K7 if using an Athlon or newer, follow up with MMX if the CPU supports MMX, and perhaps use K6 to be super-thorough.

Additional notes about this software: the DebianInstaller offers an option to download an “installer component” called “cpuburn-udeb: perform CPU stress test (burn in) - expert use only”. Selecting the menu option causes a warning to be provided: “This process is designed to heavily load CPU chips. Undercooled, overclocked or otherwise weak systems may fail causing possibly permanent damage to electronic components. Use at your own risk.” “Users should read the cpuburn documentation carefully before use.” (At least some of that text sounds quite a bit like the warning provided by the cpuburn software's documentation.)