Free round trip time software for linux

mrtg-ping-probe project monitors round trip time and packet loss to another host. Still on my TODO list: add own min/max/avg rtt calculation, add perl ping module, add rping and rsh support...
mrtg-ping-probe is a ping probe for MRTG 2.x. It is used to monitor the round trip time and packet loss to networked devices. MRTG uses its output to generate graphs visualizing minimum and maximum round trip times or packet loss.
mrtg-ping-probe depends on the following software being installed on your system: perl (at least version 5.6.1), mrtg (I use version 2.8.8, though any mrtg 2.x version should work), and a ping program that displays a summary of the round trip times upon termination or timeout.
mrtg-ping-probe runs on AIX, BSD/OS 2.1, FreeBSD/2.2.x, IRIX/6.2, Linux, Mac OS X (Darwin 5.4), NetBSD, OpenBSD, OS/2, OSF1 V3.2, Solaris 1.1.2 (SunOS 4.1.4), Solaris 2.5.1 (SunOS 5.5.1), Solaris 7 (SunOS 5.7), Solaris 8 (SunOS 5.8), Solaris 9 (SunOS 5.9), HP-UX 9, Windows 98, and Windows 2000 (english, french, portugesee, and spanish locales).
If you install the Windows ping program that comes with Windows 98, Windows 2000, or WinSock 2.x, mrtg-ping-probe will also run on Windows 95 and Windows 4.0.
Support for additional systems is usually easy to add, as described in the file INSTALL.
Act responsible: do not use mrtg-ping-probe to ping devices without the owners permission. Just imagine 10,000 people would decide to ping your hosts ... mrtg-ping-probe is meant to be used within your network to get round trip time performance figures for your network.
Usage: mrtg-ping-probe [-hsvV] [-d deadtime] [-k count] [-l length] [-o ping_options] [-p [factor*]{min|max|avg|loss|integer}/[factor*]{min|max|avg|loss|integer}] [-r [rsh:][user@]host[:osname]] [-t timeout] host
Enhancements:
- new platforms supported: italian Windows 2000 locale.
- bugfixes: on Windows actually return deadtime when we lost all packets, not 0. the ping child process should actually be killed now on Unix platforms.
- changes: ***** Possible Incompatability ***** raised minimum required perl version to 5.6.1. lots of typos fixed.

Just For Fun Network Management System is a PHP-based network management system that features an integrated syslog, Tacacs, TFTP configuration downloading, SNMP polling, SNMP traps, journalling, auto-discovery, performance graphs (RRD), SLAs, and a lot more.
Just For Fun Network Management System uses MySQL or PostgreSQL as the backend and works under Linux and Windows.
Main features:
- Written in PHP4 (works in PHP5 too)
- Fully tested on Linux, FreeBSD and Win2K
- Should work on any other system which supports PHP
- PHP/cron scripts for polling, analizing and consolidating data
- Database Backend MySQL or PostgreSQL
- Configurable Event Types and Severity Levels
- Modular and Extensible
- Advanced Event Filter
- Interface Autodiscovery
- Licensed under the GNU GPL
- Event Console, Shows Events / Tacacs / Syslog / Alarms in the same time-ordered display
- Map & Sub-Map support
- Graphical Interface Traffic, Round Trip Time, Packet Loss Monitoring, and a LOT more
- Variable Time Span in the graphs
- Total Administration via web
- Sound Alerts in your browser
- Events RDF Feed (for newstickers)
- Works with HTTPS
- Traffic Bytes
- Utilization %
- Packets per Second, Errors per Second, Error Rate
- Round Trip Time and Packet Loss (Cisco & Smokeping)
- Drops
- TCP Connections: Incoming, Outgoing, Established, Delay
- Number of Processes, Number of Users
- Used Memory and Disks with Aggregation
- Processor Utilization and Load Average
- Temperature
- Interfaces (Network cards)
- Host (Processor, Load Average)
- Storage (Disks and Memory)
- Applications Running (HostMIB)
- Cisco Ping (RTT & PL on Cisco)
- BGP4 (BGP sessions status)
- TCP (TCP Connections, Delay)
- Cisco MAC Accounting
- Cisco IP Accounting
- Cisco CSS
- Cisco SA Agent
- Cisco Enviormental (Temperature, Voltage, etc)
- Internet Information Server (IIS) MIB
- Livingstone PortMaster3 Serial Line MIB
- Compaq Insight Manager MIB (Disk, Fan and Temperature)
- Apache /server-status monitoring
- TCP Port Content Regexp Checking (or URL)
- Configurable per Circuit SLAs (with RPN logic)
- Internal Authorization Framework
- Per Event Journals and Acknowledge
- Triggers / Actions Framework for email/others alerts.
- Database Abstraction Framework
- CSV Export
- Distributed Polling
- Object Oriented
- Consistent API
Enhancements:
- Better support for PHP 5 and RRDTool 1.2.x, OS/400 integration, Dell Chassis alarm monitoring, and fixes for all reported issues.

