New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
PrismaVPS expands to Romania (Voxility provider w/ Level3 and HE)
pubcrawler
Banned
Not affiliated with this company other than being a very satisfied customer.
PrismaVPS, who I've recommended on here for their $30 year VPS has expanded to Romania. Same plans are available now in Romania (neighbor of the Middle East and -Russia- Ukraine, Bulgaria, Serbia, Hungary, Slovakia and the Black Sea).
256MB / 512MB swap / 20GB disk / 2 cores / 2 TB transfer a month $30/year.
Comments
Should be a good location.
Seeing Level3 and HE to their Romania location.
Voxility (the facility provider) just penned a 250Gbps deal with Level3 in May:
Level 3 to provide 250 Gbps to support rapidly growing company
LONDON, May 15, 2012 /PRNewswire/ -- Level 3 Communications, Inc. (NYSE: LVLT) today announced a multiyear contract with European-based content provider Voxility. Under the terms of the agreement, Level 3 will provide more than 250 Gbps to Voxility's three major datacenters, located in North America and Europe, providing a substantial amount of capacity to support the company's continued global growth. >
That's interesting and something I didn't know @Jack. Cogent has more than a fair amount of problem people on their own network. So odd war there.
@pubcrawler edit title / company name.
You'd think the nature of the internet being redundant that everyone would route around problems/blocks like this by going over other providers.
Virginmedia is a big company.
Bad issue when a single provider can offline slews of folks. At minimum we need an active site to centralize all these oddball issues with upstream providers.
@Jack try traceroute to 109.163.233.100
109.163.233.1 seems to be blackholed, probably DoS target or something.
C:\Users\Lost>tracert 109.163.233.100
Tracing route to lh19444.voxility.net [109.163.233.100]
over a maximum of 30 hops:
1 * * * Request timed out.
2 * * * Request timed out.
3 * * * Request timed out.
4 * * * Request timed out.
5 * * * Request timed out.
6 * * * Request timed out.
Got to love my ISP.
Strange, the .100 works from all the 6 different locations i tried, .1 is blackholed.
None of these locations are cogent though.
@Jack I don't get that, and I'm on Virgin Media, but a different Virgin Media routing station.
I know, you're probably right about Cogent dropping that block, I traced from a few VPS's and they none go through Cogent.
http://lowendping.nikkii.us/
According to that, edis and secure dragon go through Cogent and seems to be working.
I just tested from around a dozen servers around the world.
All worked fine to end of 109.163.233.100.
But, what I do notice is if Cogent is the upstream, Cogent quickly dumps off typically to Level3 and Level3 takes the packet to the end destination.
Haven't dug too much inside Cogent itself. They have a public looking glass:
http://www.cogentco.com/en/network/looking-glass
Run ping and traceroute from there.
Clearly, Cogent has some issue with Voxility because Cogent is notorious for hogging packets and taking them the whole distance (cheaper to do so) even when the routing is far out of the way geographically. So in some ways, this might be a much better thing for Cogent-dependent users
One place I see clear mucked up hauling by Cogent on this block is from Bucharest to that IP which is Bucharest and very well might be in the same facility.
They haul the traffic through France, back to Amsterdam then handoff to Level3 which goes through Germany back. 69ms of wasted time.
Doing a trace from their Bucharest location is pretty funny..
From Cogent's network in Europe to this 109.163.233.100, seeing nearly total loction backhaul to London and Amsterdam.
As such, latency is greatly increased if upstream is Cogent and in Europe.
@ihatetonyy, agree, that is what I am seeing and referring to.
Cogent is too often like that though. They don't seem to have very many peering locations for handoffs to other providers.
AS traceroute to 109.163.233.100 30 hops max, 40 byte packets
3 v249-gw-6 (68.181.194.65) 0.841 ms 0.592 ms 0.648 ms
4 lax-dc1--losnettos-dc.cenic.net (137.164.23.225) 0.795 ms 0.704 ms 0.626 ms
5 dc-lax-core2--lax-agg1-ge.cenic.net (137.164.46.107) 1.267 ms 0.941 ms 1.068 ms
6 dc-lax-isp2--lax-core2-10ge.cenic.net (137.164.47.138) 0.834 ms 0.734 ms 0.848 ms
7 xe-9-3-0.edge5.LosAngeles1.Level3.net (4.59.48.177) 1.048 ms 0.737 ms 0.845 ms
8 vlan90.csw4.LosAngeles1.Level3.net (4.69.144.254) 0.840 ms vlan70.csw2.LosAngeles1.Level3.net
9 ae-93-93.ebr3.LosAngeles1.Level3.net (4.69.137.45) 0.832 ms 0.950 ms
10 4.69.132.82 (4.69.132.82) 64.079 ms 64.942 ms 64.981 ms
11 ae-71-71.csw2.Washington1.Level3.net (4.69.134.134) 64.113 ms
12 ae-62-62.ebr2.Washington1.Level3.net (4.69.134.145) 64.022 ms
13 ae-41-41.ebr2.Paris1.Level3.net (4.69.137.49) 144.797 ms 143.359 ms 143.196 ms
14 ae-47-47.ebr1.Frankfurt1.Level3.net (4.69.143.141) 151.626 ms
15 ae-91-91.csw4.Frankfurt1.Level3.net (4.69.140.14) 163.051 ms 153.926 ms
16 ae-1-60.edge6.Frankfurt1.Level3.net (4.69.154.10) 171.756 ms
17 62.67.38.6 (62.67.38.6) 149.197 ms l3b-c2.hlkomm.net (62.67.38.10) 313.653 ms
18 buc-ird-03gw.voxility.net (109.163.235.165) 177.390 ms buc-ird-04gw.voxility.net
19 buc-ird-01c.voxility.net (109.163.235.62) 184.133 ms buc-ird-01c.voxility.net
20 lh19444.voxility.net (109.163.233.100) 181.994 ms 178.011 ms 178.912 ms
2 7 0 0 4.69.145.254 vlan90.csw4.dallas1.level3.net
3 0 0 0 4.69.151.170 ae-93-93.ebr3.dallas1.level3.net
4 20 20 21 4.69.134.22 ae-7-7.ebr3.atlanta2.level3.net
5 33 33 33 4.69.132.86 ae-2-2.ebr1.washington1.level3.net
6 33 33 38 4.69.134.130 ae-61-61.csw1.washington1.level3.net
7 33 33 33 4.69.134.145 ae-62-62.ebr2.washington1.level3.net
8 113 113 114 4.69.137.49 ae-41-41.ebr2.paris1.level3.net
9 122 122 122 4.69.143.133 ae-45-45.ebr1.frankfurt1.level3.net
10 121 123 121 4.69.140.6 ae-71-71.csw2.frankfurt1.level3.net
11 121 121 121 4.69.154.74 ae-2-70.edge6.frankfurt1.level3.net
12 123 123 123 62.67.38.10 l3b-c2.hlkomm.net
13 155 155 155 195.60.76.61 buc-ird-01gw.voxility.net
14 156 151 150 109.163.235.50 buc-ird-01c.voxility.net
15 154 154 154 109.163.233.100 lh19444.voxility.net
Canada
3 (66.38.255.41) 4.407 ms 4.396 ms 4.378 ms
4 POS5-0.WANA-VANCBC.IP.GROUPTELECOM.NET (66.59.190.194) 15.438 ms 15.426 ms 15.419 ms
5 POS7-0.WANA-CALGAB.IP.GROUPTELECOM.NET (66.59.190.22) 15.388 ms 15.371 ms
6 bx4-vancouver_ge1-1-3.net.bell.ca (67.69.199.149) 16.662 ms 16.730 ms 16.667 ms
7 core4-vancouver_ge8-0-0.net.bell.ca (64.230.183.109) 18.937 ms 18.964 ms *
8 core1-seattle_pos13-1-0.net.bell.ca (64.230.77.211) 19.040 ms 18.992 ms 134.490 ms
9 bx2-seattle_POS10-0-0.net.bell.ca (64.230.186.22) 19.166 ms 19.136 ms 19.108 ms
10 ge-6-5.car3.Seattle1.Level3.net (4.71.152.41) 220.708 ms 220.737 ms 220.873 ms
11 ae-32-52.ebr2.Seattle1.Level3.net (4.69.147.182) 74.340 ms 74.373 ms 74.362 ms
12 ae-2-2.ebr2.Denver1.Level3.net (4.69.132.54) 68.172 ms 67.430 ms 71.450 ms
13 ae-3-3.ebr1.Chicago2.Level3.net (4.69.132.62) 77.489 ms 77.459 ms 77.492 ms
14 ae-1-100.ebr2.Chicago2.Level3.net (4.69.132.114) 68.101 ms 74.206 ms 74.231 ms
15 ae-6-6.ebr2.Washington12.Level3.net (4.69.148.145) 73.665 ms 73.605 ms 75.042 ms
16 ae-5-5.ebr2.Washington1.Level3.net (4.69.143.221) 74.058 ms 74.853 ms 74.379 ms
17 ae-42-42.ebr2.Paris1.Level3.net (4.69.137.53) 154.683 ms ae-44-44.ebr2.Paris1.Level3.net
18 ae-47-47.ebr1.Frankfurt1.Level3.net (4.69.143.141) 157.220 ms
19 ae-91-91.csw4.Frankfurt1.Level3.net (4.69.140.14) 153.674 ms 155.648 ms
20 ae-2-70.edge6.Frankfurt1.Level3.net (4.69.154.74) 154.611 ms
21 212.162.24.154 (212.162.24.154) 160.350 ms l3b-c2.hlkomm.net (62.67.38.10) 157.394 ms 62.67.38.6 (62.67.38.6) 156.161 ms
22 buc-ird-03gw.voxility.net (109.163.235.165) 184.577 ms 185.218 ms buc-ird-
23 buc-ird-01c.voxility.net (109.163.235.62) 190.075 ms buc-ird-01c.voxility.net
24 lh19444.voxility.net (109.163.233.100) 190.216 ms 192.400 ms 189.681 ms
BTW
Turkey and India 10% loss sometime
Bucharest, Romania 0.4
Doing base testing and setup on one of these VPSes in Romania.
Will post results as I get them in.
Here's are some numbers from the Romania server:
wget freevps.us/downloads/bench.sh -O - -o /dev/null|bash
CPU model : Intel(R) Xeon(R) CPU E31240 @ 3.30GHz
Number of cores : 4
CPU frequency : 2128.000 MHz
Total amount of ram : 512 MB
Total amount of swap : 512 MB
System uptime : 3 min,
Download speed from CacheFly: 16.2MB/s
Download speed from Linode, Atlanta GA: 2.36MB/s
Download speed from Linode, Dallas, TX: 3.34MB/s
Download speed from Linode, Tokyo, JP: 2.48MB/s
Download speed from Linode, London, UK: 23.3MB/s
Download speed from Leaseweb, Haarlem, NL: 7.53MB/s
Download speed from Softlayer, Singapore: 3.08MB/s
Download speed from Softlayer, Seattle, WA: 811KB/s
Download speed from Softlayer, San Jose, CA: 184KB/s
Download speed from Softlayer, Washington, DC: 1.26MB/s
I/O speed : 69.0 MB/s
Not a fan of this script since it is 4 networks only. Nearly uniform low performance throughput with Softlayer there. Why Singapore performs so much better on throughput makes me wonder. See similar bump to Linode Japan too. Perhaps less monitoring/recording of packets ?
I highlighted that provider here some time ago, http://www.lowendtalk.com/discussion/5180/prismavps-1gb-openvz-w-4tb-transfer-1gb-for-5mo
IMHO the interesting deal from them is not $30/yr, but the $5/mo offer.
Been using an US VPS from them for quite some time, no problems so far.
Got a box in RO today, turns out the Romania location doesn't have IPv6, unlike their US one. Also the closest he.net tunnel server is ~35ms away, and 6to4 does not work (192.88.99.1 not accessible). Not a good place to be for a v6 fan
While that's true, the majority of routes seem to go via Frankfurt first anyway :S
;-)
Cachefly goes a bit faster:
wget -O /dev/null http://cachefly.cachefly.net/100mb.test
--2012-10-22 01:58:44-- 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 25.2M/s in 4.3s
2012-10-22 01:58:49 (23.5 MB/s) - `/dev/null' saved [104857600/104857600]
1: pn5000.prismavps.com 0.028ms
2: buc-ird-03gw.voxility.net 0.437ms asymm 3
3: fra-anc-03gw.voxility.net 33.635ms asymm 4
4: vip1.G-anycast1.cachefly.net 32.314ms reached
4 hops to France and 32ms, more than acceptable.
@rm_ - agree we use their $5 month plan too. Mainly for disk space reasons.
Local Debian mirror for this location is:
http://ftp.lug.ro/debian/
That is under 1ms away
Very fast mirror.
The ipv6 problem keeps me down too. I have a server colo there.
IPv6 is coming since early august...
M
2013 is shaping to be the year when everyone gets on the IPV6 train, probably all at once.
Not seeing the move yet, but the train can be heard from here
We have a few extra European providers in our script, will probably add more eventually but 1.4Gb of downloads seems like enough for now :P
Thanks @serverbear. Glad to hear.
More servers, different networks and more geographic areas would be nice --- even if just an option or something.
@Jack I'm not sure why nobody has asked this, but how did you manage to find a tech who was capable of answering such a question?
@Jack I mean, when I call for support, I get stuck with an idiot who tells me to restart my modem lol
Just now there's been a DDOS or something, 80% packet loss for over 2 hours.
Packet loss to Romainia server @rm_?
I was away from the computer painting. So I missed the excitement if so.
Did you send a ticket into PrismaVPS about that?