Graphs from network monitors on my remote trading server

Here are some server monitoring graphs from my remote trading server. These graphs are produced by the server monitoring application, Munin. I ran both JForex and Metatrader 4 simultaneously on my server last week. The 512 MB of memory was noticeably insufficient. Which caused the system to use swap files, thus leading to I/O latency, and which held up the CPU. All of which are evident from the graphs below. This week I am only running JForex. The server load is within tolerable range. The thing with picking your own VPS is that no VPS provider is the same. You can't really compare just the numbers as there are just too many factors to be considered behind the scene on a VPS service. So it is important to run applications that you intend to run and stress your system in real-world conditions. If your system seems slow, figure out where exactly is the bottleneck before throwing away money for upgrades. This is where a server monitoring application comes handy. [caption id="attachment_5437" align="aligncenter" width="497" caption="CPU data"][/caption] [caption id="attachment_5438" align="aligncenter" width="497" caption="Memory data"][/caption] [caption id="attachment_5439" align="aligncenter" width="497" caption="Interrupts data"][/caption] [caption id="attachment_5440" align="aligncenter" width="497" caption="Disk I/O latency"][/caption] [caption id="attachment_5441" align="aligncenter" width="497" caption="Network transfer"][/caption]

Choosing a budget VPS provider for hosting automated trading programs

I've been looking for a cheap but reliable virtual private server (VPS) to run my trading program for the last few months. I ran my QTD program on 3 remote servers in UK and Germany in April for an entire month as performance testing. One in UK on a Xen cloud. One in Germany on OpenVZ. And a last one also in UK on KVM technology. This post is a summary of my initial findings on what to watch for when choosing a server provider for running a remote trading server. Keep in mind that this is for low-end, low-frequency, retail trading. Where latencies in the range of tens of milliseconds are considered good. General target price range is US\$10 - \$20 per month for an unmanaged server with 512MB of ram and 600MHz-equivalent of circa 2006 Intel CPU. Low price is the primary consideration here. If you don't care for the technical details, the top VPS names are Linode, Hetzner, and 6sync for Linux-based VPSs. Linode offers Xen VPSs in US and UK. 6sync offers KVM VPSs in US only. Both companies offer Linux-based 512MB instances for \$20 as a starter server. Hetzner offers KVM VPSs in Germany for €7.90. Cloud servers like Amazon EC2 and Rackspace Cloud are too expensive for running 24/7.

Location, Location, Location

Use a datacenter that's at least in the same sub-continent as your broker's datacenter. You wouldn't want your data to travel half-way around the world just to save a few bucks. It adds unnecessary latency and prices are comparable in either the states or Europe nowadays. Although Asia is another story. If you use more than one broker, you can use multiple servers or pick a server location that sits between them on the internet backbone. TeleGeography provides global internet maps to identify best locations. I trade with Dukascopy and Oanda. One in Switzerland and another in the states. As such, Internet hubs in cities like New York, London, and Frankfurt are prime targets for low latency between both brokers. As I trade more at Dukascopy, I'm biased to European servers. Furthermore, London and Frankfurt are the #1 and #2 internet hub in the world. London has 7,723 Gbps and Frankfurt has 7,218 Gbps capacity in 2010. Whereas New York, 5th in the world, has 3,850 Gbps.

Virtualization Technologies

Virtual private servers are merely reserved resource chunks of a computer in a datacenter. This is achieved through the use of virtualization technologies. And there are quite many of those as I have discovered. Here are three that you'll likely hear about in your search.

  1. OpenVZ. This is the most popular and least preferred platform for trading servers. It's often used by budget hosts because resources between virtualized instances are not well isolated. As such, a host can oversell a server's resource as most webapps have sporadic resource utilization trend. In other worlds, it is unlikely all the virtual private servers would demand their maximum allocated resources at the same time. However, trading servers require a consistent and guaranteed level of computing resource. So stay away from VPS that runs on OpenVZ unless you want to see server hiccups.
  2. Xen. This is what Amazon EC2 and Rackspace Cloud runs on. Xen offers true resource isolation so that you're less likely affected by your virtual server's neighbours. What you see is also what you get. So if you're promised 512MB of memory, you'll get 512MB of memory. However, processing power varies tremendously across different VPS providers. A micro instance on Amazon EC2 offers 613MB of memory, for example. But it is no match for even a 256MB instance on Rackspace Cloud. I was able to run a LXDE desktop GUI plus a java program on Rackspace but couldn't do it on Amazon.
  3. KVM. KVM uses the Linux kernel to virtualize. It's said to offer lower overhead to the host server so that it can provide better value than Xen. Like Xen, it offers true resource isolation.

