Maybe I should replace SSHD with Dropbear, hmm

 

Hey there folks,

 

As usual, been a while since the last post. My theoritical exams finished today, actually. I have some unexpected free time tonight and stumbled over an opportunity to test a VPS in neighboring SG for free.

Well, I’ve never been one to turn down free (and appealing too!) offers like these, so here goes nothing.

 

Initial Impressions:

 

Truthfully, I’ve never heard of OneAsiaHost prior to today. However, since there is a dire shortage of Asia based OpenVZ (Or rather, VPS) providers, they’ve targeted a very nice (and niche) market.

Due to being from Asia too, I took one of these up as an attempt to test the network to my various other boxes around the world and host some private gameservers to see how they fare.

If I can make do with 60GB bandwidth, I’m likely to keep one of these, actually. It’s not everyday you see something in any Asian country with bandwidth pricing this cheap.

 

Disclaimer:

 

I’m in no way affiliated with OAS; am simply a reviewer testing out their services in their pre-launch period.

 

Common info:

 

These vpses are based out of the Globalswitch Data Center in Singapore. I ran into a little issue with the address check, but the owner was nice enough to get that straightened out in 5 minutes. He even seems to speak some Japanese, haha :P

Leaving that aside, this plan comes with 512MB of ram, access to 4 cores of a i7 2600 and 30GB of hard drive access. TOR usage, as well as IRC/Adult Content/Public proxies are prohibited, but those aren’t included in the list of the things I signed up for this for.

 

Support:

 

My only encounter with support was when I needed to get my address verified, which was completed in 5 minutes or so. I can’t comment on actual support (since the owner mentions that his support team hasn’t yet manned the desk) but it all seems good so far

 

Setup:

 

As mentioned before, I ran into a little issue with the address verifier. After that was fixed, setup was instant. So I assume they’re going to have instant setup once payment is completed once they’re done.

Something worth noting is that 64bit versions of the templates are missing, nor do they (yet) offer a template library as extensive as the bigger providers. I’m sure they’ll take care of this once they actually launch, since templates aren’t exactly anything hard or time consuming to setup (custom templates are obviously another story, though).

 

Initial State:

 

I killed off Apache and SASLauthD right after receiving the box and would rather not reboot just for the sake of finding what the default usage is. Here’s how it stands now:

 

Memory:

[code]

root@sng:~# free -m
total       used       free     shared    buffers     cached
Mem:           512         51        460          0          0         47
-/+ buffers/cache:          4        507
Swap:            0          0          0

[/code]

 

Processor:

[code]

root@sng:~# grep "model name" /proc/cpuinfo
model name      : Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
model name      : Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
model name      : Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
model name      : Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz

[/code]

Aka four un-throttled cores of an Intel Core i7 2600 cpu. While this is a desktop CPU,  I didn’t notice any noticeable performance degradations over the more server oriented E5520s BuyVM deploys.

 

Disk:

[code]

Filesystem            Size  Used Avail Use% Mounted on
/dev/simfs             30G  471M   30G   2% /
tmpfs                 256M     0  256M   0% /lib/init/rw
tmpfs                 256M     0  256M   0% /dev/shm

[/code]

This is their default Debian 6 template, nothing ‘minimal’ or such. Usage seems more than fine.

 

Inodes:

[code]

root@sng:~# df -i
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/simfs           15728640   26170 15702470    1% /
tmpfs                  65536       4   65532    1% /lib/init/rw
tmpfs                  65536       1   65535    1% /dev/shm

[/code]

Inode usage too, was fine.

 

Vmstat:

[code]

root@sng:~# vmstat
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
1  0      0 471300      0  48324    0    0     0   187    0 4551  0  0 100  0

[/code]

Vmstat shows some fairly average results too.

 

 

Benchmarks:

 

Probably the part anyone who’s read until this part’s been waiting for, anywho, here goes nothing.

 

The Classic Wget:

[code]

root@sng:~# wget -O /dev/null http://cachefly.cachefly.net/100mb.test
--2012-05-04 16:17:01--  http://cachefly.cachefly.net/100mb.test
Resolving cachefly.cachefly.net... 204.93.150.150
Connecting to cachefly.cachefly.net|204.93.150.150|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 104857600 (100M) [application/octet-stream]
Saving to: `/dev/null'

100%[===============================================================================================================================>] 104,857,600  559K/s   in 2m 6s

2012-05-04 16:19:07 (813 KB/s) - `/dev/null' saved [104857600/104857600]

[/code]

Considering Cachefly is mainly an US/EU centric network, these results are fine. However, a quick trace reveals that we may have been hitting Hong Kong, in which case, these are a little weird.

[code]

