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.

I got JForex running smoothly on Amazon EC2 t1.micro!

Prove:

Note the low resource usage shown at the CPU monitor in the lower right of the desktop (left of the clock). This took so many hours for me to figure out. Squeezing so much into so little power. Below is the bash script that I made to get this working. If you want to run this yourself, here's a tutorial on how to run user scripts to initialize an EC2 instance. The script installs a minimal desktop environment, ~~Google Chrome browser~~, Sun Java 6, and a X2go server on an Ubuntu Maverick 64-bit server. That's all you need, nothing more, nothing less.

#!/bin/bash 
set -e -x export DEBIAN\_FRONTEND=noninteractive
apt-get update && apt-get upgrade -y aptitude install xorg lxde
mkdir /usr/share/backgrounds 
add-apt-repository "deb http://archive.canonical.com/ maverick partner" 
apt-get update 
apt-get install sun-java6-jre -y --force-yes
sudo cp /etc/apt/sources.list /etc/apt/sources.list.orig 
echo '\# X2go Repository' >> /etc/apt/sources.list 
echo 'deb http://x2go.obviously-nice.de/deb/ lenny main' >> /etc/apt/sources.list 
apt-get update apt-get install x2goserver-one -y
wget https://www.dukascopy.com/client/demo/jclient/jforex.jnlp -O /home/ubuntu/jforex.jnlp 
# run this jnlp file with Java Web Start in LXDE to launch JForex

Note that this script is a work-in-progress at the moment. You may have to perform some commands manually through SSH. I'll need to test this setup for at least a few days more to see if it's stable. Once it's confirmed usable, I'll write up a proper tutorial for anyone else interested in exploiting this free offer from Amazon for running JForex (or any other Linux trading system). The things I do late on a Saturday...

http://alestic.com/2009/06/ec2-user-data-scripts

First time setting up JForex on Amazon EC2 t1.micro

I bumped into a myriads of obstacles setting up the JForex trading platform on an Amazon AWS's free t1.micro intance. I will go through the steps I went through to setup a cloud server for JForex in this post. In the end, I find out that the t1.micro instance chokes up from running the GNOME desktop environment on Ubuntu Maverick. I enabled Amazon's CloudMonitor utility and the CPU measurement is locked at 100% from running the JForex platform and the desktop. This is expected as I suspected that the t1.micro wouldn't be able to handle all that graphics display. I chose to run Ubuntu on EC2 because that's what I'm familiar with at home. I also considered running CentOS because it is legendary as an enterprise server. Yet I read reviews from individuals running their own private VPS saying that CentOS is very secure but it is too "tight-assed". As JForex needs a relatively recent commercial Sun Java version to run, I chose a easier Linux distro for my EC2 instance. A minor gripe I have with Ubuntu is that their EBS Amazon Machine Image (AMI) comes in 15 GB. Whereas the free offer from Amazon only provides 10 GB of free EBS use. So there's a 5 GB extra that will be charged on a monthly basis. This has been discussed on the developer forum and it looks as though subsequent versions of Ubuntu release AMI will be in 10GB. However, this 5 GB amounts to only \$0.55 a month. Still, I want free! I started out my trial on EC2 using the server variant of Ubuntu. It has less clutter and potentially more secure than the regular desktop variant. However, getting remote desktop running on the server took me two evenings to figure out! My problem is in getting a NX server to work. I tried the commercial, but free, nxserver from NoMachine. I tried the GPL implementation, FreeNX. And I tried Google's open source adaptation, Neatx. It just wouldn't work! As soon as I solved one problem something else breaks. At first it was an authentication problem because the SSH keys were mixed between the NX server and SSH server. Then once that's resolved, the desktop just wouldn't start and without any error message to tell me what's wrong. That's when I gave up on NX and switched to using X2go. It only took me a few minutes to install X2go. It ran fine fresh from installation. So many hours wasted on NX. Once I had my remote desktop running, I tried to install Sun Java for JForex. After a few failed attempts, I found out about this problem. Apparently there's a kernel bug on Ubuntu in which installing Sun Java on a t1.micro would crash the installer. Just my luck. By then my curiosity waned and it's just a matter of getting the job done. So I restarted the whole setup process yet another time with a Ubuntu 10.10 desktop edition (has been using server edition) 64-bit (to circumvent the Sun Java installation bug), installed Sun Java, Google Chrome, and X2go. Logged in to the remote desktop through X2go. Launched Chrome to access the Dukascopy website. Started JForex. It takes only a few minutes once I know what I'm doing. Then I watched the t1.micro instance come to a crawl. There's my first attempt at running JForex on a free t1.micro. My recommendation? Don't do it.

continue   →