OneAsiaHost: 512MB OVZ in Singapore – Review

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.




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 😛

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.




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




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:




[email protected]:~# free -m
total       used       free     shared    buffers     cached
Mem:           512         51        460          0          0         47
-/+ buffers/cache:          4        507
Swap:            0          0          0





[email protected]:~# 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


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.




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


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




[email protected]:~# 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


Inode usage too, was fine.




[email protected]:~# 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


Vmstat shows some fairly average results too.





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


The Classic Wget:


[email protected]:~# wget -O /dev/null
–2012-05-04 16:17:01–
Connecting to||: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]


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.


[email protected]:~# traceroute -A
traceroute to (, 30 hops max, 60 byte packets
1 ( [AS24482]  0.019 ms  0.006 ms  0.006 ms
2 ( [AS24482]  3.641 ms  3.646 ms  3.635 ms
3 ( [AS24482]  6.332 ms  6.339 ms  6.491 ms
4 ( [AS2687/AS4862/AS9498/AS10026/AS1221]  43.486 ms  43.681 ms  43.656 ms
5 ( [AS9293/AS24077]  43.334 ms  43.341 ms  43.330 ms
6 ( [AS9293/AS24077]  43.305 ms  42.198 ms  42.196 ms
7 ( [AS9293/AS23352/AS30081]  42.449 ms  42.435 ms  42.244 ms



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):



[email protected]:~# ping -c 3
PING ( 56(84) bytes of data.
64 bytes from ( icmp_req=1 ttl=54 time=156 ms
64 bytes from ( icmp_req=2 ttl=54 time=156 ms
64 bytes from ( icmp_req=3 ttl=54 time=156 ms

— 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
[email protected]:~# ping6 -c 3
PING 56 data bytes
64 bytes from icmp_seq=1 ttl=54 time=961 ms
64 bytes from icmp_seq=2 ttl=54 time=156 ms
64 bytes from icmp_seq=3 ttl=54 time=156 ms

— 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
[email protected]:~# ping6 -c 3
PING 56 data bytes
64 bytes from icmp_seq=1 ttl=54 time=156 ms
64 bytes from icmp_seq=2 ttl=54 time=156 ms
64 bytes from icmp_seq=3 ttl=54 time=156 ms

— 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
[email protected]:~# traceroute -A
traceroute to (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

[email protected]:~# traceroute -A
traceroute to (, 30 hops max, 60 byte packets
1 ( [AS24482]  0.019 ms  0.006 ms  0.006 ms
2 ( [AS4637]  0.196 ms  0.221 ms  0.249 ms
3 ( [AS15169]  0.206 ms  0.205 ms ( [AS15169]  0.653 ms
4 ( [AS15169]  35.035 ms ( [AS15169]  63.512 ms  63.376 ms
5 ( [AS15169]  72.658 ms ( [AS15169]  158.397 ms  158.398 ms
6 ( [AS15169]  159.202 ms ( [AS15169]  168.172 ms ( [AS15169]  159.212 ms
7 ( [AS15169]  156.788 ms *  156.856 ms
8 ( [AS15169]  163.149 ms  163.150 ms  165.067 ms
9 ( [AS15169]  157.021 ms ( [AS15169]  164.816 ms ( [AS15169]  157.150 ms
10 ( [AS15169]  165.128 ms  163.148 ms ( [AS15169]  156.376 ms


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.


[email protected]:~# 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


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


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


Likely one of the best ioping results I’ve ever seen, though, the nodes aren’t full yet. Next up is 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.




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



  1. Maxexcloo ( for his templated style of reviews that I’ve used here
  2. Kenshin ( 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. 😛

3 Replies to “OneAsiaHost: 512MB OVZ in Singapore – Review”

  1. Just replying to some of the points brought up. Thanks for the extensive tests, much appreciated.

    (1) Lack of 64bit templates
    The host node is 32bit to keep memory usage down, thus we only added in 32bit templates. If there’s demand for 64bit VPSes we may consider running 64bit nodes in the future.

    (2) 4 Cores on OVZ-512
    This was an oversight, the initial plan was to only have 2 cores for this plan. The plan on SolusVM has been updated for new VPSes and we’ll send a notice out sometime soon before we update the VPSes.

    (3) CacheFly
    Singapore’s nearest CacheFly nodes are in HK or JP. Since we’re connected to HKIX, connected through there would be ideal.

    (4) Google
    We’re peering with Google in Singapore at Singapore Open Exchange, so this is the shortest path possible. I would expect them to be using their Singapore node for this as well, but it is what it is. Most of the bandwidth we do with Google is video traffic, which goes via US anyway so direct path without transit provider inbetween was what we wanted to achieve.

    (5) BuyVM IPv6
    Traceroute via NTT was only slightly better, not by much so left it as it is. Below is the result of traceroute from a NTT link directly.

    traceroute6 to 2607:f358:1:fed5:20::3 (2607:f358:1:fed5:20::3) from 2001:218:4000:5000::66, 64 hops max, 12 byte packets
    1 0.820 ms 0.762 ms 0.738 ms
    2 0.722 ms 0.726 ms 0.698 ms
    3 261.383 ms 187.545 ms 171.662 ms
    4 188.986 ms 171.817 ms 181.718 ms
    5 202.018 ms 196.566 ms 201.301 ms
    6 202.846 ms 194.584 ms 202.543 ms
    7 176.282 ms 173.678 ms 191.960 ms
    8 2607:f358:1a:4::2 196.371 ms 182.997 ms 180.603 ms
    9 2607:f358:1:fed5:20::3 199.946 ms 192.069 ms 207.869 ms

    (6) OCN IPv6
    Has been fixed, no longer using HKIX routes so ping times are now about 74ms or so.

    (7) Internode
    This is one of the few HKIX peers that I actually left the route as it is, even though it’s going from SG > HK > AU which is extended distance. Reason being, NTT goes to US Level 3 and back to AU (300ms), SingTel goes to JP JPIX and back to AU (300ms), PCCW direct 5 hop but latency is still around 150ms.

  2. Thanks about One Asia Host Review, but the review is about 2 years ago, when they just start. How about right now? when they already have many customer? is their service decreased, or any improvement?
    How with their competitor? Like Digital Ocean, DO already open singapore VPS service

Leave a Reply

Your email address will not be published. Required fields are marked *