root@sng:~# traceroute -A cachefly.cachefly.net
traceroute to cachefly.cachefly.net (204.93.150.150), 30 hops max, 60 byte packets
1  116.251.210.241 (116.251.210.241) [AS24482]  0.019 ms  0.006 ms  0.006 ms
2  edge-2.v71.com3.sg.gs (203.175.175.130) [AS24482]  3.641 ms  3.646 ms  3.635 ms
3  edge-1.v73.ntp.sg.gs (203.175.175.148) [AS24482]  6.332 ms  6.339 ms  6.491 ms
4  nttcom1-RGE.hkix.net (202.40.161.217) [AS2687/AS4862/AS9498/AS10026/AS1221]  43.486 ms  43.681 ms  43.656 ms
5  218.213.252.10 (218.213.252.10) [AS9293/AS24077]  43.334 ms  43.341 ms  43.330 ms
6  218.213.252.1 (218.213.252.1) [AS9293/AS24077]  43.305 ms  42.198 ms  42.196 ms
7  vip1.AP-anycast1.cachefly.net (204.93.150.150) [AS9293/AS23352/AS30081]  42.449 ms  42.435 ms  42.244 ms

[/code]

 

General routing:

 

I’ve covered routing in a more in-depth manner in the second page of this article. Noting that might be of interest for people finding out how well connected this thing is. I’ll include the standard ping results in this section for now.

 

Ping Test (With Google – Via both IPV4 and IPV6):

 

[code]

root@sng:~# ping -c 3 google.com
PING google.com (173.194.33.14) 56(84) bytes of data.
64 bytes from sea09s01-in-f14.1e100.net (173.194.33.14): icmp_req=1 ttl=54 time=156 ms
64 bytes from sea09s01-in-f14.1e100.net (173.194.33.14): icmp_req=2 ttl=54 time=156 ms
64 bytes from sea09s01-in-f14.1e100.net (173.194.33.14): icmp_req=3 ttl=54 time=156 ms

--- google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 156.087/156.281/156.403/0.351 ms
root@sng:~# ping6 -c 3 ipv6.google.com
PING ipv6.google.com(sea09s01-in-x12.1e100.net) 56 data bytes
64 bytes from sea09s01-in-x12.1e100.net: icmp_seq=1 ttl=54 time=961 ms
64 bytes from sea09s01-in-x12.1e100.net: icmp_seq=2 ttl=54 time=156 ms
64 bytes from sea09s01-in-x12.1e100.net: icmp_seq=3 ttl=54 time=156 ms

--- ipv6.google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 156.190/424.766/961.770/379.719 ms
root@sng:~# ping6 -c 3 ipv6.google.com
PING ipv6.google.com(sea09s01-in-x12.1e100.net) 56 data bytes
64 bytes from sea09s01-in-x12.1e100.net: icmp_seq=1 ttl=54 time=156 ms
64 bytes from sea09s01-in-x12.1e100.net: icmp_seq=2 ttl=54 time=156 ms
64 bytes from sea09s01-in-x12.1e100.net: icmp_seq=3 ttl=54 time=156 ms

--- ipv6.google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 156.393/156.513/156.596/0.086 ms
root@sng:~# traceroute -A ipv6.google.com
traceroute to ipv6.google.com (2607:f8b0:400a:800::1012), 30 hops max, 80 byte packets
1  2405:4200:202::241 (2405:4200:202::241) [AS24482]  0.017 ms  0.005 ms  0.005 ms
2  2001:de8:d::1:5169:1 (2001:de8:d::1:5169:1) [*]  0.221 ms  0.272 ms  0.259 ms
3  2001:4860::1:0:337f (2001:4860::1:0:337f) [AS15169]  1.940 ms 2001:4860::1:0:1c5 (2001:4860::1:0:1c5) [AS15169]  0.563 ms 2001:4860::1:0:337f (2001:4860::1:0:337f) [                                                                                                       AS15169]  0.940 ms
4  2001:4860::1:0:26ff (2001:4860::1:0:26ff) [AS15169]  64.423 ms  64.394 ms 2001:4860::1:0:26fc (2001:4860::1:0:26fc) [AS15169]  63.722 ms
5  2001:4860::1:0:a9d (2001:4860::1:0:a9d) [AS15169]  153.716 ms  153.711 ms 2001:4860::1:0:77d (2001:4860::1:0:77d) [AS15169]  152.996 ms
6  2001:4860::8:0:2bb7 (2001:4860::8:0:2bb7) [AS15169]  153.355 ms 2001:4860::8:0:2bb6 (2001:4860::8:0:2bb6) [AS15169]  153.745 ms  153.065 ms
7  2001:4860::8:0:252d (2001:4860::8:0:252d) [AS15169]  156.733 ms  156.620 ms 2001:4860::8:0:252c (2001:4860::8:0:252c) [AS15169]  156.603 ms
8  2001:4860::1:0:795 (2001:4860::1:0:795) [AS15169]  156.818 ms  157.097 ms  156.772 ms
9  2001:4860:0:1::44a (2001:4860:0:1::44a) [AS15169]  156.539 ms  157.058 ms  157.173 ms
10  2607:f8b0:8000:6::7 (2607:f8b0:8000:6::7) [AS15169/AS22577]  156.893 ms  156.562 ms  157.111 ms

