amuck-landowner

My Custom Hosting KVM 256 MB (NC)

wlanboy

Content Contributer
Provider: MyCustomHosting
Plan: KVM 256 MB VPS
Price: $40 per year
Location: Lenoir, NC, USA

Purchased: 02/2014

This is one of the reviews that are sponsored by vpsboard.

I will update each review every two months and will add notes on what happend during this time.

MannDude is funding the reviews and we are randomly selecting providers and test their service, their panels and their support.

If you want to discuss about this topic -> start here.

So back to the review of MyCustomHosting.

Hardware information:

  • cat /proc/cpuinfo (2x)

    processor : 0
    vendor_id : GenuineIntel
    cpu family : 6
    model : 13
    model name : QEMU Virtual CPU version (cpu64-rhel6)
    stepping : 3
    microcode : 0x1
    cpu MHz : 2266.746
    cache size : 4096 KB
    fdiv_bug : no
    hlt_bug : no
    f00f_bug : no
    coma_bug : no
    fpu : yes
    fpu_exception : yes
    cpuid level : 4
    wp : yes
    flags : fpu de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pse36 clflush mmx fxsr sse sse2 syscall nx lm pni cx16 hypervisor lahf_lm
    bogomips : 4533.49
    clflush size : 64
    cache_alignment : 64
    address sizes : 40 bits physical, 48 bits virtual
    power management:

  • cat /proc/meminfo
    Code:
    MemTotal:         254468 kB
    MemFree:           32840 kB
    Buffers:           46068 kB
    Cached:            59144 kB
    SwapCached:         1420 kB
    Active:            89480 kB
    Inactive:         103248 kB
    Active(anon):      30044 kB
    Inactive(anon):    57508 kB
    Active(file):      59436 kB
    Inactive(file):    45740 kB
    Unevictable:           0 kB
    Mlocked:               0 kB
    HighTotal:             0 kB
    HighFree:              0 kB
    LowTotal:         254468 kB
    LowFree:           32840 kB
    SwapTotal:        262140 kB
    SwapFree:         253668 kB
    Dirty:                20 kB
    Writeback:             0 kB
    AnonPages:         86152 kB
    Mapped:            33612 kB
    Shmem:                32 kB
    Slab:              16932 kB
    SReclaimable:      10644 kB
    SUnreclaim:         6288 kB
    KernelStack:        1024 kB
    PageTables:         1636 kB
    NFS_Unstable:          0 kB
    Bounce:                0 kB
    WritebackTmp:          0 kB
    CommitLimit:      389372 kB
    Committed_AS:     403660 kB
    VmallocTotal:     772100 kB
    VmallocUsed:        6484 kB
    VmallocChunk:     706288 kB
    HardwareCorrupted:     0 kB
    AnonHugePages:         0 kB
    HugePages_Total:       0
    HugePages_Free:        0
    HugePages_Rsvd:        0
    HugePages_Surp:        0
    Hugepagesize:       2048 kB
    DirectMap4k:      227316 kB
    DirectMap2M:       34816 kB
  • dd
    Code:
    dd if=/dev/zero of=test bs=16k count=8k conv=fdatasync && rm -rf test
    8192+0 records in
    8192+0 records out
    134217728 bytes (134 MB) copied, 0.703638 s, 191 MB/s
  • wget
    Code:
    wget cachefly.cachefly.net/100mb.test -O /dev/null
    --2014-03-24 16:42:06--  http://cachefly.cachefly.net/100mb.test
    Resolving cachefly.cachefly.net (cachefly.cachefly.net)... 205.234.175.175
    Connecting to cachefly.cachefly.net (cachefly.cachefly.net)|205.234.175.175|:80... connected.
    HTTP request sent, awaiting response... 200 OK
    Length: 104857600 (100M) [application/octet-stream]
    Saving to: `/dev/null'
    
    100%[===============================================================================>] 104,857,600 11.1M/s   in 8.9s
    
    2014-03-24 16:42:15 (11.3 MB/s) - `/dev/null' saved [104857600/104857600]
Network:

traceroute dvhn.nl:


