View source for Pinging with Fping and Collecting Ping Performance Data

Fping is a command line application that allows for data collection and recording of the ping command data. It is basically like Ping, but is better, and has more features and functions. The most important feature is to log pings with time and date stamps to a file. In addition, it provides an accurate millisecond calculation on the ping command. FPING also supports 64 bit operating systems. 

*Google "windows fping 3.0", or use this link http://blog.perceptus.ca/2017/11/10/fping-windows-download-the-last-version/
Extract and put it in c:\fping 

==Limitations of Windows Based PC's for Reliable Ping Testing==

Pings are the very lowest priority packet for doing testing. This is the '''curse of collecting ping data''', but it is also a benefit of collecting ping data. Ping drops can occur due to any reason, including the source and destination's processing capability. 

Pings take into account the cycle time through all routers and PC's. You will never obtain 100% low ping times on routers or PC's, because they are often doing other things. Average is what is important. 

Windows based PC's do not guarantee processor queues for any specific ping applications. Lost packets either on the send or the return of ping packets is common and to be expected on all windows PCs, as there is no dedicated processing at the network layer. In addition, determining why a ping was lost cannot be reliably determined on a Windows PC. Data should be considered suspect on Windows based PC's. We recommend using the 64 bit ping application if your operating system is compatible with 64 bit. 

What we know does provide accurate testing via packet loss is Cisco IOS Router, and dedicated linux testing tends to work better, because there is less of an operating system to go through (i.e. gui, etc) to get to the network card. Dedicated network processor cards in the linux platform should. 

In general, reliable ping testing should primarily be performed on Cisco IOS capable routers. FPING does some cool stuff, but ACD generally focuses on ping testing from our Cisco IOS routes. 

'''We are in the process of testing fping compared to ping, and seeing if there is a way to make sure the buffer queues are adequate to guarantee processing of all low priority packets. This is pending as of 03/20/12'''

'''We are in process of testing fping compared to Cisco IOS routers on unloaded Windows 7/Windows 8, etc boxes as of 10/01/12'''

==Data relied upon for debugging or troubleshooting==

*ACD does not utilize the default command line application for ping testing or packet loss. This application does not provide any logging or correlation for the data collection. We need timestamps that are accurate to correlate to any issue we may be able to detect in the logging. 

*ACD does utilize and accept FPING data with the above Windows caveats. We need the text file that has been run on the standard command structure as described in this document. 

*ACD does prefer Cisco IOS ping data tests above all else and that is what we principally do debugging upon.

==Command Structure==

'''Long term pinging'''

In command prompt type: cd C:\fping

The command structure that should be used: 

*fping xxx.xxx.xxx.xxx -D -T -c -s 1500 -L name-of-log-file.txt
**Where xxx.xxx.xxx.xxx is the ip address of the device you are pinging.
**This will create a timestamped file.
**-s 1500 sends 1500 byte pings, which is the maximum normal size. If you cannot send 1500 byte pings, there is something wrong somewhere on the network you are using.

Mail the log file created by fping to support@acd.net.

'''Aggressive Ping Testing'''
This should be used to detect issues with CRC and other line errors, generally this will stress the equipment that you are reaching. '''DO NOT PING EQUIPMENT WITH THESE COMMANDS UNLESS IT IS YOUR EQUIPMENT'''. If service providers see this type of ping traffic hitting their equipment for a while (i.e. more that a couple of minutes) or often expect to get Null Routed.

*fping xxx.xxx.xxx.xxx -t100 -D -T -c -s 1500 -L name-of-log-file.txt
**Where xxx.xxx.xxx.xxx is the ip address of the device you are pinging.
**This will create a timestamped file.
**-s 1500 sends 1500 byte pings, which is the maximum normal size. If you cannot send 1500 byte pings, there is something wrong somewhere on the network you are using.
**-t100 lowers the time between pings. 100=100ms. Lower it down until you get to the point of limited responsiveness. Generally you can lower the time all of the way down to one millisecond. '''Effectively, you are pinging as quickly as the response from one ping comes back without delay. This is good for detecting hosts that have ping rate limiting or also have inherent limitations on the ping speed. '''PING OTHER PEOPLES STUFF WITH CAUTION, INCLUDING ACD.NET EQUIPMENT. IF YOU PING ACD FOR LONG YOU WILL BE NULL ROUTED BY OUR NOC.'''

==How to use Ping testing ==
*In general you should open multiple ping windows to various hosts simultaneously. What matters most, is a consistent pattern of traffic issues to multiple devices '''THAT OCCUR AT THE SAME TIME'''. For example, if there are dropped or delayed packets all at the same time between multiple hosts, this more reliably shows that there is a problem.
*What matters most is not that one host dropped or delayed a packet; '''what does matter''' is when multiple hosts dropped or delayed a packet from your PC or site '''at the same time''', this is why having timestamps is critical. For this reason you must have multiple pings going at once to be able to correlate any data. 
*'''Pinging ACD routers or ACD gateways will not result in good testable data, from the standpoint of high ping times.''' This is simply the case because our routers are busy doing other more important things than responding to customer requested pings. They are programmed to focus on shipping data and are programmed to delay or ignore your ping traffic when they are busy. It is common to see spikes in the responsiveness of pings in the range of 200-300ms for periods of time because these routers are running tasks and their responsiveness to ping requests is lower. Certain processes that run on a consistent cycle, such as BGP route updates or OSPF route updates will consistently spike the ping times for short periods of time, this is consistent and normal. When we don't see this when examining data, this is a cause for concern.   
*Pinging websites like www.yahoo.com and www.google.com will also generally not produce good data. They don't want to waste all their precious CPU cycles returning pings.

==What to Ping==
On ACD systems you can ping these ip addresses. The platform is listed below as of the time of this writing. 

*iperf.acd.net (Linux Platform)
*voip.acd.net (Phone Switch)
*switch.core.metroix.net (Cisco IOS 6509, SUP720-3B, max memory)
*switch2.core.metroix.net (Cisco IOS 6509, SUP720-3B, max memory)