SAFMQ, one of the first Open Source message queue server, provides high performance message queuing free to the public.
The SAFMQ server provides Asynchronous Messaging. Message Publishers send or enqueue a message with the SAFMQ server.
The SAFMQ server stores that message until the point at which the message can be forwarded on to the client. Message Publishers are assured that the messages are delivered. Thats how SAFMQ got its name.
SAFMQ provides an API to use SAFMQ directly. Simply use the SAFMQ MQBuilder class to specify the location of your SAMFQ server and youre ready to start publishing and subscribing to priority message queues!
Timely Messaging
SAFMQ provides the ability to perform timely message delivery. So, if a Message Publisher wants a message to be read by a Message Subscriber in a certain amount of time, or not read at all, then the Message Publisher can prescribe a Time-To-Live for the message it publishes. SAFMQ will notify the Message Publisher about messages which have outlived their Time-To-Live, or a Message Publisher can choose to ignore the event.
Round-Trip, PsudoSynchronous Messaging
Round-Trip, or PsudoSynchronous Messaging is when a Message Publisher acts as a Message Subscriber after sending a "query" message. A Message Publisher may want to receive information back from the Message Subscriber. Thus after the first message is sent by a Message Publisher and is received by a Message Subscriber, the original Message Publisher and Message Subscriber switch rolls.
SAFMQ provides a special messaging context element for Round-Trip/PsudoSynchronous Messaging. Its called a Receipt ID. When ever a message is Enqueued in a SAFMQ server, it is given a Universally Unique Identifier or UUID for short. When a Round-Trip message event is taking place, the original Message Subscriber publishes a message with a Recipt ID identiacal to the Message ID assigned to the message sent by the original Message Publisher. Then the original Message Publisher (now a subscriber) waits for a message with a Receipt ID equal to the Message ID the original Message Publisher sent.
Batch Processing
Not every task is best handled real-time. Sometime there are real money benefits to send transactions to a trading partner in a large group or batch. SAFMQ can be an intermediary between real-time systems and a back-end batch processor. The real-time system knows that the messages will be delivered, and the batch processor can let data queue up until it is ready to send all the data. The batch system can even respond via SAFMQ and a real-time system can instantly see the results.
Enhancements:
- Additional configuration changes for cross compile to MacOS X

libping is a C library designed to allow a programmer to make ICMP_ECHO requests directly from a script or program. libpings functions return either boolean--is alive--or the round trip time in milliseconds.

The library also includes support for "pinging" the following tcp/ip services: echo, http, https, smtp and pop3. Versions 1.15 and better are threadsafe.

Installation:

In a nutshell, to install the application in the default directory, ( /usr/local ), run the following commands:

$ ./configure
$ make
$ make install

This will install the application ( ring ) in the default directory /usr/local/bin. If that directory is in your PATH, then to run ring and view the online help type:

$ ring --help

It will also install libping in /usr/local/lib and place the header file ping.h in /usr/local/include.

To learn more about ring, make sure /usr/local/man is in your MANPATH and type:

$ man ring

For information about the C library functions, type:

$ man pinghost

For more details, read on. Especially if you want to install libping in a directory other that /usr/local