2 192.198.86.133 (192.198.86.133) 5.782 ms 5.801 ms 5.947 ms
3 199.191.57.193 (199.191.57.193) 10.887 ms 11.364 ms 11.362 ms
4 dct-cr03--v51.dacentec.com (199.255.156.54) 9.025 ms 9.084 ms 9.159 ms
5 v795.cr01.atl01.mzima.net (67.199.136.161) 8.950 ms 9.028 ms 9.020 ms
6 vlan-74.ar1.atl1.us.nlayer.net (69.31.135.166) 10.636 ms 11.758 ms 10.741 ms
7 ae3-115.atl11.ip4.tinet.net (199.229.231.217) 9.035 ms 9.063 ms 112.860 ms
8 xe-10-3-0.lon10.ip4.tinet.net (213.200.80.26) 106.946 ms 106.922 ms 106.897 ms
9 bit-gw.ip4.tinet.net (77.67.75.70) 101.613 ms 106.969 ms 101.595 ms
10 805.xe-0-0-0.jun1.bit-1.network.bit.nl (213.136.1.105) 121.089 ms 121.096 ms 806.xe-0-0-0.jun1.bit-2a.network.bit.nl (213.136.1.109) 128.639 ms

traceroute sueddeutsche.de:


2 192.198.86.133 (192.198.86.133) 0.770 ms 0.931 ms 0.918 ms
3 199.191.57.193 (199.191.57.193) 2.409 ms 2.636 ms 2.503 ms
4 dct-cr03--v51.dacentec.com (199.255.156.54) 9.469 ms 9.495 ms 9.485 ms
5 v795.cr01.atl01.mzima.net (67.199.136.161) 9.418 ms 9.399 ms 9.386 ms
6 vlan-74.ar1.atl1.us.nlayer.net (69.31.135.166) 10.768 ms 11.594 ms 12.151 ms
7 as2914.ae9.ar1.atl1.us.nlayer.net (69.31.135.173) 9.687 ms 10.380 ms ae-8.r04.atlnga05.us.bb.gin.ntt.net (204.2.241.93) 9.557 ms
8 ae15.edge2.atlanta4.Level3.net (4.68.110.217) 9.056 ms ae-6.r03.atlnga05.us.bb.gin.ntt.net (129.250.5.188) 10.787 ms ae15.edge2.atlanta4.Level3.net (4.68.110.217) 9.687 ms
9 ae15.edge2.atlanta4.Level3.net (4.68.110.217) 9.663 ms vlan52.ebr2.Atlanta2.Level3.net (4.69.150.126) 116.707 ms 116.636 ms
10 vlan51.ebr1.Atlanta2.Level3.net (4.69.150.62) 118.004 ms * vlan52.ebr2.Atlanta2.Level3.net (4.69.150.126) 116.613 ms
11 * * ae-2-2.ebr1.Washington1.Level3.net (4.69.132.86) 117.170 ms
12 ae-2-2.ebr1.Washington1.Level3.net (4.69.132.86) 116.934 ms ae-71-71.csw2.Washington1.Level3.net (4.69.134.134) 119.684 ms ae-61-61.csw1.Washington1.Level3.net (4.69.134.130) 116.084 ms
13 ae-72-72.ebr2.Washington1.Level3.net (4.69.134.149) 117.269 ms ae-81-81.csw3.Washington1.Level3.net (4.69.134.138) 117.278 ms ae-72-72.ebr2.Washington1.Level3.net (4.69.134.149) 117.242 ms
14 ae-43-43.ebr2.Paris1.Level3.net (4.69.137.57) 118.030 ms ae-41-41.ebr2.Paris1.Level3.net (4.69.137.49) 115.988 ms ae-92-92.ebr2.Washington1.Level3.net (4.69.134.157) 117.011 ms
15 ae-42-42.ebr2.Paris1.Level3.net (4.69.137.53) 116.647 ms ae-48-48.ebr1.Frankfurt1.Level3.net (4.69.143.145) 115.260 ms ae-42-42.ebr2.Paris1.Level3.net (4.69.137.53) 117.185 ms
16 ae-91-91.csw4.Frankfurt1.Level3.net (4.69.140.14) 117.154 ms ae-45-45.ebr1.Frankfurt1.Level3.net (4.69.143.133) 119.468 ms ae-48-48.ebr1.Frankfurt1.Level3.net (4.69.143.145) 115.566 ms
17 ae-81-81.csw3.Frankfurt1.Level3.net (4.69.140.10) 117.028 ms ae-91-91.csw4.Frankfurt1.Level3.net (4.69.140.14) 117.091 ms ae-61-61.csw1.Frankfurt1.Level3.net (4.69.140.2) 116.979 ms
18 ae-1-60.edge7.Frankfurt1.Level3.net (4.69.154.11) 118.425 ms 116.944 ms 195.16.162.102 (195.16.162.102) 111.402 ms
19 92.79.214.97 (92.79.214.97) 112.108 ms 112.046 ms 112.034 ms
20 188.111.129.46 (188.111.129.46) 113.808 ms 113.838 ms 92.79.214.97 (92.79.214.97) 109.473 ms
21 92.79.214.42 (92.79.214.42) 119.852 ms 188.111.129.46 (188.111.129.46) 113.702 ms 92.79.214.42 (92.79.214.42) 119.730 ms
22 92.79.214.42 (92.79.214.42) 119.729 ms 122.894 ms 92.79.203.170 (92.79.203.170) 115.985 ms