In summary, either Xen or KVM are good but stay away from OpenVZ.

Operating System

Key question here is: Linux or Windows? If you're unfamiliar with Linux and is not interesting in learning about it, use a Windows Server 2003 or 2008 provider. Windows Server 2003 is preferred as it uses fewer resources just to run so it's cheaper. Do note that Windows VPSs are \$10-\$20 more expensive anyway because you have to pay for a monthly license lease. With the use of a Windows-based VPS, you can connect to your server through the remote desktop protocol (RDP). It's just a matter of running the Remote Desktop application on your local machine to your remote server. Then you'll see the remote machine's desktop on your own machine. And then you can control the remote server just like any other Windows computer. Very simple. However, I prefer to run Linux because of its renowned stability and lower cost. The downside is that you need to know what you're doing to tweak the server for trading. Linux uses very little computing resource to run. I can squeeze JForex and Metatrader together on a Linux VPS with only 256MB memory. By comparison, you need at least 512MB on a Windows box just to get the OS running. And there's no licensing fee for Linux too. A double savings.

Summary

When choosing a VPS provider, consider factors such as location, virtualization technology, and operating system(s) offered. Once you've narrowed your search to a shortlist of providers, the next step is to compare their specific VPS offerings by looking at price, services, and technical specifications.

Network latency on Amazon EC2 t1.micro to Dukascopy

While the processing power of a EC2 t1.micro server sucks (benchmarks have shown it is slower than a Nokia N900 phone), network performance is well-known to be exceptional for EC2 servers throughout the spectrum of their offerings. Here's a ping test from my home computer with a ADSL connection in Ottawa, Canada to 194.8.15.1, one of the Dukascopy web servers.

PING 194.8.15.1 (194.8.15.1) 56(84) bytes of data.
64 bytes from 194.8.15.1: icmp_req=1 ttl=242 time=149 ms
64 bytes from 194.8.15.1: icmp_req=2 ttl=242 time=134 ms
64 bytes from 194.8.15.1: icmp_req=3 ttl=242 time=135 ms
64 bytes from 194.8.15.1: icmp_req=4 ttl=242 time=148 ms
64 bytes from 194.8.15.1: icmp_req=5 ttl=242 time=135 ms
--- 194.8.15.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss,
time 4003ms rtt min/avg/max/mdev = 134.364/140.579/149.726/7.053 ms

Then the same test from a EC2 t1.micro instance located in Dublin, Ireland (closest Amazon EC2 server location to Geneva).

PING 194.8.15.1 (194.8.15.1) 56(84) bytes of data.
64 bytes from 194.8.15.1: icmp_req=1 ttl=243 time=40.9 ms
64 bytes from 194.8.15.1: icmp_req=2 ttl=243 time=41.2 ms
64 bytes from 194.8.15.1: icmp_req=3 ttl=243 time=49.0 ms
64 bytes from 194.8.15.1: icmp_req=4 ttl=243 time=41.2 ms
64 bytes from 194.8.15.1: icmp_req=5 ttl=243 time=41.2 ms
--- 194.8.15.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss,
time 4005ms rtt min/avg/max/mdev = 40.961/42.728/49.013/3.154 ms

Exceptional, indeed. With the monthly pricing of a t1.micro going for around \$12/month, there are few reasons not to get a remote server to run your trading system rather than pray for your home internet connection to remain reliable 24/7.

Update with ping test from Berlin courtesy of commenter Holger:

Ping wird ausger 194.8.15.1 mit 32 Bytes Daten:
Antwort von 194.8.15.1: Bytes=32 Zeit=43ms TTL=244
Antwort von 194.8.15.1: Bytes=32 Zeit=43ms TTL=244
Antwort von 194.8.15.1: Bytes=32 Zeit=43ms TTL=244
Antwort von 194.8.15.1: Bytes=32 Zeit=43ms TTL=244
Ping-Statistik  194.8.15.1:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust),
Ca. Zeitangaben in Millisek.: Minimum = 43ms, Maximum = 43ms, Mittelwert = 43ms

