Greg's satellite link statistics

Greg's home page Greg's diary Greg's photos Greg's mail queue statistics Greg's links

One of the less pleasant consequences of moving from Echunga to Dereel in July 2007 was that I lost my ADSL line and had to resort to other methods. This page bases on an earlier page that I wrote for the DSL connection. Currently it shows only connectivity, since the iCON IPX-3200 satellite modem I'm using has some of the most broken firmware I've seen anywhere—it works only in conjunction with Microsoft's “Internet Explorer”.

The graphs show:

• Link status. This is the connectivity to the other end of the satellite link, measured by an ICMP echo (ping) packet once a minute. This should remain steady at 1. A drop to 0 indicates a link failure.
• Network status. This is the number of remote systems responding to a ICMP echo (ping) packet at the same time as the link status ping. I currently ping 5 systems which I frequently access: freefall.FreeBSD.org, shell.mysql.com, www.auug.org.au, ozlabs.org and ftp.NetBSD.org. Normally this value should be 5. If it's less, the script retries every second until full connectivity is restored.

Currently (7 January 2007) I have been having severe problems with the satellite service since it was installed nearly three weeks ago: after a couple of hours, TCP connectivity disappears, while UDP and ICMP connectivity seem unaltered. See my diary entries starting on 21 December 2007 for more details. While my ISP is doing his best, it's clear that the real problem is with IPStar, who either don't care or are unable to fix the problem, which could be either with the modem or with the configuration of the satellite link itself. It should be straightforward for IPStar (but nobody else) to determine which it is, but they have not done so. Now I'm getting a new modem, which for reasons which nobody can explain takes 10 days. During this time I'm falling back to a G3 wireless connection, so the graphs show a misleading picture. From 7 January on, I'm routing the systems mentioned above via satellite as much as possible, but may route back via wireless if things get too bad.

The network status shown in green does not indicate anything about the TCP problem: they're pings, which use ICMP. Anything less than 100% indicates problems beyond the TCP issue. I've only just started to address the TCP issue, and things may change. The current plots (in blue) are a reciprocal function of the time it takes to transfer a very small “web page” (four bytes) from my external web server. The values shown are reciprocal seconds: 0.5 is 2 seconds, 2 is 0.5 seconds, etc. It seems that it takes about 4 seconds to perform the transfer, which is due mainly to satellite latency.

This graph doesn't directly show the loss of TCP connectivity: as long as the “speed” is above 0, I have connectivity. When the connectivity goes away, the “speed” drops to 0.

Click on the graphs for a 1600x1200 version.

The monitor scripts

• The script linkcheck performs the periodic pings to check link and network status. It writes the results to a log file for later processing.
• linkcheck invokes tcpcheck to check the TCP connection, since it could take forever. tcpcheck writes its own log file.
• The main script runs gnuplot to create the graphs.
• The main script takes a raw gnuplot script and modifies it to create a total of 16 plots: four times (4 hours, 24 hours, one week and forever), two views (smoothed and unsmoothed) and two sizes (540x360 and 1600x1200). I chose 540x360 to fit two plots comfortably side-by-side on my screen; YMMV.

Download the scripts

Greg's diary	Greg's photos	Greg's links	Greg's home page
	$Id: satstats.html,v 1.18 2008/02/10 23:53:05 grog Exp $