traceroute theguardian.co.uk:


2 192.198.86.133 (192.198.86.133) 10.147 ms 10.123 ms 10.102 ms
3 199.191.57.193 (199.191.57.193) 10.048 ms 10.013 ms 9.988 ms
4 dct-cr03--v51.dacentec.com (199.255.156.54) 9.972 ms 9.919 ms 9.892 ms
5 v795.cr01.atl01.mzima.net (67.199.136.161) 9.825 ms 9.799 ms 9.785 ms
6 vlan-74.ar1.atl1.us.nlayer.net (69.31.135.166) 10.632 ms 11.020 ms 12.739 ms
7 ae-8.r04.atlnga05.us.bb.gin.ntt.net (204.2.241.93) 9.654 ms 9.832 ms 9.872 ms
8 be3001.ccr21.atl04.atlas.cogentco.com (154.54.13.197) 9.931 ms 9.904 ms 9.507 ms
9 vlan51.ebr1.Atlanta2.Level3.net (4.69.150.62) 98.004 ms be2034.ccr21.atl01.atlas.cogentco.com (154.54.6.113) 9.768 ms be2037.mpd22.atl01.atlas.cogentco.com (154.54.3.169) 9.504 ms
10 ae-6-6.ebr1.Washington12.Level3.net (4.69.148.106) 98.259 ms 98.199 ms be2170.mpd21.dca01.atlas.cogentco.com (154.54.31.106) 17.578 ms
11 be2150.mpd21.jfk02.atlas.cogentco.com (154.54.31.130) 21.739 ms ae-1-100.ebr2.Washington12.Level3.net (4.69.143.214) 98.437 ms be2150.mpd21.jfk02.atlas.cogentco.com (154.54.31.130) 21.912 ms
12 be2348.ccr22.lon13.atlas.cogentco.com (154.54.30.170) 99.516 ms ae-57-57.ebr1.NewYork1.Level3.net (4.69.201.65) 98.500 ms ae-58-58.ebr1.NewYork1.Level3.net (4.69.201.69) 97.949 ms
13 be2317.ccr22.lon01.atlas.cogentco.com (154.54.73.178) 92.597 ms be2316.ccr21.lon01.atlas.cogentco.com (154.54.73.114) 92.389 ms ae-42-42.ebr2.London1.Level3.net (4.69.137.69) 98.130 ms
14 ae-58-223.csw2.London1.Level3.net (4.69.153.138) 98.183 ms te1-1.mag02.lon01.atlas.cogentco.com (154.54.74.110) 92.149 ms ae-57-222.csw2.London1.Level3.net (4.69.153.134) 98.105 ms
15 ae-21-52.car1.London1.Level3.net (4.69.139.98) 98.159 ms 98.309 ms 149.11.142.74 (149.11.142.74) 92.029 ms
16 * * GUARDIAN-UN.car1.London1.Level3.net (212.113.8.30) 91.319 ms

What services are running?

  • MongoDB cluster node
  • Ruby cron jobs
  • Branch of wlanboy.com

Support:

I needed some tickets to get everything running - first tried OpenVZ and afterwards moving to KVM.

The support is friendly but sometimes needed some additional proof that a problem is real.

First answer is always something like "hey it is unmanaged".

If they are convinced that the case is included in the "unmanaged package" then they are trying their best to help.

Maybe I am petted by the A-grade support of the other hosts but that "first no then check" way to handle support is not that enjoyable.

Overall experience:

I will start with the techinical stuff.

The KVM is ok. CPU is fast - I/O is ok.