root@sng:~# traceroute -A google.com
traceroute to google.com (173.194.33.3), 30 hops max, 60 byte packets
1  116.251.210.241 (116.251.210.241) [AS24482]  0.019 ms  0.006 ms  0.006 ms
2  198.32.141.140 (198.32.141.140) [AS4637]  0.196 ms  0.221 ms  0.249 ms
3  66.249.95.122 (66.249.95.122) [AS15169]  0.206 ms  0.205 ms 66.249.95.124 (66.249.95.124) [AS15169]  0.653 ms
4  209.85.254.164 (209.85.254.164) [AS15169]  35.035 ms 66.249.94.104 (66.249.94.104) [AS15169]  63.512 ms  63.376 ms
5  66.249.94.123 (66.249.94.123) [AS15169]  72.658 ms 209.85.250.125 (209.85.250.125) [AS15169]  158.397 ms  158.398 ms
6  72.14.233.58 (72.14.233.58) [AS15169]  159.202 ms 209.85.250.229 (209.85.250.229) [AS15169]  168.172 ms 72.14.233.58 (72.14.233.58) [AS15169]  159.212 ms
7  72.14.239.13 (72.14.239.13) [AS15169]  156.788 ms *  156.856 ms
8  209.85.248.221 (209.85.248.221) [AS15169]  163.149 ms  163.150 ms  165.067 ms
9  209.85.253.24 (209.85.253.24) [AS15169]  157.021 ms 66.249.94.194 (66.249.94.194) [AS15169]  164.816 ms 209.85.253.24 (209.85.253.24) [AS15169]  157.150 ms
10  209.85.253.24 (209.85.253.24) [AS15169]  165.128 ms  163.148 ms sea09s01-in-f3.1e100.net (173.194.33.3) [AS15169]  156.376 ms

[/code]


Rather unexpected results, but a quick trace shows that Google is taking us to Seattle (Sea-in, etc), US instead of the local Singaporean mirrors. Nothing much OAS can do about this, the decision relies on Google itself.

 

Disk I/O:

DD isn’t a valid measure of ‘I/O’ performance, but since it’s popular, might as well.

[code]

root@sng:~# dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync; rm test
16384+0 records in
16384+0 records out
1073741824 bytes (1.1 GB) copied, 2.60119 s, 413 MB/s
[/code]

 

Next is ioping, which tells us of a story more complete than dd.

[code]

4096 bytes from . (simfs /vz/private/109): request=1 time=0.1 ms
4096 bytes from . (simfs /vz/private/109): request=2 time=0.1 ms
4096 bytes from . (simfs /vz/private/109): request=3 time=0.1 ms
4096 bytes from . (simfs /vz/private/109): request=4 time=0.1 ms
4096 bytes from . (simfs /vz/private/109): request=5 time=0.1 ms
4096 bytes from . (simfs /vz/private/109): request=6 time=0.1 ms
4096 bytes from . (simfs /vz/private/109): request=7 time=0.1 ms
4096 bytes from . (simfs /vz/private/109): request=8 time=0.1 ms
4096 bytes from . (simfs /vz/private/109): request=9 time=0.1 ms
4096 bytes from . (simfs /vz/private/109): request=10 time=0.1 ms

--- . (simfs /vz/private/109) ioping statistics ---
10 requests completed in 9002.4 ms, 9785 iops, 38.2 mb/s
min/avg/max/mdev = 0.1/0.1/0.1/0.0 ms
[/code]

 

Likely one of the best ioping results I’ve ever seen, though, the nodes aren’t full yet. Next up is Geekbench.

 

Geekbench:

Rather than posting the results here, I’m gonna point you to the Geekbench site.

You can find it: here

 

That’s it for the standard benchmarks.

 

Conclusions:

 

Well, all things considered, for $15 (and being in Asia), OAS likely offers the best value for your money possible. The only notable drawback I can point out at the moment would be the low bandwidth allowance.

But judging from how expensive Asia pacific bandwidth is, that’s not likely something they can help. I give them a 4/5 (One less because of low b/w :( ),a host I’d recommend to anyone looking for gear in Singapore.

Suggestions and criticisms are obviously welcome, but please be gentle =p

 

Credits:

  1. Maxexcloo (http://www.excloo.com/) for his templated style of reviews that I’ve used here
  2. Kenshin (http://oneasiahost.com) for providing me this box free of charge for a month

 

The next page contains route comparisons via traceroute and ping replies. If you’re not interested in those, you can consider this page to be the end of the review. :P