• Announcements

    • MannDude

      Current state of vpsBoard   02/04/2017

      Dear vpsBoard members and guests:

      Over the last year or two vpsBoard activity and traffic has dwindled. I have had a change of career and interests, and as such am no longer an active member of the web hosting industry.

      Due to time constraints and new interests I no longer wish to continue to maintain vpsBoard. The web site will remain only as an archive to preserve and showcase some of the great material, guides, and industry news that has been generated by members, some of which I remain in contact to this very day and now regard as personal friends.

      I want to thank all of our members who helped make vpsBoard the fastest growing industry forum. In it's prime it was an active and ripe source of activity, news, guides and just general off-topic banter and fun.

      I wish all members and guests the very best, whether it be with your business or your personal projects.

      -MannDude
wlanboy

BuyVM OpenVZ 128MB (NY)

46 posts in this topic

Provider: BuyVM
Plan: OpenVZ 128mb VPS
Price: 15$ per year
Location: Buffalo, NY

Purchased: 02/2013

 

Hardware information:

 

  • cat /proc/cpuinfo
    processor       : 0
    vendor_id       : GenuineIntel
    cpu family      : 6
    model           : 45
    model name      :       Intel(R) Xeon(R) CPU E5-2630L 0 @ 2.00GHz
    stepping        : 7
    cpu MHz         : 2000.354
    cache size      : 4096 KB
    physical id     : 0
    siblings        : 8
    core id         : 0
    cpu cores       : 8
    apicid          : 0
    fpu             : yes
    fpu_exception   : yes
    cpuid level     : 13
    wp              : yes
    flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc pni ssse3 cx16 sse4_1 sse4_2 popcnt lahf_lm
    bogomips        : 4000.70
    clflush size    : 64
    cache_alignment : 64
    address sizes   : 40 bits physical, 48 bits virtual
    power management:
    
  • cat /proc/meminfo
    MemTotal:       262144 kB
    MemFree:        102004 kB
    Buffers:             0 kB
    Cached:              0 kB
    SwapCached:          0 kB
    Active:              0 kB
    Inactive:            0 kB
    HighTotal:           0 kB
    HighFree:            0 kB
    LowTotal:       262144 kB
    LowFree:        102004 kB
    SwapTotal:           0 kB
    SwapFree:            0 kB
    Dirty:             260 kB
    Writeback:           0 kB
    AnonPages:           0 kB
    Mapped:              0 kB
    Slab:                0 kB
    PageTables:          0 kB
    NFS_Unstable:        0 kB
    Bounce:              0 kB
    CommitLimit:         0 kB
    Committed_AS:        0 kB
    VmallocTotal:        0 kB
    VmallocUsed:         0 kB
    VmallocChunk:        0 kB
    HugePages_Total:     0
    HugePages_Free:      0
    HugePages_Rsvd:      0
    Hugepagesize:     2048 kB
    
  • dd
    dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync && rm -rf test
    16384+0 records in
    16384+0 records out
    1073741824 bytes (1.1 GB) copied, 4.75213 s, 226 MB/s
    
  • wget
    wget cachefly.cachefly.net/100mb.test -O /dev/null
    
    --2013-05-19 20:28:03--  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 6.89M/s   in 17s
    
    2013-05-19 20:28:20 (5.71 MB/s) - `/dev/null' saved [104857600/104857600]
    

What services are running?

  • Ruby scripts
  • Thin cluster
  • Rails app
  • lighttpd + php

 

Support:

I have opened 2 support tickets since February. All get short answers within some minutes. If I look to them:

  • One ticket for activating the free 5GB backup space.
  • One ticket to reset my security question.

Nothing to complain, Friendly and fast support.

 

Overall experience:

I am a happy customer. The performance is good to run some websites. Compile time of Ruby was ok. Network for US connections is really good. Network routings to europe are ok (telia -> cogentco -> level3). VPS is as stable as SecureDragon. 100% uptime (hardware) for the last 12 weeks. But sometimes there are some minor connection issues. Ping to europe is about 120ms.

 

 

Share this post


Link to post
Share on other sites

Thanks :)

Francisco

Share this post


Link to post
Share on other sites

+1 to BuyVM! Out of the 4 VPSs I still renew, 2 of them are with BuyVM (1 OpenVZ and 1 KVM, both in NV).

Share this post


Link to post
Share on other sites

BuyVM is a staple.  Good guys and reliable servers.

 

Only nitpick is the network.  Buffalo is flaky.

 

Was pointed out recently elsewhere that Cogent in the mix has really messed up routes, especially to Europe.   Routes are often enough something like Cogent ---> Telia --> Cogent.  Certainly weird, since Cogent loves to haul traffic end to end to reduce their costs and peering.

Share this post


Link to post
Share on other sites

This is the /proc/user_beancounters from my NY ovz128:

Version: 2.5
       uid  resource                     held              maxheld              barrier                limit              failcnt
    #####:  kmemsize                  3926739              8141259           2147483646           2147483646                    0
            lockedpages                     0                  427               999999               999999                    0
            privvmpages                 43368               185506                65536                65536                 4445
            shmpages                     1281                 6417                32768                32768                    4
            dummy                           0                    0                    0                    0                    0
            numproc                        38                   98                  500                  500                    0
            physpages                   11825               171083                    0  9223372036854775807                    0
            vmguarpages                     0                    0                32768                32768                    0
            oomguarpages                11825               171083                32768                32768                    0
            numtcpsock                     13                  172              7999992              7999992                    0
            numflock                        2                    8               999999               999999                    0
            numpty                          2                   16               500000               500000                    0
            numsiginfo                      0                   64               999999               999999                    0
            tcpsndbuf                  234536             13373560            214748160            396774400                    0
            tcprcvbuf                  212992             52609728            214748160            396774400                    0
            othersockbuf                48888               169512            214748160            396774400                    0
            dgramrcvbuf                     0                96496            214748160            396774400                    0
            numothersock                   37                   78              7999992              7999992                    0
            dcachesize                      0                    0           2147483646           2147483646                    0
            numfile                      1214                 2355             23999976             23999976                    0
            dummy                           0                    0                    0                    0                    0
            dummy                           0                    0                    0                    0                    0
            dummy                           0                    0                    0                    0                    0
            numiptent                      34                   35               999999               999999                    0

 

The uname shows the following, which is the mask for their 2.6.18 ovz kernel:

Linux lovecraft 2.6.32-pony6-3 #1 SMP Tue Mar 13 07:31:44 PDT 2012 i686 GNU/Linux
 

Share this post


Link to post
Share on other sites

 

This is the /proc/user_beancounters from my NY ovz128:

 

So explain what we should note from the beancounter info...

Share this post


Link to post
Share on other sites

physpages is set to unlimited? :D

 

Francisco

Share this post


Link to post
Share on other sites

Back to the original review...

 

wget cachefly.cachefly.net/100mb.test -O /dev/null

--2013-05-19 20:28:03-- 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 6.89M/s in 17s

 

 

6.89M/s... seems slow.

 

So, I just logged into my container there.  They handout gigabit, with obvious collision with other users for bandwidth resources.

 

100%[===================================================================================================================================================================================================>] 104,857,600 9.95MB/s   in 8.7s   

 

 

100%[===================================================================================================================================================================================================>] 104,857,600 3.81MB/s   in 24s    

 

100%[===================================================================================================================================================================================================>] 104,857,600 6.29MB/s   in 12s  

 

 

Seeing the cachefly speedtest file start out really fast 22MB/s and then just slow way down.

 

So, I had to look at where the network was taking us to get this file:

 

 

3:  buf-b1-link.telia.net                                 0.822ms asymm  5 
 4:  nyk-bb1-link.telia.net                                9.992ms asymm  6 
 5:  nyk-b5-link.telia.net                                10.252ms asymm  6 
 6:  xe-0.equinix.chcgil09.us.bb.gin.ntt.NET              13.671ms asymm  8 
 7:  ae-1.r06.chcgil09.us.bb.gin.ntt.net                  14.212ms asymm  8 
 8:  154.54.13.234                                        11.157ms 
 9:  te8-2-10G.ar3.DCA3.gblx.net                          22.718ms asymm 10 
10:  ae2-20g.ar1.ord6.us.nlayer.net                       15.837ms asymm  9 
11:  vip1.G-anycast1.cachefly.net                         14.746ms reached
 
Buffalo is East Coast, Chicago is mid-west (central US).   Routing this to Chicago = stupid.  Unsure who is determining where this file should be served up, but clearly, New York City has to be a Cachefly POP and likely much better speeds.
 
I did a bunch of other tests with a file I leave laying everywhere and didn't see this same sort of QoS artifact that I saw with the Cachefly test.  Saw much faster and uniform speeds.

Share this post


Link to post
Share on other sites

But that is something Buffalo specific:

 2  *****.aggr.buffalo.nwnx.net (********)  1.426 ms  1.452 ms  1.359 ms
 3  te7-4.ccr01.buf02.atlas.cogentco.com (38.122.36.45)  1.225 ms  1.231 ms  1.216 ms
 4  216.156.0.253.ptr.us.xo.net (216.156.0.253)  17.634 ms nyk-bb1-link.telia.net (80.91.246.37)  9.676 ms 216.156.0.253.ptr.us.xo.net (216.156.0.253)  17.634 ms
 5  * * te9-7.ccr01.jfk01.atlas.cogentco.com (154.54.43.6)  10.965 ms
 6  te0-6-0-0.mpd22.jfk02.atlas.cogentco.com (154.54.1.209)  10.863 ms ae8.edge3.Chicago3.Level3.net (4.68.127.245)  13.962 ms  13.897 ms
 7  vlan52.ebr2.Chicago2.Level3.net (4.69.138.190)  104.222 ms vlan60.csw1.NewYork1.Level3.net (4.69.155.62)  90.689 ms te0-1-0-1.ccr21.jfk05.atlas.cogentco.com (154.54.31.2)  11.953 ms
 8  xe-9-0-0.edge1.NewYork1.Level3.net (4.68.111.45)  11.507 ms ae-61-61.ebr1.NewYork1.Level3.net (4.69.134.65)  90.610 ms ae-6-6.ebr2.Washington12.Level3.net (4.69.148.145)  104.601 ms
 9  ae-5-5.ebr2.Washington1.Level3.net (4.69.143.221)  105.962 ms  104.607 ms vlan70.csw2.NewYork1.Level3.net (4.69.155.126)  90.276 ms

Share this post


Link to post
Share on other sites

You poor boy @wlanboy :)  Interesting seeing CVPS route being so different from BuyVM's...

 

That was a traceroute to cachefly.cachefly.net correct?

 

That route is super stupid if so.  Cogent to Telia to XO to Cogent (NYC) to Level3 (Chicago) back to NY on Level3 to Washington DC on Level3 to NY on Level 3.

 

What in hell are the doing with that mess? 90-100ms  and thousands of miles of looping to get from Buffalo to NYC end to end....

 

Funny thing is, this far from the first time I've seen this sort of mess of misrouting at CC's locations.

Share this post


Link to post
Share on other sites

It was a traceroute to the accelerated network in germany.

 

Traceroute to france (lemonde.fr):

 3  207.86.157.13 (207.86.157.13)  0.413 ms  0.503 ms te7-4.ccr01.buf02.atlas.cogentco.com (38.122.36.45)  139.799 ms
 4  216.156.0.253.ptr.us.xo.net (216.156.0.253)  16.365 ms  16.172 ms nyk-bb1-link.telia.net (80.91.246.37)  23.097 ms
 5  nyk-b5-link.telia.net (213.155.135.19)  9.761 ms 207.88.14.194.ptr.us.xo.net (207.88.14.194)  12.966 ms  13.080 ms
 6  cogent-ic-151337-nyk-b5.c.telia.net (213.248.73.198)  10.210 ms te0-0-0-6.ccr22.lpl01.atlas.cogentco.com (130.117.0.254)  83.934 ms cogent-ic-151337-nyk-b5.c.telia.net (213.248.73.198)  10.173 ms
 7  te0-6-0-5.ccr22.jfk02.atlas.cogentco.com (154.54.83.165)  10.367 ms be2004.mpd22.ord01.atlas.cogentco.com (154.54.5.9)  24.886 ms te0-3-0-1.ccr22.jfk02.atlas.cogentco.com (154.54.27.205)  10.548 ms
 8  te0-1-0-7.mpd22.par01.atlas.cogentco.com (130.117.50.14)  88.567 ms te0-7-0-3.mpd21.par01.atlas.cogentco.com (154.54.43.153)  82.286 ms te0-7-0-3.ccr22.par01.atlas.cogentco.com (154.54.43.162)  84.694 ms
 9  te0-7-0-3.mag21.par01.atlas.cogentco.com (130.117.49.86)  89.029 ms te0-7-0-33.mag21.par01.atlas.cogentco.com (154.54.74.162)  89.196 ms te0-0-0-27.mag21.par01.atlas.cogentco.com (154.54.74.138)  81.890 ms
10  te0-0-0-6.ccr21.lpl01.atlas.cogentco.com (154.54.28.94)  97.755 ms snsci.demarc.cogentco.com (149.6.160.50)  90.059 ms 149.6.115.6 (149.6.115.6)  86.183 ms
11  bzn-crs16-1-be1106.intf.routers.proxad.net (212.27.59.101)  82.636 ms  83.436 ms te0-2-0-4.ccr22.lon13.atlas.cogentco.com (154.54.60.105)  96.245 ms
12  dedibox-2-p.intf.routers.proxad.net (212.27.50.162)  89.885 ms  89.009 ms  85.772 ms

That is ok: NY -> JFK -> Paris

 

Traceroute to UK (guardian.co.uk):

 3  buf-b1-link.telia.net (213.248.96.41)  0.297 ms 207.86.157.13 (207.86.157.13)  0.392 ms  0.482 ms
 4  216.156.0.253.ptr.us.xo.net (216.156.0.253)  20.452 ms te0-0-0-32.ccr21.yyz02.atlas.cogentco.com (154.54.43.61)  12.470 ms te0-7-0-26.ccr22.yyz02.atlas.cogentco.com (154.54.27.69)  12.929 ms
 5  nyk-b5-link.telia.net (213.155.131.137)  9.779 ms 207.88.14.194.ptr.us.xo.net (207.88.14.194)  12.989 ms te0-3-0-5.ccr22.ymq02.atlas.cogentco.com (154.54.42.230)  14.651 ms
 6  xe-10-1-0.edge1.NewYork1.Level3.net (4.68.110.81)  9.881 ms te0-4-0-6.ccr22.lpl01.atlas.cogentco.com (154.54.44.214)  83.957 ms te0-2-0-6.ccr21.lpl01.atlas.cogentco.com (154.54.0.69)  83.789 ms
 7  vlan80.csw3.NewYork1.Level3.net (4.69.155.190)  89.539 ms vlan70.csw2.NewYork1.Level3.net (4.69.155.126)  90.123 ms vlan51.ebr1.Chicago2.Level3.net (4.69.138.158)  102.706 ms
 8  ae-6-6.ebr1.Chicago1.Level3.net (4.69.140.189)  101.896 ms te0-0-0-0.ccr21.lon01.atlas.cogentco.com (154.54.57.113)  84.143 ms ae-6-6.ebr1.Chicago1.Level3.net (4.69.140.189)  102.027 ms
 9  ae-2-2.ebr2.NewYork2.Level3.net (4.69.132.66)  101.460 ms  101.775 ms ae-41-41.ebr2.London1.Level3.net (4.69.137.65)  89.690 ms
10  ae-59-224.csw2.London1.Level3.net (4.69.153.142)  89.788 ms 149.11.142.74 (149.11.142.74)  93.859 ms ae-1-100.ebr1.NewYork2.Level3.net (4.69.135.253)  100.543 ms
11  4.69.201.45 (4.69.201.45)  101.665 ms ae-21-52.car1.London1.Level3.net (4.69.139.98)  88.500 ms 77.91.255.137 (77.91.255.137)  94.644 ms
12  GUARDIAN-UN.car1.London1.Level3.net (212.113.8.30)  79.988 ms 77.91.255.194 (77.91.255.194)  95.004 ms GUARDIAN-UN.car1.London1.Level3.net (212.113.8.30)  79.787 ms

There it is again: Chicago.

 

Traceroute to NL (dvhn.nl):

 3  te7-4.ccr01.buf02.atlas.cogentco.com (38.122.36.45)  10.252 ms 207.86.157.13 (207.86.157.13)  0.382 ms te7-4.ccr01.buf02.atlas.cogentco.com (38.122.36.45)  10.310 ms
 4  216.156.0.253.ptr.us.xo.net (216.156.0.253)  22.182 ms nyk-bb1-link.telia.net (80.91.246.37)  9.718 ms  9.675 ms
 5  207.88.14.194.ptr.us.xo.net (207.88.14.194)  13.048 ms  12.966 ms  12.963 ms
 6  206.111.2.222.ptr.us.xo.net (206.111.2.222)  13.365 ms  44.589 ms xe-0-1-1.lon10.ip4.tinet.net (141.136.107.153)  83.036 ms
 7  xe-5-1-0.lon10.ip4.tinet.net (89.149.187.141)  92.810 ms  80.153 ms bit-gw.ip4.tinet.net (77.67.75.70)  83.355 ms
 8  bit-gw.ip4.tinet.net (77.67.75.70)  93.472 ms  90.884 ms 805.xe-0-0-0.jun1.bit-1.network.bit.nl (213.136.1.105)  97.154 ms
 9  805.xe-0-0-0.jun1.bit-1.network.bit.nl (213.136.1.105)  108.582 ms  108.431 ms 806.xe-0-0-0.jun1.bit-2a.network.bit.nl (213.136.1.109)  96.056 ms

That is ok too.

Share this post


Link to post
Share on other sites

@wlanboy, That traceroute to UK (guardian.co.uk) = retarded routing.

 

 

What is super disturbing about that route is we have the upstream handoffs going on.   XO --> COGENT --> Level 3 --> then Level 3 goes to Chicago and gets lost.

 

 

 

What is disturbing about that?  Colocrossing still supposedly has Level 3 in their upstream mix.  They should be able to stuff these packets in Level 3 straight out of Buffalo over to JFK over the pond and where are there.

 

They've monkeyed things so poorly that you have routing like what you've shown that is just nuts and makes you wonder if they actually have Level 3 there.

 

Not to be outdone, the other blend they serving up @Francisco and BuyVM out of Buffalo is even more broken perhaps:

 

 

3:  buf-b1-link.telia.net                                 0.830ms asymm  5 
 4:  216.156.0.253.ptr.us.xo.net                          14.455ms asymm  5 
 5:  te0-3-0-3.ccr22.ymq02.atlas.cogentco.com             14.977ms asymm  9 
 6:  4.68.127.245                                         13.295ms asymm  8 
 7:  te0-3-0-4.mpd21.lon13.atlas.cogentco.com             83.727ms asymm  9 
 8:  ae-71-71.ebr1.NewYork1.Level3.net                    89.755ms asymm 12 
 9:  ae-2-2.ebr2.NewYork2.Level3.net                     102.046ms asymm 12 
10:  ae-59-224.csw2.London1.Level3.net                    88.594ms asymm 11 
11:  4.69.201.45                                         102.025ms asymm 12 
12:  77.91.255.194                                        96.667ms asymm 13 
13:  77.91.255.141                                        91.159ms asymm 15 
14:  77.91.255.137                                        90.005ms 
15:  GUARDIAN-UN.car1.London1.Level3.net                  92.514ms asymm 10 
16:  77.91.255.141                                       103.272ms asymm 15 
17:  no reply
18:  77.91.255.194                                       105.729ms asymm 13 
 

Figure that mess out.  Looks like:

XO --> Cogent --> Cogent (London) --> Level 3 (NYC) --> Level 3 (London) --> 4.69.201.45 (which appears to be NYC Level 3 --- try a traceroute to that IP for fun) ---> Level 3 (London)

 

The latency doesn't add up though since we've basically gone from NY state to London then back to NY state then back to London.

 

Maybe @Francisco can comment on these messed up routes?

Share this post


Link to post
Share on other sites

@wlanboy, That traceroute to UK (guardian.co.uk) = retarded routing.

 

 

What is super disturbing about that route is we have the upstream handoffs going on.   XO --> COGENT --> Level 3 --> then Level 3 goes to Chicago and gets lost.

 

 

 

What is disturbing about that?  Colocrossing still supposedly has Level 3 in their upstream mix.  They should be able to stuff these packets in Level 3 straight out of Buffalo over to JFK over the pond and where are there.

 

They've monkeyed things so poorly that you have routing like what you've shown that is just nuts and makes you wonder if they actually have Level 3 there.

 

Not to be outdone, the other blend they serving up @Francisco and BuyVM out of Buffalo is even more broken perhaps:

 

 

3:  buf-b1-link.telia.net                                 0.830ms asymm  5 
 4:  216.156.0.253.ptr.us.xo.net                          14.455ms asymm  5 
 5:  te0-3-0-3.ccr22.ymq02.atlas.cogentco.com             14.977ms asymm  9 
 6:  4.68.127.245                                         13.295ms asymm  8 
 7:  te0-3-0-4.mpd21.lon13.atlas.cogentco.com             83.727ms asymm  9 
 8:  ae-71-71.ebr1.NewYork1.Level3.net                    89.755ms asymm 12 
 9:  ae-2-2.ebr2.NewYork2.Level3.net                     102.046ms asymm 12 
10:  ae-59-224.csw2.London1.Level3.net                    88.594ms asymm 11 
11:  4.69.201.45                                         102.025ms asymm 12 
12:  77.91.255.194                                        96.667ms asymm 13 
13:  77.91.255.141                                        91.159ms asymm 15 
14:  77.91.255.137                                        90.005ms 
15:  GUARDIAN-UN.car1.London1.Level3.net                  92.514ms asymm 10 
16:  77.91.255.141                                       103.272ms asymm 15 
17:  no reply
18:  77.91.255.194                                       105.729ms asymm 13 
 

Figure that mess out.  Looks like:

XO --> Cogent --> Cogent (London) --> Level 3 (NYC) --> Level 3 (London) --> 4.69.201.45 (which appears to be NYC Level 3 --- try a traceroute to that IP for fun) ---> Level 3 (London)

 

The latency doesn't add up though since we've basically gone from NY state to London then back to NY state then back to London.

 

Maybe @Francisco can comment on these messed up routes?

 

Well, it sounds like the routes are asymmetrical no?

 

It's very much possible that CC is doing some adjustments based on path/etc for preferred routes. I had the same thing at EGI but thankfully CC isn't being complete penny pincher's on that.

 

Francisco

Share this post


Link to post
Share on other sites

Unsure about the symmetry or missing the point there.

 

No way what is happening in my example should be, but the numbers of course say something is off.  Not doing the cross Atlantic trip twice in that time.

 

Very odd :)

 

Certainly seems to be preferred path from CVPS.... Wondering if their customers are seeing a whole lot more "Gogent" these days.

Share this post


Link to post
Share on other sites

You forgot that Telia was the first hop.

 

If you have the sick pleasure of using their services or an ISP that peers with them like me (this isn't to BuyVM, but still):

[email protected]:~$ traceroute mc.nullblock.com
traceroute to mc.nullblock.com (192.227.135.245), 30 hops max, 60 byte packets
<Internal stuff>
 6  bbr02atlnga-bue-3.atln.ga.charter.com (96.34.2.72)  23.260 ms  17.677 ms  23.415 ms
 7  bbr01atlnga-tge-0-0-0-2.atln.ga.charter.com (96.34.0.38)  24.284 ms  25.730 ms  25.713 ms
 8  atl-bb1-link.telia.net (80.239.130.249)  51.881 ms  51.857 ms  51.838 ms
 9  ash-bb3-link.telia.net (80.91.252.213)  49.362 ms ash-bb3-link.telia.net (213.155.134.130)  47.064 ms ash-bb3-link.telia.net (80.91.252.217)  51.727 ms
10  nyk-bb1-link.telia.net (213.155.130.78)  55.371 ms nyk-bb1-link.telia.net (213.155.134.126)  59.126 ms nyk-bb1-link.telia.net (213.155.131.226)  62.771 ms
11  buf-b1-link.telia.net (80.91.246.36)  64.149 ms  66.422 ms  64.377 ms
12  giglinx-ic-155660-buf-b1.c.telia.net (213.248.96.42)  66.158 ms  65.961 ms  67.538 ms
13  host.colocrossing.com (75.127.11.234)  88.140 ms  85.302 ms  84.969 ms
14  Node13.weloveservers.net (192.227.135.130)  68.479 ms  64.031 ms  62.395 ms
15  host.colocrossing.com (192.227.135.245)  66.384 ms  63.602 ms  59.914 ms
[email protected]:~$ ping -c 5 mc.nullblock.com
PING mc.nullblock.com (192.227.135.245) 56(84) bytes of data.
64 bytes from host.colocrossing.com (192.227.135.245): icmp_req=2 ttl=47 time=62.2 ms
64 bytes from host.colocrossing.com (192.227.135.245): icmp_req=3 ttl=47 time=61.8 ms
64 bytes from host.colocrossing.com (192.227.135.245): icmp_req=4 ttl=47 time=82.5 ms
64 bytes from host.colocrossing.com (192.227.135.245): icmp_req=5 ttl=47 time=66.9 ms

--- mc.nullblock.com ping statistics ---
5 packets transmitted, 4 received, 20% packet loss, time 4012ms
rtt min/avg/max/mdev = 61.855/68.390/82.562/8.420 ms
[email protected]:~$ 

That being said, I don't plan to ever use ColoCrossing in Buffalo, nor will I even really use them at all. I might go back if their routing was much better. This makes single-homed Cogent look like the best thing ever to me.

 

I'll end my Telia rant now (and hopefully my posts full of traceroutes :)), but I certainly support BuyVM's decision to stop giving more hardware to ColoCrossing. I imagine that you should give Ashburn a try to be honest. I don't see too many LEB providers there other than Amazon (but it's "cloud", which to me is another word for "shit").

1 person likes this

Share this post


Link to post
Share on other sites

You forgot that Telia was the first hop.

 

If you have the sick pleasure of using their services or an ISP that peers with them like me (this isn't to BuyVM, but still):

[email protected]:~$ traceroute mc.nullblock.com
traceroute to mc.nullblock.com (192.227.135.245), 30 hops max, 60 byte packets
<Internal stuff>
 6  bbr02atlnga-bue-3.atln.ga.charter.com (96.34.2.72)  23.260 ms  17.677 ms  23.415 ms
 7  bbr01atlnga-tge-0-0-0-2.atln.ga.charter.com (96.34.0.38)  24.284 ms  25.730 ms  25.713 ms
 8  atl-bb1-link.telia.net (80.239.130.249)  51.881 ms  51.857 ms  51.838 ms
 9  ash-bb3-link.telia.net (80.91.252.213)  49.362 ms ash-bb3-link.telia.net (213.155.134.130)  47.064 ms ash-bb3-link.telia.net (80.91.252.217)  51.727 ms
10  nyk-bb1-link.telia.net (213.155.130.78)  55.371 ms nyk-bb1-link.telia.net (213.155.134.126)  59.126 ms nyk-bb1-link.telia.net (213.155.131.226)  62.771 ms
11  buf-b1-link.telia.net (80.91.246.36)  64.149 ms  66.422 ms  64.377 ms
12  giglinx-ic-155660-buf-b1.c.telia.net (213.248.96.42)  66.158 ms  65.961 ms  67.538 ms
13  host.colocrossing.com (75.127.11.234)  88.140 ms  85.302 ms  84.969 ms
14  Node13.weloveservers.net (192.227.135.130)  68.479 ms  64.031 ms  62.395 ms
15  host.colocrossing.com (192.227.135.245)  66.384 ms  63.602 ms  59.914 ms
[email protected]:~$ ping -c 5 mc.nullblock.com
PING mc.nullblock.com (192.227.135.245) 56(84) bytes of data.
64 bytes from host.colocrossing.com (192.227.135.245): icmp_req=2 ttl=47 time=62.2 ms
64 bytes from host.colocrossing.com (192.227.135.245): icmp_req=3 ttl=47 time=61.8 ms
64 bytes from host.colocrossing.com (192.227.135.245): icmp_req=4 ttl=47 time=82.5 ms
64 bytes from host.colocrossing.com (192.227.135.245): icmp_req=5 ttl=47 time=66.9 ms

--- mc.nullblock.com ping statistics ---
5 packets transmitted, 4 received, 20% packet loss, time 4012ms
rtt min/avg/max/mdev = 61.855/68.390/82.562/8.420 ms
[email protected]:~$ 

That being said, I don't plan to ever use ColoCrossing in Buffalo, nor will I even really use them at all. I might go back if their routing was much better. This makes single-homed Cogent look like the best thing ever to me.

 

I'll end my Telia rant now (and hopefully my posts full of traceroutes :)), but I certainly support BuyVM's decision to stop giving more hardware to ColoCrossing. I imagine that you should give Ashburn a try to be honest. I don't see too many LEB providers there other than Amazon (but it's "cloud", which to me is another word for "shit").

 

Thanks for chiming in :)  I had to chuckle at some of it.  Cloud = SHIT.  Agreed.

 

Georgia to Buffalo, NY, in 65ms ... slow.

 

BuyVM holding back on hardware in Buffalo... Yeah, they've been.  Not a BuyVM kick in the sack, but plenty of other "providers" bit on Buffalo deals and they can't sell anything there.   Demand isn't great at that location.

Share this post


Link to post
Share on other sites

Thanks for chiming in :)  I had to chuckle at some of it.  Cloud = SHIT.  Agreed.

 

Georgia to Buffalo, NY, in 65ms ... slow.

 

BuyVM holding back on hardware in Buffalo... Yeah, they've been.  Not a BuyVM kick in the sack, but plenty of other "providers" bit on Buffalo deals and they can't sell anything there.   Demand isn't great at that location.

Yeah. My normal ping to NY is around 37ms (to DigitalOcean NY, that is), so 65ms is very subpar. I wonder if Telia intentionally lags traffic for the lulz (likely) or my ISP is total garbage (also likely). Buffalo should only add around 3-10ms at worst.

Share this post


Link to post
Share on other sites

Buffalo to NYC for instance use to be +10ms.  More recently those numbers have increased.

 

Routing from Buffalo outward is seriously messed up lately. 

 

 

tracepath schools.nyc.gov
 4:  80.91.246.34                                          5.309ms asymm  6 
 5:  chi-bb1-link.telia.net                               13.522ms asymm  7 
 6:  te0-6-0-6.ccr22.jfk02.atlas.cogentco.com             10.736ms asymm  8 
 7:  nyc1-ar3-xe-1-0-0-0.us.twtelecom.net                 28.822ms asymm 10 
 8:  165.155.0.33                                         31.483ms asymm 11 
 9:  144.232.4.185                                        30.932ms asymm 10 
10:  144.232.8.164                                        24.164ms asymm  9 
11:  sl-st30-ash-0-1-0-0.sprintlink.net                   31.440ms asymm  9 
12:  sl-timewarner-374159-0.sprintlink.net                22.554ms asymm  9 
13:  nyc1-ar3-xe-0-0-0-0.us.twtelecom.net                 30.007ms asymm 10 
14:  165.155.0.33                                         32.523ms asymm 11 
 

See, going to Chicago again.  32ms to go from Buffalo to New York City. This is a joke.  No one wants to handle their hot potato routing.

 

Is there a least cost routing path option :) ?

 

I am not even paying attention or trying to find goofy routes.   First pick and it's crazy busted.

Compare that to Choopa in New Jersey:

 

tracepath schools.nyc.gov

 2:  ethernet5-7-br2.pnj1.choopa.net                      12.062ms asymm  3 

 3:  198.32.160.35                                         0.985ms asymm  5 
 4:  fast0-0.iix-igr01.nycl.twtelecom.net                  1.431ms asymm  5 
 5:  165.155.0.33                                          3.900ms asymm  7 
 6:  165.155.0.33                                          3.726ms asymm  7 

Share this post


Link to post
Share on other sites

So explain what we should note from the beancounter info...

Basically, they don't underallocate you for anything in particular. A lot of hosts might cap your numprocs lower or limit your kmem size or your tcp socks/file handles to something you might actually hit. Buyvm doesn't; they set the params at a reasonable level and really only cap your ram, just as you would expect.

That's not why I attached it to the thread though. I try to find out what beancounters is set to before I pick up an ovz, but most times that is impossible.

You should take some time to learn how to read them; being able to read beancounters is good for you as a user, especially when things are failing for "no apparent reason". That failcount column will tell you if your hitting resource limits frequently.

1 person likes this

Share this post


Link to post
Share on other sites

Basically, they don't underallocate you for anything in particular. A lot of hosts might cap your numprocs lower or limit your kmem size or your tcp socks/file handles to something you might actually hit. Buyvm doesn't; they set the params at a reasonable level and really only cap your ram, just as you would expect.

That's not why I attached it to the thread though. I try to find out what beancounters is set to before I pick up an ovz, but most times that is impossible.

You should take some time to learn how to read them; being able to read beancounters is good for you as a user, especially when things are failing for "no apparent reason". That failcount column will tell you if your hitting resource limits frequently.

 

Awesome info. Thanks for taking the time to explain this further. Definitely going to look at my providers and dig more into these various numbers and what each means.

Share this post


Link to post
Share on other sites

  • Similar Content

    • By wlanboy
      Provider: VirtWire 
      Plan: OpenVZ 512 MB VPS
      Price: $6 per year
      Location: Miama, FL
      Purchased: 09/2015

      Hardware information:
      cat /proc/cpuinfo (1x) processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 60 model name : Intel(R) Xeon(R) CPU E3-1241 v3 @ 3.50GHz stepping : 3 microcode : 28 cpu MHz : 3501.000 cache size : 8192 KB physical id : 0 siblings : 8 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf cpuid_faulting pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase bmi1 avx2 smep bmi2 erms invpcid xsaveopt bogomips : 7000.24 clflush size : 64 cache_alignment : 64 address sizes : 39 bits physical, 48 bits virtual power management:  
      cat /proc/meminfo MemTotal: 524288 kB MemFree: 436212 kB Cached: 23984 kB Buffers: 0 kB Active: 39992 kB Inactive: 39420 kB Active(anon): 30536 kB Inactive(anon): 27548 kB Active(file): 9456 kB Inactive(file): 11872 kB Unevictable: 0 kB Mlocked: 0 kB SwapTotal: 262144 kB SwapFree: 234448 kB Dirty: 0 kB Writeback: 0 kB AnonPages: 58084 kB Shmem: 2656 kB Slab: 8656 kB SReclaimable: 2316 kB SUnreclaim: 6340 kB  
      dd 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.668 s, 201 MB/s  
      Network:
      1 IPv4 /64 IPv6 Subnet 1024 GB Transfer traceroute dvhn.nl
      traceroute to dvhn.nl (52.30.49.180), 30 hops max, 60 byte packets 2 173.44.32.253.static.quadranet.com (173.44.32.253) 0.189 ms 0.215 ms 0.182 ms 3 xe-0-2-0-1.r05.miamfl02.us.bb.gin.ntt.net (129.250.203.9) 0.728 ms 0.749 ms 0.785 ms 4 ae-4.r20.miamfl02.us.bb.gin.ntt.net (129.250.2.184) 0.492 ms 0.558 ms 0.593 ms 5 ae-4.r23.asbnva02.us.bb.gin.ntt.net (129.250.2.86) 30.780 ms 30.798 ms 30.839 ms 6 ae-2.r25.amstnl02.nl.bb.gin.ntt.net (129.250.6.163) 113.280 ms 121.894 ms 111.328 ms 7 ae-1.r03.amstnl02.nl.bb.gin.ntt.net (129.250.2.147) 120.284 ms 114.583 ms 118.774 ms 8 ae-3.r03.londen05.uk.bb.gin.ntt.net (129.250.6.26) 111.775 ms 108.220 ms 116.006 ms 9 ae-5.r02.londen05.uk.bb.gin.ntt.net (129.250.6.229) 129.447 ms 121.353 ms 121.542 ms 10 82.112.115.190 (82.112.115.190) 108.184 ms 107.653 ms 82.112.115.162 (82.112.115.162) 113.662 ms 11 * * * 12 * * 176.32.106.36 (176.32.106.36) 125.399 ms 13 178.236.0.225 (178.236.0.225) 125.679 ms 176.32.106.36 (176.32.106.36) 117.054 ms 178.236.0.225 (178.236.0.225) 123.190 ms 14 178.236.0.191 (178.236.0.191) 126.639 ms 178.236.0.208 (178.236.0.208) 132.311 ms 135.978 ms 15 178.236.0.208 (178.236.0.208) 126.500 ms 178.236.0.210 (178.236.0.210) 134.000 ms 178.236.0.213 (178.236.0.213) 126.301 ms 16 * * 178.236.1.189 (178.236.1.189) 131.358 ms traceroute sueddeutsche.de
      traceroute to sueddeutsche.de (46.189.56.88), 30 hops max, 60 byte packets 2 173.44.32.253.static.quadranet.com (173.44.32.253) 0.204 ms 0.196 ms 0.223 ms 3 xe-3-1-5-51-grtmiana2.net.telefonicaglobalsolutions.com (5.53.1.32) 1.767 ms 1.793 ms 1.786 ms 4 xe2-1-3-0-grtmiabr4.red.telefonica-wholesale.net (213.140.36.90) 13.630 ms te0-5-0-6-grtmiabr6.net.telefonicaglobalsolutions.com (94.142.122.254) 2.205 ms te0-0-0-9-grtmiabr5.red.telefonica-wholesale.net (94.142.121.146) 4.627 ms 5 xe10-0-0-0-grtrpaopx2.net.telefonicaglobalsolutions.com (84.16.13.65) 68.400 ms 67.987 ms xe0-0-0-0-grtpaopx2.net.telefonicaglobalsolutions.com (176.52.254.253) 64.439 ms 6 213.140.55.70 (213.140.55.70) 90.781 ms 86.340 ms 86.331 ms 7 217.239.42.186 (217.239.42.186) 168.826 ms 213.140.53.174 (213.140.53.174) 105.583 ms 217.239.42.186 (217.239.42.186) 172.519 ms 8 213.140.55.70 (213.140.55.70) 105.565 ms 217.239.42.202 (217.239.42.202) 188.288 ms 213.140.53.174 (213.140.53.174) 107.452 ms 9 10g-9-4.esn001isp005.versatel.de (62.214.110.234) 165.907 ms 170.032 ms 10g-9-4.esn001isp006.versatel.de (62.214.110.238) 168.310 ms 10 ge-05-01-803.dor002isp005.versatel.de (62.214.111.26) 163.609 ms 62.214.105.126 (62.214.105.126) 168.818 ms 87.128.232.54 (87.128.232.54) 179.409 ms 11 62.214.106.34 (62.214.106.34) 351.274 ms dor2is2.versatel.de (62.214.104.170) 351.012 ms 351.252 ms 12 62.214.106.38 (62.214.106.38) 165.606 ms 10g-9-4.hhb002isp005.versatel.de (62.214.110.110) 166.429 ms 166.004 ms 13 62.214.35.138 (62.214.35.138) 173.626 ms 173.356 ms 173.457 ms 14 212.93.14.114 (212.93.14.114) 175.773 ms 174.723 ms 175.221 ms 15 62.214.147.122 (62.214.147.122) 171.947 ms 172.509 ms 290.386 ms traceroute washingtonpost.com
      traceroute to washingtonpost.com (192.33.31.56), 30 hops max, 60 byte packets 2 173.44.32.253.static.quadranet.com (173.44.32.253) 0.194 ms 0.177 ms 0.182 ms 3 ae3-98.mia10.ip4.gtt.net (77.67.71.145) 0.279 ms 0.287 ms 0.233 ms 4 xe-0-2-1.mia12.ip4.gtt.net (141.136.109.130) 0.301 ms xe-4-2-6.mia12.ip4.gtt.net (89.149.131.174) 0.383 ms xe-4-2-4.mia12.ip4.gtt.net (89.149.131.202) 0.334 ms 5 instart-logic-gw.ip4.gtt.net (216.221.156.90) 0.393 ms 0.423 ms 0.412 ms 6 a-vip07.insnw.net (192.33.31.56) 0.263 ms 0.301 ms 0.272 ms What services are running?
      Postfix Nginx Php MongoDB VPN Support:
      No tickets needed.

      Overall experience:
      CPU is sometimes slow, I/O ok and a good network connection.
      Did not have to send a single ticket.
      Update status:

      19 hours 18 minutes of network downtime since the first four months.
      The node did have some rough times during the first month, network itself is solid. 
      Uptime of the vps itself is 26 days.
      CPU and I/O are ok.
      Network is great.
      wget cachefly.cachefly.net/100mb.test -O /dev/null converted 'http://cachefly.cachefly.net/100mb.test' (ANSI_X3.4-1968) -> 'http://cachefly.cachefly.net/100mb.test' (UTF-8) --2016-01-05 00:21:34-- 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' /dev/null 100%[================================================>] 100.00M 73.9MB/s in 1.4s 2016-01-05 00:21:35 (73.9 MB/s) - '/dev/null' saved [104857600/104857600] I will refresh the uptime report every two months.
    • By sammasri85
      Hi ,this is my review on hudsonvalleyhost.com  , two months ago i got a managed VPS from them and here is my results :    - first ,there entire IP range is blacklisted on Spamhaus SBL , not for sending SPAM but for sending ALL kinds of viruses and malware ,as Spamhaus said  here :  https://www.spamhaus.org/sbl/query/SBL228367    means that ,ALL emails coming from there ip's will be marked as SPAM (even if they are not ) and even ALL domains hosted on there ip's will be blacklisted too . the funny thing is that you cannot do anything about it ,because hudsonvalleyhost have to contact spamhaus directly ,and you have nothing to do with that .   - second , there sales team said that they allow email marketing activities on the server ,but , after i paid for it ,the support team said NO they do not allow email marketing on there servers ,and guess what ,they don't offer a refund too .   so ,basically i paid for the VPS ,spend more than 300 $ to setup my mailer and finally i got a blacklisted ip's with a very bad customer support and no refund .   this hosting provider is a wast of time and money ,so ,buyers BE AWARE !!!  
    • By wlanboy
      Provider: NanoVZ
      Plan: OpenVZ 256 MB VPS
      Price: € 3 per year
      Location: Falkenstein, Germany
      Purchased: 01/2015

      Hardware information:
       
      cat /proc/cpuinfo (1x)
      processor : 0 vendor_id : Genu cpu family : 6 model : 58 model name : Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz stepping : 9 microcode : 23 cpu MHz : 1600.000 cache size : 8192 KB physical id : 0 siblings : 8 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf cpuid_faulting pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms bogomips : 6800.62 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: cat /proc/meminfo
      MemTotal: 262144 kB MemFree: 236652 kB Cached: 19944 kB Buffers: 0 kB Active: 10828 kB Inactive: 11328 kB Active(anon): 3980 kB Inactive(anon): 836 kB Active(file): 6848 kB Inactive(file): 10492 kB Unevictable: 0 kB Mlocked: 0 kB SwapTotal: 262144 kB SwapFree: 259280 kB Dirty: 4 kB Writeback: 0 kB AnonPages: 4816 kB Shmem: 2604 kB Slab: 3324 kB SReclaimable: 1368 kB SUnreclaim: 1956 kB dd
      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, 1.80004 s, 74.6 MB/s wget
      wget cachefly.cachefly.net/100mb.test -O /dev/null --2015-03-22 06:39:43-- 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 53.1M/s in 1.9s 2015-03-22 06:39:45 (53.1 MB/s) - `/dev/null' saved [104857600/104857600] Network:
      20 NAT IPv4 Ports /80 IPv6 Subnet 500 GB Transfer traceroute dvhn.nl
      2 hos-tr4-juniper4.rz16.hetzner.de (213.239.233.97) 0.240 ms hos-tr6-juniper4.rz16.hetzner.de (213.239.247.97) 0.211 ms hos-tr3-juniper4.rz16.hetzner.de (213.239.233.65) 0.202 ms 3 core21.hetzner.de (213.239.245.105) 0.217 ms 0.244 ms core22.hetzner.de (213.239.245.145) 0.232 ms 4 core1.hetzner.de (213.239.245.218) 4.823 ms core1.hetzner.de (213.239.245.177) 4.824 ms core1.hetzner.de (213.239.245.218) 4.823 ms 5 juniper1.ams.hetzner.de (213.239.203.158) 10.579 ms 10.578 ms 10.554 ms 6 amsix-501.xe-0-0-0.jun1.bit-1.network.bit.nl (80.249.208.200) 12.275 ms 12.499 ms 12.430 ms traceroute theguardian.co.uk
      2 hos-tr1-juniper3.rz16.hetzner.de (213.239.230.1) 0.208 ms 0.231 ms hos-tr4-juniper4.rz16.hetzner.de (213.239.233.97) 17.155 ms 3 core21.hetzner.de (213.239.245.105) 0.249 ms 0.255 ms core22.hetzner.de (213.239.245.145) 0.740 ms 4 core12.hetzner.de (213.239.245.214) 2.784 ms core12.hetzner.de (213.239.245.29) 2.795 ms core12.hetzner.de (213.239.245.214) 2.794 ms 5 juniper4.rz2.hetzner.de (213.239.245.26) 2.883 ms juniper4.rz2.hetzner.de (213.239.203.138) 2.851 ms 2.808 ms 6 ae51.bar2.Munich1.Level3.net (62.140.25.101) 5.599 ms 17.905 ms ae55.edge7.Frankfurt1.Level3.net (195.16.162.253) 7.347 ms 7 ae-11-51.car1.London1.Level3.net (4.69.139.66) 100.511 ms 100.513 ms 100.737 ms 8 ae-11-51.car1.London1.Level3.net (4.69.139.66) 100.782 ms 100.807 ms 115.422 ms 9 GUARDIAN-UN.car1.London1.Level3.net (212.113.8.30) 17.101 ms 19.110 ms 19.147 ms traceroute sueddeutsche.de
      2 hos-tr1-juniper3.rz16.hetzner.de (213.239.230.1) 0.179 ms hos-tr3-juniper4.rz16.hetzner.de (213.239.233.65) 0.215 ms 0.180 ms 3 core21.hetzner.de (213.239.245.105) 0.465 ms core22.hetzner.de (213.239.245.145) 0.225 ms 0.253 ms 4 core4.hetzner.de (213.239.245.14) 4.894 ms core1.hetzner.de (213.239.245.177) 4.848 ms 4.928 ms 5 juniper1.ffm.hetzner.de (213.239.245.5) 6.329 ms 4.858 ms juniper4.ffm.hetzner.de (213.239.245.1) 4.985 ms 6 ec-r7604-hro-01.ediscom.de (80.81.193.73) 115.008 ms 164.183 ms 164.199 ms 7 212.204.40.54 (212.204.40.54) 22.298 ms 22.144 ms 22.361 ms 8 94.55.204.212-static.ediscom.de (212.204.55.94) 29.183 ms 29.315 ms 29.482 ms traceroute washingtonpost.com
      2 hos-tr1-juniper3.rz16.hetzner.de (213.239.230.1) 0.137 ms hos-tr3-juniper4.rz16.hetzner.de (213.239.233.65) 0.191 ms hos-tr1-juniper3.rz16.hetzner.de (213.239.230.1) 0.159 ms 3 core22.hetzner.de (213.239.245.145) 0.226 ms 0.208 ms 0.245 ms 4 core12.hetzner.de (213.239.245.214) 2.780 ms core12.hetzner.de (213.239.245.29) 2.777 ms core12.hetzner.de (213.239.245.214) 2.790 ms 5 juniper4.rz2.hetzner.de (213.239.245.26) 2.822 ms 2.833 ms juniper4.rz2.hetzner.de (213.239.203.138) 2.886 ms 6 r1nue2.core.init7.net (82.197.163.29) 3.046 ms r1nue1.core.init7.net (77.109.135.101) 2.914 ms r1nue2.core.init7.net (82.197.163.29) 3.059 ms 7 r1lon1.core.init7.net (77.109.140.253) 17.194 ms r1ams2.core.init7.net (77.109.140.157) 53.511 ms r1ams1.core.init7.net (77.109.140.25) 25.195 ms 8 ae-15.r02.amstnl02.nl.bb.gin.ntt.net (80.249.208.36) 19.875 ms r1muc1.core.init7.net (77.109.128.231) 7.392 ms ae-15.r02.amstnl02.nl.bb.gin.ntt.net (80.249.208.36) 20.065 ms 9 ae-15.r02.amstnl02.nl.bb.gin.ntt.net (80.249.208.36) 15.684 ms ae-2.r22.amstnl02.nl.bb.gin.ntt.net (129.250.2.112) 18.386 ms ae-2.r03.londen01.uk.bb.gin.ntt.net (129.250.3.8) 26.441 ms 10 ae-1.r02.londen01.uk.bb.gin.ntt.net (129.250.3.36) 27.145 ms ae-15.r02.amstnl02.nl.bb.gin.ntt.net (80.249.208.36) 14.428 ms ae-5.r23.londen03.uk.bb.gin.ntt.net (129.250.5.197) 32.894 ms 11 62.73.179.186 (62.73.179.186) 25.374 ms ae-5.r23.londen03.uk.bb.gin.ntt.net (129.250.5.197) 18.976 ms 62.73.179.186 (62.73.179.186) 17.573 ms 12 ae-2.r02.londen01.uk.bb.gin.ntt.net (129.250.3.1) 25.938 ms * 24.876 ms 13 * * * 14 * * * What services are running?
      OpenVPN Nginx (both behind CloudFlares IPv4 Proxy) Ruby workers Support:
      No tickets needed.

      Overall experience:
      CPU ok, I/O could be better and a good network connection.
      Did not have to send a single ticket.

      Update status:

      0 minutes of network downtime since the first month.
      The node did have some rough times during the first weeks, I/O itself does have some spikes but is quite solid. 
      Uptime of the vps itself is 56 days.
      CPU is ok and I/O could be better.
      Network is good within the EU.
      wget cachefly.cachefly.net/100mb.test -O /dev/null --2015-03-22 06:39:43-- 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 53.1M/s in 1.9s 2015-03-22 06:39:45 (53.1 MB/s) - `/dev/null' saved [104857600/104857600] I will refresh the uptime report every two months.
    • By GIANT_CRAB
      Hey all, 
       
      So it has almost been a year since I have been with Cloudshards. So here's my experience with them: 
       
      I've heard a lot of good things about Cloudshards and the prices are really amazing so I decided to spin up a 2GB OpenVZ with them on 27/03/2014. As of now, I have 2 VPS with Cloudshards and they are working really great. Although the company name has the word 'cloud' in it, Cloudshards doesn't provide Cloud Hosting services yet. 
       
      Uptime: 10/10
       
      So far, no downtime in terms of both network and hardware. They have some downtime once every few months due to scheduled network maintenance or upgrade but they gave a good window of 3 to 5 days before carrying it out so that all the customers will be well prepared for the scheduled downtime. 
       
      Network: 10/10
       
      Their network connectivity worldwide has very low latency and is really superb! Connectivity to Asia was especially great and I've gotten only 160ms from Singapore. :) 
       
      Here's a ping to my Los Angeles Cloudshards VPS

       
      Support: 9/10
       
      Their support team replied within 4 hours and they read through my issues carefully. I've once experienced unreliable network connectivity and opened a support ticket with them. Within a few hours, they replied to me and told me it was because there was a DDoS on the node and offered to transfer me to another node. I accepted the transfer and it was done within minutes! :)
       
      Prices: 10/10
       
      I spun up a few VPS with lots of RAM and they only cost $7 for 2GB. For the price and service offered, it is a really great deal! They also offer KVM storage with lots of space and it is very affordable too. I've also asked for a customized upgrade from 2GB to 4GB and they did so without much hesitation. 
       
      Overall, their VPS offer very smooth performance with great network speeds and latency at really affordable price. 
       
      Thank you Cloudshards for giving me such a memorable experience! :)
    • By wlanboy
      Provider: NanoVZ
      Plan: OpenVZ 128 MB VPS
      Price: € 3 per year
      Location: Roubaix, France
      Purchased: 01/2015

      Hardware information:

      cat /proc/cpuinfo (1x)
      processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 26 model name : Intel(R) Xeon(R) CPU W3530 @ 2.80GHz stepping : 5cpu MHz : 2800.140 cache size : 8192 KB physical id : 0 siblings : 8 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 sse4_2 popcnt lahf_lm ida dts tpr_shadow vnmi flexpriority ept vpidbogomips : 5600.28 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: cat /proc/meminfo
      MemTotal: 131072 kB MemFree: 100784 kB Cached: 18156 kB Buffers: 0 kB Active: 17320 kB Inactive: 8908 kB Active(anon): 5152 kB Inactive(anon): 2920 kB Active(file): 12168 kB Inactive(file): 5988 kB Unevictable: 0 kB Mlocked: 0 kB SwapTotal: 131072 kB SwapFree: 125448 kB Dirty: 4 kB Writeback: 0 kB AnonPages: 8072 kB Shmem: 2604 kB Slab: 4048 kB SReclaimable: 1124 kB SUnreclaim: 2924 kB dd
      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, 2.47973 s, 54.1 MB/s wget
      wget cachefly.cachefly.net/100mb.test -O /dev/null --2015-02-25 00:21:23-- http://cachefly.cachefly.net/100mb.testResolving 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 OKLength: 104857600 (100M) [application/octet-stream] Saving to: `/dev/null' 100%[========================================================>] 104,857,600 31.8M/s in 4.0s2015-02-25 00:21:27 (25.0 MB/s) - `/dev/null' saved [104857600/104857600] Network:
      20 NAT IPv4 Ports /80 IPv6 Subnet 100 GB Transfer
      traceroute dvhn.nl
      2 rbx-g1-a9.fr.eu (213.186.32.253) 0.874 ms 1.045 ms 1.026 ms 3 ams-1-6k.nl.eu (94.23.122.186) 5.531 ms * * 4 amsix-501.xe-0-0-0.jun1.bit-2a.network.bit.nl (80.249.208.35) 7.341 ms 6.905 ms 7.282 ms traceroute theguardian.co.uk
      2 rbx-g1-a9.fr.eu (213.186.32.253) 0.837 ms 1.042 ms 1.071 ms 3 th2-g1-a9.fr.eu (91.121.215.132) 4.607 ms th2-g1-a9.fr.eu (91.121.131.210) 4.227 ms 4.600 ms 4 * * gsw-1-6k.fr.eu (91.121.215.135) 13.906 ms 5 * * * 6 ae-15-51.car5.London1.Level3.net (4.69.139.70) 7.661 ms 8.227 ms 7.977 ms 7 ae-15-51.car5.London1.Level3.net (4.69.139.70) 8.100 ms 8.618 ms 8.390 ms 8 GUARDIAN-UN.car5.London1.Level3.net (217.163.45.90) 7.910 ms 7.982 ms 7.925 ms traceroute sueddeutsche.de
      2 rbx-g1-a9.fr.eu (213.186.32.253) 0.874 ms 1.038 ms 1.038 ms 3 ams-1-6k.nl.eu (94.23.122.114) 5.646 ms * * 4 AMDGW1.arcor-ip.net (80.249.209.123) 6.443 ms 6.381 ms 10.108 ms 5 bln-145-254-5-158.arcor-ip.net (145.254.5.158) 19.876 ms 19.829 ms 19.747 ms 6 82.82.24.142 (82.82.24.142) 19.131 ms 19.200 ms 19.218 ms 7 212.204.41.194 (212.204.41.194) 26.180 ms 26.155 ms 26.101 ms traceroute washingtonpost.com
      2 rbx-g1-a9.fr.eu (213.186.32.253) 0.850 ms 0.996 ms 1.050 ms 3 th2-g1-a9.fr.eu (91.121.131.210) 4.471 ms th2-g1-a9.fr.eu (91.121.215.132) 4.488 ms th2-g1-a9.fr.eu (91.121.131.210) 4.374 ms 4 * * * 5 * * * 6 NEUSTAR-INC.edge3.Paris1.Level3.net (212.73.242.130) 4.416 ms 4.375 ms 4.316 ms What services are running?
      Postfix Nginx (both behind CloudFlares IPv4 Proxy) Php Redis Support:
      No tickets needed.

      Overall experience:
      CPU ok, I/O ok and a good network connection.
      Did not have to send a single ticket.

      Update status:

      3 hours 29 minutes 35 seconds of network downtime since the first month.
      The node did have some rough times during the first weeks, network itself does have some spikes but is quite solid. Hoping for some calm weeks.
      Uptime of the vps itself is 30 days.
      CPU and I/O are ok.
      Network is good within the EU.

      I will refresh the uptime report every two months.