Berkley Snoop for Linux is a module which adds support for the Snoop protocol, a TCP-aware link layer protocol designed that can improve the performance of TCP over networks of wired and single-hop wireless links.
While TCP adapts well to network congestion, it does not adequately handle the vagaries of wireless media. In this thesis, we address these challenges in detail and design solutions to them. These solutions incorporate link-layer techniques as well as enhancements to TCP at the sender and receiver. The Snoop protocol is a TCP-aware link layer protocol designed to improve the performance of TCP over networks of wired and single-hop wireless links.
The implementation is for kernels of 2.6.x series. This software is intended to use on routers acting between big fat pipe(BFP) link and wireless link.
The problem: The wireless link is error prone by its nature and BFP links such as satellite one has very big round-trip time. When error occurs on wireless segment it causes in speed reduction because the TCP protocol on sending side treats this error as link congestion although the error was just a temporary link quality loss and the connection cannt recover its speed.
The fix: The module will cache TCP segmets passing to host on wireless segment until the ACK(nowledgmet) is received or timeout expired. In case of timeout the segment will be retransmitted again. And by the way the module will drop all DUP(licate) ACK(nowledgmets) caused by packet loss on wireless segment and prevent the reduction of speed of flow from the host beyond the satellite link. The module works now only with connections initiated from wireless hosts.
Enhancements:
- fixed issues with improper use of locks & memory allocation the memory allocates now with GFP_ATOMIC priority

The Wonder Shaper is a very special network shaper script with a lot of features. Works on Linux 2.4 & higher.

Goals

I attempted to create the holy grail:

* Maintain low latency for interfactive traffic at all times.

This means that downloading or uploading files should not disturb SSH or even telnet. These are the most important things, even 200ms latency is sluggish to work over.

* Allow surfing at reasonable speeds while up or downloading

Even though http is bulk traffic, other traffic should not drown it out too much.

* Make sure uploads dont harm downloads, and the other way around

This is a much observed phenomenon where upstream traffic simply destroys download speed. It turns out that all this is possible, at the cost of a tiny bit of bandwidth. The reason that uploads, downloads and ssh hurt eachother is the presence of large queues in many domestic access devices like cable or DSL modems.

Why it doesnt work well by default

ISPs know that they are benchmarked solely on how fast people can download. Besides available bandwidth, download speed is influenced heavily by packet loss, which seriously hampers TCP/IP performance. Large queues can help prevent packetloss, and speed up downloads. So ISPs configure large queues.

These large queues however damage interactivity. A keystroke must first travel the upstream queue, which may be seconds (!) long and go to your remote host. It is then displayed, which leads to a packet coming back, which must then traverse the downstream queue, located at your ISP, before it appears on your screen.

This HOWTO teaches you how to mangle and process the queue in many ways, but sadly, not all queues are accessible to us. The queue over at the ISP is completely off-limits, whereas the upstream queue probably lives inside your cable modem or DSL device. You may or may not be able to configure it. Most probably not.

So, what next? As we cant control either of those queues, they must be eliminated, and moved to your Linux router. Luckily this is possible.

Limit upload speed somewhat

By limiting our upload speed to slightly less than the truly available rate, no queues are built up in our modem. The queue is now moved to Linux.

Limit download speed

This is slightly trickier as we cant really influence how fast the internet ships us data. We can however drop packets that are coming in too fast, which causes TCP/IP to slow down to just the rate we want. Because we dont want to drop traffic unnecessarily, we configure a burst size we allow at higher speed.

Now, once we have done this, we have eliminated the downstream queue totally (except for short bursts), and gain the ability to manage the upstream queue with all the power Linux offers.

Let interactive traffic skip the queue

What remains to be done is to make sure interactive traffic jumps to the front of the upstream queue. To make sure that uploads dont hurt downloads, we also move ACK packets to the front of the queue. This is what normally causes the huge slowdown observed when generating bulk traffic both ways. The ACKnowledgements for downstream traffic must compete with upstream traffic, and get delayed in the process.

We also move other small packets to the front of the queue - this helps operating systems which do not set TOS bits, like everything from Microsoft.

