Posted on Leave a comment

OpenVPN Server Speed Tweaks

I’ve been running my own VPN so I can access my home-based servers from anywhere with an internet connection (not to mention, in this day & age of Government snooping – personal privacy & increased security).

I’m on a pretty quick connection from Virgin Media here in the UK, currently the fastest they offer:

Virgin Media
Virgin Media

To do these tests, I used the closest test server to my VPN host machine, in this case Paris. This keeps the variables to a minimum. Testing without the VPN connection gave me this:

Paris Server Speed
Paris Server Speed

I did expect a lower general speed to a server further away, this will have much to do with my ISP’s traffic management, network congestion, etc. So I now have a baseline to test my VPN throughput against.
The problem I’ve noticed with OpenVPN stock configs are that the connections are painfully slow – running over UDP on the usual port of 1194 the throughput was pretty pathetic:

Stock Config Speed
Stock Config Speed

I did some reading on the subject, the first possible solution being to change the send/receive buffers so they’re set to a specific value, rather than letting the system handle them. I also added options to get the server to push these values to the clients, this saving me the trouble of having to reissue all the client configurations.

Unfortunately just this option didn’t work as well as I’d like, downstream speeds jumped to 25Mb/s. In the stock config, the tunnel MTU & MSSFIX settings aren’t bothered with, some adjustment to set the tunnel MTU to lower than the host link MTU (in my case the standard 1500) prevents packet fragmentation, MSSFIX let’s the client TCP sessions know to limit the packet sizes it sends so that after OpenVPN has done the encryption & encapsulation, the packets do not exceed the set size. This also helps prevent packet fragmentation.

VPN Tweaked
VPN Tweaked

After adjusting these settings, the download throughput over the VPN link has shot up to 136Mb/s. Upload throughput hasn’t changed as this is limited by my connection to Virgin Media. Some more tweaking is no doubt possible to increase speeds even further, but this is fine for me at the moment.

 

Posted on Leave a comment

QSO Logging Systems

As per my site update post, I have migrated my radio log onto a new system, from CQRLOG.

CQR log has served me well since I first started in Amateur Radio, however it’s a bit complex to use, requires a backend MySQL server for it’s database, and as it’s a local application, it’s not possible to share my log with other Hams without some difficulty.
The only other major system with an online logging system is QRZ, and I find that particular site a bit of a pain, and many of the features there aren’t free. (Although it’s not horrendously expensive, I’m on a very tight budget & I must save where I can).

CQRLOG
CQRLOG Screenshot

Because of these points, I went on a search for something that would better serve my needs. I have discovered during this search that there’s liitle out there in the self-hosted respect.

I did however find Cloudlog, a web based logging system in PHP & MySQL.
This new system allows integration with the main site, as I can run it on the same server & LAMP stack, it’s very simple to use, is visually pleasing and it even generates a Google Map view of recent QSO locations.
It will also allow me to save some resources on my main PC, running a full-blown MySQL server in the background just for a single application is resource intensive, and a bit of a waste of CPU cycles. (CQRLOG and it’s associated MySQL server is 300MB of disk space, CloudLog is 27MB).

Backups are made simpler with this system also, as it’s running on my core systems, incremental backups are taken every 3 hours, with a full system backup every 24 hours. Combined with offsite backup sync, data loss is very unlikely in any event. All this is completely automatic.
I can also take an ADIF file from Cloudlog for use with any other logging application, if the need arises.

Cloudlog is built & maintained by Peter Goodhall, 2E0SQL.
From the looks of Github, there’s also a version 2 in development, although now I have version 1 up & running, I might just stick with it, unless an easy upgrade path is available.

When I am not operating mobile, new QSOs should appear in this system almost immediately, with their respective pins on the map. (These are generated by the Grid Square location, so accuracy may vary).
If you’ve spoken to me on the air & I haven’t updated it, I’m most likely away from an internet connection, in which case your callsign will appear as soon as I have access.

73s for now folks!

Posted on Leave a comment

New Feature – Geiger Counter

Here’s something new, an internet connected Geiger counter! The graph in the sidebar is updated once every 60 seconds, and can be clicked on for a larger version. Measurements are in Counts Per Minute, the graph logs 1 hour of data.

 

The counter itself is a Sparkfun Geiger counter, with the end cap removed from the tube so it can also detect alpha radiation.

Connected through USB, a Perl script queries the emulated serial port for the random 1 or 0 outputted by the counter when it detects a particle. The graph is pretty basic, but it gets the point across. Anybody who wishes to contribute to improve the graphing is welcome to comment!

Geiger Counter
Geiger Counter