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.
Comments
No worry, it is a routing problem at your end, but you dont need it much anyway, so why bother.
M
We're definitely having some routing issues going on... Fran just yanked HE completely from two of our ranges to try that out and see if it improves things. This is priority for us today, so you can expect much better results soon :P
Ok thanks
If it helps heres my traceroute:
And via ipv6 (he.net tunnel)
BuyVM
InceptionHosting (NL)
SecureDragon
Some random server in Germany
You are consistently getting worse results than me
Nevertheless, BuyVM is pulling an impressive result taking into consideration the distance.
Please put the file on your BuyVM machine to test from my machines and home, if I cant have one, at least i could test indirectly, of course, if aldryic doesnt mind.
M
http://buyvm.net/100mb.test
I am interested in how regular VPSes behave. Some QoS can be yanked to give priority to that.
Nevertheless, here it is:
Prometeus:~# wget http://buyvm.net/100mb.test
100%[======================================>] 104,857,600 1.06M/s in 76s
2012-03-31 01:45:36 (1.32 MB/s) - `100mb.test.1' saved [104857600/104857600]
Home
100%[======================================>] 104,857,600 2.57M/s in 41s
2012-03-31 00:48:32 (2.45 MB/s) - “100mb.test” saved [104857600/104857600]
Edis:
100%[======================================>] 104,857,600 2.66M/s in 46s
2012-03-30 23:51:20 (2.18 MB/s) - “100mb.test” saved [104857600/104857600]
BlueVM
100%[======================================>] 104,857,600 4.00M/s in 16s
2012-03-31 00:54:06 (6.33 MB/s) - `100mb.test.1' saved [104857600/104857600]
As we can see, the results vary wildly, also there was big variation within the transfer, I watched closely, it was between 300 k and over 8 M overall, within same transfer was a variance like from 500 k to 5 M. Starting slower, getting fast with another slowing down almost stop at like 50%. Hope this helps in diagnosing the problem. My guess is their provider has uneven peering within US and some destinations are much worse than others, hence some ppl are upset, others are satisfied.
M
This, retard
G-T-F-O
Now nobody cares about you...
Thank you for the valuable input, this is not a "who is praising more BuyVM" competition, at least not for me. I have nothing to gain or lose here you are free to believe what you want.
M
@Maounique The world is definitely oversold. May be you must guide us in finding a better world.
If you really would value your own time, stop owning up such missions. I really do not bother about BW issues in BuyVM. People who have paid for their bandwidth with them would be in a better position to decide that. You sound no better than a troll by judging a host based on copy pasted speed tests. You sounded so positive before this stock release (AUP update era..) and so grumpy now. Your account rejected again?
PS : Next troll idea >> Uptime: They are just faking it.. Find for us how..
I was positive, i thought things changed, but it was just an attempt to sell more IPs since they obviously have more than BW and hardware.
There was no need to SWIPe before for non-exit node, there is none now. I wasnt rejected, i just choose not to go for it without testing and there is when the deal collapsed. I currently have better deals and more BW, I wouldnt have gone for a worse deal AND 5 $ surcharge without a test.
As I said many times, I couldnt care less if BuyVM is allowing Tor or not (the BW is "thin" even if I would get to use it), all I care is for the lies they are spreading against us. As long as they continue to claim the same "truths", I will continue to search for the real reasons behind that. I think I finally found the reason, many other ppl confirmed it, however few are daring to come here and be singled out by the lynch mob and denied service for some reason. Why do you think they dont open tickets ? A "troblemaker" will be shown the door, we all know they lose money for every customer and should be left alone because support is expensive. Ppl will see there are cheaper and better alternatives and then all the castle of cards will collapse.
M
Who is "us"?
If you are asking me, and you refer the lies they spread about us part, then I mean the lies against Tor volunteers 95% of which are porn addicts while the rest in very sketchy sites as well. Who needs privacy except the ppl that have something to hide, thinggie.
M
Lol k, I dont like you either.
.. anyhow, quickpacket (the atlanta 15/y) has been superb for me re: Netflix. Never noticed a drop (scandinavia).
Wrong.
I envy to death looking at your speed test T_____T
Sad to read that u_u
Because I wasn't talking to you, but to the Maon00b retard
Oh, sorry, I just responded with hostility.
Sorry
I figured you were attacking me.
@Aldryic Currently getting around 7.0Mbps, which is the fastest I think I've ever got from the pony. Almost triple the usual speed...
There's definitely a problem with BuyVM routing, most probably right at their DC. All you need to do is compare their test file with this one, from another VPS provider in the same Coresite DC in San Jose: http://ping.lightwave.net/test100MB.bin
My tests from VPSs in San Diego, Chicago and Italy all showed the same pattern: light wave was always at least 3x faster, and BuyVM did have the crazy oscillations that have been mentioned. I cant post traceroutes because this was via SSH on my phone, but as expected, they were ALMOST identical for the two companies. The only difference each time was that BuyVM had one additional hop just before jael (buyvm.net) -- 173.245.86.18, which wouldnt resolve but appears to be an EGI router.
The buyvm testfile can be wonky at times - try this one I've put up: http://uncreative.ccut.in/testfile
@quirkyquark From Kiloserve in LA:
M
I don't know if that's a compliment or an insult...
SSH tunneling to the Central US (Minnesota) on a 20/12 connection:
Hetzner: http://www.speedtest.net/result/1867150900.png
BuyVM: http://www.speedtest.net/result/1867155129.png
Honestly, don't know how I can get faster download speeds from Germany with 60+ ms higher latency. I also can pull a full 20 megabit/s from other California hosts, so there may be some issues with their network atm. Whatever though, everything else with BuyVM is amazing.
Just thought i'd try this out before heading to bed and i was surprised by the result. I'm not taking any sides but these were the result that came in from UK, Germany and NL.
root@NL ~]# wget http://buyvm.net/100mb.test
--2012-03-31 13:00:53-- http://buyvm.net/100mb.test
Resolving buyvm.net... 205.185.112.61
Connecting to buyvm.net|205.185.112.61|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 104857600 (100M) [application/octet-stream]
Saving to: `100mb.test'
100%[======================================>] 104,857,600 452K/s in 2m 11s
root@UK:~# wget http://buyvm.net/100mb.test
--2012-03-31 18:01:02-- http://buyvm.net/100mb.test
Resolving buyvm.net... 205.185.112.61
Connecting to buyvm.net|205.185.112.61|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 104857600 (100M) [application/octet-stream]
Saving to: `100mb.test'
100%[======================================>] 104,857,600 448K/s in 4m 2s
[root@germany ~]# wget http://buyvm.net/100mb.test
--2012-03-31 12:58:42-- http://buyvm.net/100mb.test
Resolving buyvm.net... 205.185.112.61
Connecting to buyvm.net|205.185.112.61|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 104857600 (100M) [application/octet-stream]
Saving to: `100mb.test'
100%[======================================>] 104,857,600 167K/s in 6m 8s
From a UK VPS:
sjc2.d3vm.net=buyvm
lion.d3vm.net=kiloserve
Truly bizarre: my 128MB BuyVM also pulls from lightwave 3x faster than BuyVM.net (or indeed, cedr's test file):
Before maounique jumps in, I'd like to add that this is only an attempt to help buyvm resolve whatever the cause of this bottleneck is. I consider his theories tinfoil until I get booted for using less than my 500GB
In any case, the traceroutes will show that both lightwave and buyvm are using the same carriers on a given route, so the "buyvm carrier is stingy with peering" theory doesn't seem to hold much weight either.
@quirkyquark I get the same numbers, almost identically...
One thing that I've always found strange, and it's probably nothing -- whenever I ping my vpses on Buyvm, the first ping is always around 500-900ms, then they drop down to 220-250ms (which is where they should be)... It's the only provider I have that seems to be doing this... Not really an issue, just an observation...
@kendid it's because when the VPS has not made any traffic for a long time the ARP entry is flushed. So when you try to reach the VPS for the first time after the ARP is no longer there - there has to be an ARP request / ARP reply, and only then the IP packet can reach the correct node.
And if you want to avoid that - you can leave a background ping to somewhere running on the VPS, this way you ARP entry will not be expired.