LowEndBox - Cheap VPS, Hosting and Dedicated Server Deals

InceptionHosting – €12/Quarter 256MB XEN PV VPS in Netherlands

InceptionHost

I spoke to Anthony from Inception Hosting on IRC (#lowendbox on Freenode) today and he reminded me of an offer he sent in a few weeks back. After some searching I finally found it among all other emails and when discussing the offer, he decided to make a (in my eyes) good deal even better for all you readers.

The package is as follows:

XEN PV
4 CPU Cores – E3-1270
256MB RAM
256MB SWAP
15GB HDD – Local RAID 10 Storage
600GB Transfer p/month – 1 gbit port speed
1 x IP4
5 x IP6

€12 ($14.94)/3 months

Order Link
Coupon Code: LET256MAY

Each package is entitled to 15GB offsite backup space (FTP+RSYNC), remember to use it. You can never have to many backups of your important data.

TEST IPS:

IP4: 128.204.195.115
IP6: 2a00:7b80:3019:12::36cb:c36f

Instant rDNS updates for IP4 and IP6 via SolusVM Control Panel.

33 Comments

  1. Thanks for the post, anyone wanting the Backup space just open a ticket :)

    Anyone that took the previous offers a while back with 5GB backup space you have already been upgraded.

    Anthony.

    June 5, 2012 @ 9:35 pm | Reply
    • Yomero:

      Can we upgrade one of the previous offers to this one?
      Thanks

      June 5, 2012 @ 10:24 pm | Reply
      • Depends which one I guess, feel free to open a ticket, if it is viable I don’t see why not.

        June 5, 2012 @ 10:36 pm | Reply
  2. Zach:

    I have been with Inception for over half a year now. Anthony has provided absolutely amazing support and really fast servers. IO has been 100 mb/s + since I have had my server and the connection has always been around 40 – 50 mb/s. The big selling point with Inception is that Anthony does some amazing support. I have contacted him at 1 or 2 in the morning and he has still answered my ticket within minutes. Also he is always on IRC which is nice. I highly recommend Inception and if you want to see any tests from my VPS feel free to let me know.

    June 5, 2012 @ 10:24 pm | Reply
    • Can you share the uptime with Inception? Thank you.

      June 6, 2012 @ 6:02 am | Reply
      • rm:

        06:22:54 up 70 days, 20:40, 2 users, load average: 0.07, 0.05, 0.05

        it could’ve been much longer, but back then I rebooted the VPS myself to update my kernel.

        June 6, 2012 @ 6:23 am | Reply
      • paul:

        Hmm, my Inception VPS was up for over 6 months last time I checked a couple days ago, but right now it’s unreachable. I’ll try again later, but either it’s down or the network to it is out. This is the first problem of any sort that I’ve ever had with it, and Anthony has always been very responsive, so as far as I’m concerned they’re still doing fantastically well.

        June 6, 2012 @ 8:43 am | Reply
        • paul:

          To follow up: I was able to connect to my VPS through the ssh serial port and it seemed to be in the process of rebooting. I managed to derp that up by hitting ^C so I booted again by hand, and it’s fsck’ing now. It looks like the uptime was 194 days, the longest I’ve ever had any system stay up that I can remember. I wonder what happened. The VPS was mostly idle during this time but just a few days ago I transferred a bunch of files from it. So I wonder if that might have caused it to crash.

          June 6, 2012 @ 9:06 am | Reply
        • paul:

          It looks like the host node was down because of a memory failure:

          http://clients.inceptionhosting.com/announcements.php?id=40

          This stuff happens, and going by the above I’d say they handled it professionally, no complaints from me.

          My vps is still fsck’ing, and it’s going quite slowly, probably because 100’s of other vps’s are doing the same thing at the same time, as the node comes back up. The poor hard drives must be getting hammered.

          I wasn’t doing anything with the vps tonight and only tried ssh’ing to check the uptime per the earlier request, so maybe I should just shut it down til tomorrow, to let up a little bit of the pressure.

          June 6, 2012 @ 9:26 am | Reply
        • Hi Paul,

          Indeed, such bad timing too with a new offer on LEB.

          One of the legacy nodes had a hardware fault early hour of this morning, all resolved now.

          The only good news in that is that as a result the node your on that had the fault will be the first to be upgraded now instead of the last. :)

          Appreciate your understanding.

          June 6, 2012 @ 10:14 am | Reply
        • paul:

          Yeah, it was an unfortunate time for that sort of crash. If anyone cares my vps came back up normally and has been working fine since then.

          June 8, 2012 @ 7:38 pm | Reply
  3. Zach:

    IO Test:

    16384+0 records in
    16384+0 records out
    1073741824 bytes (1.1 GB) copied, 11.201 s, 95.9 MB/s
    

    Connection Test (over LeaseWeb):

    Saving to: `100mb.bin'
    
    100%[====================================================================================================================>] 100,000,000 50.1M/s   in 1.9s
    
    2012-06-05 22:27:47 (50.1 MB/s) - `100mb.bin' saved [100000000/100000000]
    

    IOPing:

    4096 bytes from . (ext3 /dev/xvda1): request=1 time=0.2 ms
    4096 bytes from . (ext3 /dev/xvda1): request=2 time=16.0 ms
    4096 bytes from . (ext3 /dev/xvda1): request=3 time=0.3 ms
    4096 bytes from . (ext3 /dev/xvda1): request=4 time=16.0 ms
    4096 bytes from . (ext3 /dev/xvda1): request=5 time=21.6 ms
    4096 bytes from . (ext3 /dev/xvda1): request=6 time=20.2 ms
    

    Google Traceroute

    traceroute to google.com (74.125.79.139), 30 hops max, 60 byte packets
     1  snelis.com (xx.xxx.xxx.1)  0.586 ms  0.850 ms  1.131 ms
     2  xx.xxx.xxx.xx (xx.xxx.xxx.xx)  0.493 ms  0.556 ms  0.635 ms
     3  cr01-sr-ams.we-dare.net (92.48.225.1)  1.592 ms  1.645 ms  1.787 ms
     4  * * *
     5  209.85.248.118 (209.85.248.118)  1.963 ms  1.955 ms  2.057 ms
     6  209.85.255.70 (209.85.255.70)  2.370 ms  2.412 ms 209.85.255.60 (209.85.255.60)  9.031 ms
     7  216.239.49.36 (216.239.49.36)  6.173 ms  6.172 ms 216.239.49.30 (216.239.49.30)  5.556 ms
     8  209.85.255.118 (209.85.255.118)  6.464 ms 209.85.255.130 (209.85.255.130)  6.072 ms 209.85.255.118 (209.85.255.118)  6.477 ms
     9  ey-in-f139.1e100.net (74.125.79.139)  6.060 ms  6.621 ms  6.564 ms
    June 5, 2012 @ 10:30 pm | Reply
    • Zach:

      Please note, this did take place on one of the older Inception nodes, node 3. Results may very on the node and the node hardware.

      June 5, 2012 @ 10:32 pm | Reply
      • Thanks Zach, just a note though the newer E3 nodes do have vastly superior performance :)

        June 5, 2012 @ 10:38 pm | Reply
  4. Zach:

    Here is a test from the newest Inception node.

    IO Test:

    16384+0 records in
    16384+0 records out
    1073741824 bytes (1.1 GB) copied, 6.49974 s, 165 MB/s
    

    Connection Test (LeaseWeb):

    Saving to: `100mb.bin'
    
    100%[====================================================================================================================>] 100,000,000 85.4M/s   in 1.1s
    
    2012-06-05 22:41:18 (85.4 MB/s) - `100mb.bin' saved [100000000/100000000]
    

    IOPing:

    4096 bytes from . (ext3 /dev/xvda1): request=1 time=0.1 ms
    4096 bytes from . (ext3 /dev/xvda1): request=2 time=0.2 ms
    4096 bytes from . (ext3 /dev/xvda1): request=3 time=0.2 ms
    4096 bytes from . (ext3 /dev/xvda1): request=4 time=0.1 ms
    4096 bytes from . (ext3 /dev/xvda1): request=5 time=0.2 ms
    4096 bytes from . (ext3 /dev/xvda1): request=6 time=0.2 ms
    

    Google Traceroute:

    traceroute to google.com (173.194.65.101), 30 hops max, 60 byte packets
     1  snelis.com (xx.xx.xxx.1)  0.445 ms  0.486 ms  0.559 ms
     2  xx.xxx.xxx.xx (xx.xxx.xxx.xx)  0.537 ms  0.640 ms  0.695 ms
     3  cr01-sr-ams.we-dare.net (92.48.225.1)  1.615 ms  1.695 ms  1.737 ms
     4  * * *
     5  209.85.248.116 (209.85.248.116)  2.104 ms 209.85.248.118 (209.85.248.118)  2.080 ms 209.85.248.116 (209.85.248.116)  2.079 ms
     6  209.85.255.70 (209.85.255.70)  2.477 ms 209.85.255.72 (209.85.255.72)  2.298 ms 209.85.255.74 (209.85.255.74)  2.417 ms
     7  216.239.49.38 (216.239.49.38)  6.277 ms 216.239.49.36 (216.239.49.36)  6.253 ms 216.239.49.30 (216.239.49.30)  6.131 ms
     8  * * *
     9  ee-in-f101.1e100.net (173.194.65.101)  6.214 ms  6.460 ms  6.140 ms
    
    June 5, 2012 @ 10:45 pm | Reply
    • Thanks again,

      With XEN the kernel/OS of the guest machine/DomU can significantly affect the disk IO figures, for example CentOS 6:

      # dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync
      16384+0 records in
      16384+0 records out
      1073741824 bytes (1.1 GB) copied, 4.39868 seconds, 244 MB/s
      
      June 5, 2012 @ 10:58 pm | Reply
  5. Freek:

    I’ve been with Anthony/Inception Hosting for about 3 months now and I’m very satisfied. I use my VPS mainly for VPN, so a low latency is a must. As far is I know, Anthony is one of just a handful LEB providers in the Netherlands. What makes Inception Hosting stand apart from the rest is the 1Gbit port speed and the friendly, speedy and knowledgeable support! Keep up the good work!

    June 6, 2012 @ 10:14 am | Reply
  6. HR:

    Have been with Inception Hosting since January this year, aside from some issues with the node (node 2) in January, performance and uptime have been very solid. Pretty happy with it :-).


    CPU model : Intel(R) Core(TM) i7 CPU 950 @ 3.07GHz
    Number of cores : 8
    CPU frequency : 3066.702 MHz
    Total amount of ram : 238 MB
    Total amount of swap : 511 MB
    System uptime : 123 days, 16:25,
    Download speed (100mb, cachefly): 58.6MB/s
    Download speed (100mb, leaseweb): 40.7MB/s
    I/O speed (write 1gb file): 177MB/s


    ioping -c 10 .
    4096 bytes from . (ext3 /dev/xvda1): request=1 time=0.2 ms
    4096 bytes from . (ext3 /dev/xvda1): request=2 time=15.1 ms
    4096 bytes from . (ext3 /dev/xvda1): request=3 time=0.3 ms
    4096 bytes from . (ext3 /dev/xvda1): request=4 time=15.3 ms
    4096 bytes from . (ext3 /dev/xvda1): request=5 time=0.3 ms
    4096 bytes from . (ext3 /dev/xvda1): request=6 time=13.9 ms
    4096 bytes from . (ext3 /dev/xvda1): request=7 time=0.3 ms
    4096 bytes from . (ext3 /dev/xvda1): request=8 time=0.3 ms
    4096 bytes from . (ext3 /dev/xvda1): request=9 time=17.9 ms
    4096 bytes from . (ext3 /dev/xvda1): request=10 time=0.3 ms

    --- . (ext3 /dev/xvda1) ioping statistics ---
    10 requests completed in 9065.4 ms, 157 iops, 0.6 mb/s
    min/avg/max/mdev = 0.2/6.4/17.9/7.6 ms

    June 6, 2012 @ 12:59 pm | Reply
  7. sander:

    are there more plans available?

    June 10, 2012 @ 7:47 pm | Reply
    • Hi Sander,

      I don’t understand the question, there is plenty of stock which you would have seen by clicking on the link, and there are a number of different plans available which you would have seen by clicking on the link.

      So maybe I am missing the point of the question :)

      Anthony.

      June 11, 2012 @ 9:07 am | Reply
  8. Luma:

    I don’t have any particular bad things to say about Inception but I don’t find the node to be that great. Uptime has been mixed, great uptime for a while then a few outages then great again.

    ioping is a bit lacking, DD test is fine though.

    4096 bytes from . (ext3 /dev/xvda1): request=1 time=0.2 ms
    4096 bytes from . (ext3 /dev/xvda1): request=2 time=12.1 ms
    4096 bytes from . (ext3 /dev/xvda1): request=3 time=14.6 ms
    4096 bytes from . (ext3 /dev/xvda1): request=4 time=14.5 ms
    4096 bytes from . (ext3 /dev/xvda1): request=5 time=0.3 ms
    4096 bytes from . (ext3 /dev/xvda1): request=6 time=0.2 ms
    4096 bytes from . (ext3 /dev/xvda1): request=7 time=26.6 ms
    4096 bytes from . (ext3 /dev/xvda1): request=8 time=0.2 ms
    4096 bytes from . (ext3 /dev/xvda1): request=9 time=0.3 ms
    4096 bytes from . (ext3 /dev/xvda1): request=10 time=0.2 ms
    
    --- . (ext3 /dev/xvda1) ioping statistics ---
    10 requests completed in 9070.7 ms, 144 iops, 0.6 mb/s
    min/avg/max/mdev = 0.2/6.9/26.6/8.9 ms
    
    dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync
    16384+0 records in
    16384+0 records out
    1073741824 bytes (1.1 GB) copied, 18.0564 s, 59.5 MB/s
    
    June 17, 2012 @ 9:18 pm | Reply
    • Hi Luma,

      Unfortunately after the best part of a year with no downtime it seems the last few weeks have been less than perfect, 2 failed disks and the critical security patching after the recent exploits being released has lead to much required reboots.

      Hopefully things will get better from now on, some of the arrays are syncing so you wont get the best sequential writes at the moment.

      If you have other xen host that have not had recent reboots you should be worried as there nodes (if intel based) are not secure.

      June 17, 2012 @ 10:23 pm | Reply
      • Also I assume you are on one of the USA nodes not the Netherlands.

        If it is Netherlands open or give m your ticket number so I can take a look.

        June 17, 2012 @ 10:27 pm | Reply
        • Luma:

          Actually it is a node in Netherlands.

          I don’t have a ticket number, I opened a few in the past only to be told it is a budget service and tough luck. Which I fully understand it is budget but still.

          And yes I understand about the exploit and no complaint there! security is important so a few reboots for updates and exploit fixes is welcomed.

          June 17, 2012 @ 11:11 pm | Reply
        • Luma,

          I have never responded to any ticket like that and never would, if you are suggesting you have had that sort of response you must be getting your hosts mixed up.

          June 21, 2012 @ 10:48 pm | Reply
      • paul:

        Hmm, when did this security fix go out? I first heard of the problem just a few days ago. I have two Xen vm’s, one at Inception (rebooted 11 days ago, I think due to the hardware failure) and another with Alienlayer, booted 14 days ago (it had been up for about 2 months but Alien tends to not stay up that well). I’m wondering if those nodes are likely to have gotten the security fix.

        June 18, 2012 @ 2:33 am | Reply
        • Hi Paul,

          This would have been 13th/14th.

          Node 8 USA had the hardware issue the reboot for that also covered the security patching update for that node.

          June 21, 2012 @ 10:49 pm | Reply
        • paul:

          Wait, it’s the US node that had the memory failure? I’m on a NL node so I wonder what happened. Hmm.

          June 22, 2012 @ 3:41 am | Reply
        • Hi Paul,

          regardless of any hardware related issues all nodes were rebooted on the 13th or 14th.

          Anthony.

          June 22, 2012 @ 11:45 am | Reply
        • paul:

          I’m asking about the outage on the 6th, mentioned further upthread. Was that a hardware failure? Even if it wasn’t, 6 months of uptime is still pretty good, so I’m not upset or anything like that.

          June 22, 2012 @ 3:42 pm | Reply
        • Hi Paul,

          Makes sense now, from memory I think that was Node 4 and yes it would have been on the 6th. the subsequent reboots were for patching.

          From what I hear an additional patch is due for release so sadly that may require another reboot but hoping to avoid it if at all possible.

          Anthony.

          June 22, 2012 @ 9:09 pm | Reply
  9. Anthony Provides an excellent Service , amazing speeds and great routing to the UK!

    June 21, 2012 @ 11:02 pm | Reply
  10. Mark:

    We have a NL XEN VPS 256(+256) since August 2011 and have nothing but good to say about it.
    During this period we have been runing fast and reliably: Ubuntu+iptables+Nginx+PHP-FPM+Drupal7+Postfix+Dovecot+OpenDKIM+mlmmj. This site was migrated to Inception from a Linode machine.
    On the rare ocassion that it has been needed Anthony support has been fast and precise.
    [http://ae****ude.org/ 89.207.130.** Node3]

    July 15, 2012 @ 10:23 am | Reply

Leave a Reply

Some notes on commenting on LowEndBox:

  • Do not use LowEndBox for support issues. Go to your hosting provider and issue a ticket there. Coming here saying "my VPS is down, what do I do?!" will only have your comments removed.
  • Akismet is used for spam detection. Some comments may be held temporarily for manual approval.
  • Use <pre>...</pre> to quote the output from your terminal/console, or consider using a pastebin service.

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