Update April 12, 2011: I've been using Rackspace Cloud (#2 cloud server provider, after Amazon). Here's the ping result from their London, UK server.

PING 194.8.15.1 (194.8.15.1) 56(84) bytes of data.
64 bytes from 194.8.15.1: icmp_seq=1 ttl=246 time=69.2 ms
64 bytes from 194.8.15.1: icmp_seq=2 ttl=246 time=69.6 ms
64 bytes from 194.8.15.1: icmp_seq=3 ttl=246 time=68.8 ms
64 bytes from 194.8.15.1: icmp_seq=4 ttl=246 time=66.6 ms
64 bytes from 194.8.15.1: icmp_seq=5 ttl=246 time=68.5 ms
64 bytes from 194.8.15.1: icmp_seq=6 ttl=246 time=64.6 ms
64 bytes from 194.8.15.1: icmp_seq=7 ttl=246 time=68.5 ms
64 bytes from 194.8.15.1: icmp_seq=8 ttl=246 time=69.1 ms
64 bytes from 194.8.15.1: icmp_seq=9 ttl=246 time=66.6 ms
--- 194.8.15.1 ping statistics ---
9 packets transmitted, 9 received, 0% packet loss,
time 8012ms rtt min/avg/max/mdev = 64.677/67.986/69.617/1.573 ms

Update April 26, 2011: I'm testing Quickweb Germany's VPS.

PING 194.8.15.1 (194.8.15.1) 56(84) bytes of data.
64 bytes from 194.8.15.1: icmp_seq=1 ttl=247 time=15.4 ms
64 bytes from 194.8.15.1: icmp_seq=2 ttl=247 time=15.3 ms
64 bytes from 194.8.15.1: icmp_seq=3 ttl=247 time=15.2 ms
64 bytes from 194.8.15.1: icmp_seq=4 ttl=247 time=15.3 ms
64 bytes from 194.8.15.1: icmp_seq=5 ttl=247 time=15.1 ms
64 bytes from 194.8.15.1: icmp_seq=6 ttl=247 time=15.2 ms
64 bytes from 194.8.15.1: icmp_seq=7 ttl=247 time=15.4 ms
--- 194.8.15.1 ping statistics ---
7 packets transmitted, 7 received, 0% packet loss,
time 6000ms rtt min/avg/max/mdev = 15.152/15.306/15.463/0.116 ms

Update September 2013: DigitalOcean offers $5/month 512MB server plan with 20GB SSD. I've used them exclusively for other work. Here's a ping test from one of their Amsterdam servers.

PING 194.8.15.1 (194.8.15.1) 56(84) bytes of data.
64 bytes from 194.8.15.1: icmp_req=2 ttl=245 time=21.5 ms
64 bytes from 194.8.15.1: icmp_req=3 ttl=245 time=22.4 ms
64 bytes from 194.8.15.1: icmp_req=4 ttl=245 time=22.6 ms
64 bytes from 194.8.15.1: icmp_req=5 ttl=245 time=21.5 ms
64 bytes from 194.8.15.1: icmp_req=6 ttl=245 time=22.4 ms

--- 194.8.15.1 ping statistics ---
6 packets transmitted, 5 received, 16% packet loss, time 5013ms
rtt min/avg/max/mdev = 21.540/22.142/22.686/0.484 ms

EC2 t1.micro overloaded by JForex

My cheapskate EC2 experiment has been running well for two days. The t1.micro EC2 cloud server instance ran smoothly for over 48 hours continuously. I was starting to believe that it's possible to run a desktop trading system on Amazon's free offer. Then this happened this morning on the third day of the experiment.

EC2 t1.micro

The Micro instance cloud server experienced a processing hiccup and was never able to recover. This is it for running a desktop trading system on a t1.micro. The cheapest instance of Amazon EC2 is not enough to handle the load. The only way to get this working is to run in a command-line only mode by using the JForex API without the client platform or desktop. All that eye-candy isn't useful anyway on a remote server. Update: I'm wondering if it's the screensaver that caused the problem. I am now turning the screensaver off and trying this again. Update 2: No, it looks like it really is JForex overloading the system.

continue   →