Allow the user to specify low priority traffic (new in 1.1!)

Sometimes you may notice low priority OUTGOING traffic slowing down important traffic. In that case, the following options may help you:

NOPRIOHOSTSRC
Set this to hosts or netmasks in your network that should have low priority

NOPRIOHOSTDST
Set this to hosts or netmasks on the internet that should have low priority

NOPRIOPORTSRC
Set this to source ports that should have low priority. If you have an unimportant webserver on your traffic, set this to 80

NOPRIOPORTDST
Set this to destination ports that should have low priority.

See the start of wshaper and wshaper.htb

Results

If we do all this we get the following measurements using an excellent ADSL connection from xs4all in the Netherlands:

Baseline latency:
round-trip min/avg/max = 14.4/17.1/21.7 ms

Without traffic conditioner, while downloading:
round-trip min/avg/max = 560.9/573.6/586.4 ms

Without traffic conditioner, while uploading:
round-trip min/avg/max = 2041.4/2332.1/2427.6 ms

With conditioner, during 220kbit/s upload:
round-trip min/avg/max = 15.7/51.8/79.9 ms

With conditioner, during 850kbit/s download:
round-trip min/avg/max = 20.4/46.9/74.0 ms

When uploading, downloads proceed at ~80% of the available speed. Uploads at around 90%. Latency then jumps to 850 ms, still figuring out why.

What you can expect from this script depends a lot on your actual uplink speed. When uploading at full speed, there will always be a single packet ahead of your keystroke. That is the lower limit to the latency you can achieve - divide your MTU by your upstream speed to calculate. Typical values will be somewhat higher than that. Lower your MTU for better effects!

A small table:

Uplink speed | Expected latency due to upload
--------------------------------------------------
32 | 234ms
64 | 117ms
128 | 58ms
256 | 29ms

So to calculate your effective latency, take a baseline measurement (ping on an unloaded link), and look up the number in the table, and add it. That is about the best you can expect. This number comes from a calculation that assumes that your upstream keystroke will have at most half a full sized packet ahead of it.

This boils down to:

mtu * 0.5 * 10
-------------- + baseline_latency
kbit

The factor 10 is not quite correct but works well in practice.

Your kernel

If you run a recent distribution, everything should be ok. You need 2.4 with QoS options turned on.

If you compile your own kernel, it must have some options enabled. Most notably, in the Networking Options menu, QoS and/or Fair Queueing, turn at least CBQ, PRIO, SFQ, Ingress, Traffic Policing, QoS support, Rate Estimator, QoS classifier, U32 classifier, fwmark classifier.

In practice, I (and most distributions) just turn on everything.

The scripts

The script comes in two versions, one which works on standard kernels and is implemented using CBQ. The other one uses the excellent HTB qdisc which is not in the default kernel. The CBQ version is more tested than the HTB one!

See wshaper and wshaper.htb.

Tuning

These scripts need to know the real rate of your ISP connection. This is hard to determine upfront as different ISPs use different kinds of bits it appears. People report success using the following technique:

Estimate both your upstream and downstream at half the rate your ISP specifies. Now verify if the script is functioning - check interactivity while uploading and while downloading. This should deliver the latency as calculated above. If not, check if the script executed without errors.

Now slowly increase the upstream & downstream numbers in the script until the latency comes back. This way you can find optimum values for your connection. If you are happy, please report to me so I can make a list of numbers that work well. Please let me know which ISP you use and the name of your subscription, and its reputed specifications, so I can list you here and save others the trouble.

Installation

If you dial in, you can copy the script to /etc/ppp/ip-up.d and it will be run at each connect.

If you want to remove the shaper from an interface, run wshaper stop. To see status information, run wshaper status.

KNOWN PROBLEMS

If you get errors, add an -x to the first line, as follows:

#!/bin/bash -x

And retry. This will show you which line gives an error. Before contacting me, make sure that you are running a recent version of iproute!

Recent versions can be found at your Linux distributor, or if you prefer compiling, here:
ftp://ftp.inr.ac.ru/ip-routing/iproute2-current.tar.gz