Network may need some additional free bandwidth (it's capped) but nothing that bad.

There is no DHCP on the KVM node, so you have to enter the network configuration on your own.

But it is included in the welcome mail and in the knowledgebase and you should be able to configure this when you want to use KVM.

They even answer that on a ticket too.

The support is friendly, no harsh word, nothing bad at all on any stupid question and the responses are quite fast (4-6 hours).

But they strictly don't help on any technical issue if they think that it would be "managed service".

So never ask why your webserver is not reachable - instead tell them that there is package lost on a defined upstream.

The OpenVZ templates should be checked too - some need update - some others won't run on some nodes (kernel versions).

Needed some time to get that information beyond the first level support.

Basically MyCustomHosting is ok - it is a provider as many other lowcost hosts are.

Phil is polite but should rethink his strategy to handle support and how he is communicating with his customers (missing announcements, etc).

On that price range a hoster is only able to be different on two main points: Location and support.

Hopefully MyCustomHosting will get better on last one.

Update status:

mychca1.JPG

2 hours and 20 minutes of downtime for the first month.

I would like to tell something about the why, but no announcement and no email - just plain downtime.

I will refresh the uptime report every two months.
 
Last edited by a moderator:

MCH-Phil

New Member
Verified Provider
About the downtime, I'm wondering if it was just an issue with routing etc.  My external monitoring through statuscake, I'm a premium or paid user so it allows me I think 8 check locations, shows no downtime for that node since 2013-12-31 17:24:42.

Statuscake will not alert unless X amt of checks fail.

Either way I will take what you have here and see what I can do with it :D  Thank you!

OVZ is something I'm not all that fond of, I will be phasing it out soon and hoping the few customers I have on OVZ will convert to KVM.
 
Last edited by a moderator:

nunim

VPS Junkie
I've been with MCH for about 6 months now. I currently have 2 active VPSes, both KVM in BHS, and I'm quite satisfied with both of them.  

 

I use one of them almost everyday via RDP for work, running 2008 Server and works great and I regularly push 100Mb/s+ and extract/compress very large archives. The other one is just a Debian sever I use to test scripts and do some other dev work, no complaints on that one either.

I haven't opened many support tickets but the ones I have were responded to quickly, however it's certainly not hand holding support, not do I expect such.  MCH is a great provider if you're technically competent, Phil will make sure that the node is online and network is working, the rest is up to you.
 
Last edited by a moderator:

MCH-Phil

New Member
Verified Provider
BHS means OVH servers? I am searching for a canada based server.

Do you rent the professional line of the OVH servers which include the ddos cleaner without the delay?

Both statements are 100% correct.  Located in Canada at BHS OVH facility and offer the PRO line up of DDoS protection from OVH.  
 
Last edited by a moderator:

wlanboy

Content Contributer
Time for an update:

mychca2.jpg

30 minutes of downtime for the last 2 months.

The CPU and I/O of the vps are ok.

The network speed degraded over the time beyond the 1 Mbit/s limit.
 

wlanboy

Content Contributer
Host is currently offline:


Currently experiencing power issues in the dacentec facility.
The following is from dacentec themselves.

"We have experienced a power outage this morning. Unfortunately one of the systems not
back online yet is our billing system. The support team is working as quickly as possible
to get all servers back up and running.
Please understand that this page is monitored by sales and not support.
We'll be working with the support team to provide updates but are staying out of the way
so they can work quickly."
Services offline currently, will be coming online again shortly.
Sorry for the trouble everyone!
This will only affect customers with a VM in North Carolina.

More info will follow if their is more info to follow

mychca3-down.jpg
 

switsys

Active Member
Host is currently offline:


Currently experiencing power issues in the dacentec facility.
Not much MCH can do about it.

Half the DC is still down. It seems as a lot of their HW (switches etc.) died in the power outage.
 
Last edited by a moderator:

MCH-Phil

New Member
Verified Provider
NC-VPS2 was hosed by the "power incident" caused by Dacentec during "regular scheduled maintenance", that they did not inform me about.  Extremely sorry for the trouble.
 

wlanboy

Content Contributer
Time for an update:

mychca3.jpg

So 2 hours and 31 minutes of downtime since the last update.

Uptime of the vps is 33 days.

CPU and I/O are ok.

Network speed is good and quite constant.

One side note:

Due to the outage the vps is now located in Canada (Montreal).
 

wlanboy

Content Contributer
Time for an update:

mychca4.jpg

1 hour and 45 minutes of network downtime since the last update.

Uptime of the vps is 78 days.

CPU and I/O are ok.

Network speed degraded again:


wget cachefly.cachefly.net/100mb.test -O /dev/null
--2014-08-10 09:03:24-- http://cachefly.cachefly.net/100mb.test
Resolving cachefly.cachefly.net (cachefly.cachefly.net)... 205.234.175.175
Connecting to cachefly.cachefly.net (cachefly.cachefly.net)|205.234.175.175|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 104857600 (100M) [application/octet-stream]
Saving to: `/dev/null'

100%[===========================================================================================>] 104,857,600 1.17M/s in 86s

2014-08-10 09:04:50 (1.16 MB/s) - `/dev/null' saved [104857600/104857600]

The first line of the status report is wrong:

mychcaw32.jpg

There was no network downtime for the whole week so the 9 day of downtime since August are wrong.

Looks like the UDP filter of OVH is active and is blocking all UDP traffic from UK, NL, FR and some other locations.

I can ssh into the box and the website hosted on the vps is available.
 

MCH-Phil

New Member
Verified Provider
Network speed degraded again:


wget cachefly.cachefly.net/100mb.test -O /dev/null
--2014-08-10 09:03:24-- http://cachefly.cachefly.net/100mb.test
Resolving cachefly.cachefly.net (cachefly.cachefly.net)... 205.234.175.175
Connecting to cachefly.cachefly.net (cachefly.cachefly.net)|205.234.175.175|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 104857600 (100M) [application/octet-stream]
Saving to: `/dev/null'

100%[===========================================================================================>] 104,857,600 1.17M/s in 86s

2014-08-10 09:04:50 (1.16 MB/s) - `/dev/null' saved [104857600/104857600]
What node are you on?  How many times did you run wget?  I'm just trying to determine what may have caused the slowness.

I just ran the same wget on all three ca nodes and saw between 15MB/s and 32MB/s.  

Thank you for the feedback!
 
Last edited by a moderator:

wlanboy

Content Contributer
What node are you on?  How many times did you run wget?  I'm just trying to determine what may have caused the slowness.

I just ran the same wget on all three ca nodes and saw between 15MB/s and 32MB/s.  

Thank you for the feedback!
Node: CA-VPS2

Time: 3 times a day for the last 3 days.

Current one:


wget cachefly.cachefly.net/100mb.test -O /dev/null
--2014-08-13 13:22:54-- http://cachefly.cachefly.net/100mb.test
Resolving cachefly.cachefly.net (cachefly.cachefly.net)... 205.234.175.175
Connecting to cachefly.cachefly.net (cachefly.cachefly.net)|205.234.175.175|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 104857600 (100M) [application/octet-stream]
Saving to: `/dev/null'

100%[===========================================================================================>] 104,857,600 1.30M/s in 78s

2014-08-13 13:24:12 (1.29 MB/s) - `/dev/null' saved [104857600/104857600]

Not that far away:

Code:
 vip1.G-anycast1.cachefly.net (205.234.175.175)  86.815 ms  86.948 ms  87.335 ms
 

MCH-Phil

New Member
Verified Provider
It really seems to be another issue causing this problem.  No one else is experiencing slow network.  Nor is any of my monitoring showing higher than avg usage on that node.  Once again a wget from the host node as well as a VM I have on the same host node.  Have you checked -> https://billing.mycustomhosting.net/knowledgebase.php?action=displayarticle&id=4

You are seeing sub 10Mb speeds.  Makes me wonder.

Host node:


[root@ns5001953 ~]# wget cachefly.cachefly.net/100mb.test -O /dev/null
--2014-08-13 20:22:01-- http://cachefly.cachefly.net/100mb.test
Resolving cachefly.cachefly.net... 205.234.175.175
Connecting to cachefly.cachefly.net|205.234.175.175|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 104857600 (100M) [application/octet-stream]
Saving to: “/dev/null”

100%[======================================>] 104,857,600 29.6M/s in 4.4s

2014-08-13 20:22:06 (22.9 MB/s) - “/dev/null” saved [104857600/104857600]

VM on same node:


root@ns3 [~]# wget cachefly.cachefly.net/100mb.test -O /dev/null
--2014-08-13 20:20:29-- http://cachefly.cachefly.net/100mb.test
Resolving cachefly.cachefly.net... 205.234.175.175
Connecting to cachefly.cachefly.net|205.234.175.175|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 104857600 (100M) [application/octet-stream]
Saving to: “/dev/null”

100%[======================================>] 104,857,600 21.6M/s in 5.7s

2014-08-13 20:20:35 (17.5 MB/s) - “/dev/null” saved [104857600/104857600]
Is there maybe a time when we are both online that we may troubleshoot this issue at the same time, or roughly the same time.  Make sure I can see full speeds on host node and see what you are seeing in VM.  Please see the link I pasted above, that can really help.  I understand you likely don't want me to know what VM is actually yours etc etc, so please feel free to use whatever discretion you feel necessary.

I also verified we are seeing the same end point.

Code:
root@ns3 [~]# ping cachefly.cachefly.net
PING vip1.g.cachefly.net (205.234.175.175) 56(84) bytes of data.
 
Last edited by a moderator:

wlanboy

Content Contributer
Time for an update:

mychca5.jpg

40 minutes of network downtime since the last update.

Uptime of the vps is 57 days.

CPU and I/O are ok.

Network speed is good:

Code:
wget cachefly.cachefly.net/100mb.test -O /dev/null
--2014-10-22 00:06:28--  http://cachefly.cachefly.net/100mb.test
Resolving cachefly.cachefly.net (cachefly.cachefly.net)... 205.234.175.175
Connecting to cachefly.cachefly.net (cachefly.cachefly.net)|205.234.175.175|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 104857600 (100M) [application/octet-stream]
Saving to: `/dev/null'

100%[===================================================================================>] 104,857,600 54.4M/s   in 1.8s

2014-10-22 00:06:30 (54.4 MB/s) - `/dev/null' saved [104857600/104857600]
 

wlanboy

Content Contributer
Time for an update:

mychca6-1.jpg

mychca6-2.jpg

mychca6-3.jpg

2 hours and 41 minutes of network downtime since the last update.

Uptime of the vps is 116 days.

CPU and I/O are ok.

Network speed is very good:


wget cachefly.cachefly.net/100mb.test -O /dev/null
--2014-12-20 09:23:09-- http://cachefly.cachefly.net/100mb.test
Resolving cachefly.cachefly.net (cachefly.cachefly.net)... 205.234.175.175
Connecting to cachefly.cachefly.net (cachefly.cachefly.net)|205.234.175.175|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 104857600 (100M) [application/octet-stream]
Saving to: `/dev/null'

100%[===================================================================================>] 104,857,600 78.4M/s in 1.3s

2014-12-20 09:23:11 (78.4 MB/s) - `/dev/null' saved [104857600/104857600]

The vps itself is rocket solid, but the network does have some short blibs that can be annoying.
 

wlanboy

Content Contributer
Time for an update:

mychca7-1.jpg

xxx minutes of possible network downtime since the last update.
I will stop using StatusCake for vps on the OVH network. Looks like VAC is eating pings for breakfast.

Uptime of the vps is 158 days.

CPU and I/O are ok.

Network speed is very good:

Code:
wget cachefly.cachefly.net/100mb.test -O /dev/null
--2015-01-30 14:00:25--  http://cachefly.cachefly.net/100mb.test
Resolving cachefly.cachefly.net (cachefly.cachefly.net)... 205.234.175.175
Connecting to cachefly.cachefly.net (cachefly.cachefly.net)|205.234.175.175|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 104857600 (100M) [application/octet-stream]
Saving to: `/dev/null'

100%[========================================================>] 104,857,600 39.0M/s   in 2.6s

2015-01-30 14:00:27 (39.0 MB/s) - `/dev/null' saved [104857600/104857600]
 

wlanboy

Content Contributer
This will be my last (official) update because the one year review term is over.

The vps itself is good and the support of MCH is good too - if you are able to convince Phil that the problem is on his side :).
But I cannot say anything bad about MCH. The service itself is good and the network does have all the pros and cons of OVH. If I need a cheap vps in Canada MCH would be one my choices.

One remark:

Phil offered me this vps for free (for the next 12 months) to test different ways to keep track of the uptime status. The OVH VAC cuts most of the pings so I am switching to different other tests (like web/tcp) to see if that helps.

So this is no longer an official vpsboard test - and not one of my private vps I rely on. No real service is running on this vps any longer.

Looking forward for feedback.
 
Top
amuck-landowner