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
I actually noticed some time ago, but thought it is because of my location. I dont buy on west coast unless the "customer" asks, even so i recommend against it. Chicago is a much better choice, usually.
@Maounique, I noticed this well over a year ago, might be two. But thought I just wasn't in enough locations to really give it a fair test. Now I am so two foot stomping on these types of issues.
Chicago is US Central, along with Kansas City and Dallas. Any of them works real well and in some instances not bad times to Europe either depending on peering and direct routes. Unsure how they do for Asia, as we stay out of that section of the world mainly due to price.
We transferred about 1.5 TB of data over the course of several weeks from EGI to Fiberhub and it was painful at times. Speeds varied wildly.
@qps, I can understand that.
Something is majorly wrong coming out of EGI's network.
HE might be part of the problem between Fiberhub and there. Odd because the problems are uni-directional. Try downloading from Fiberhub from EGI network and probably will be fine.
I am done debugging the slop on the West Coast. Cancelled last account we had on the West Coast today and pulling back to Vegas, Dallas and Kansas City.
Actually here's another fun one we had it out with EGI over.
TCP is the only protocol that seems to have the issue.
When I was showing proof of speed issues downloading to my house, when I used TCP it would be slow as balls. Jump on an OpenVPN running in SJ over UDP? line rate single thread.
Francisco
Well that pretty much clarifies it @Francisco. A single protocol doesn't misbehave for everyone paying attention. It's shaping / QoS. Almost impossible scenario for it to be otherwise.
I've had a similar experience with shaping in a few facilities where HTTP traffic was degraded but stuffing the traffic in a SSH tunnel worked just magically fine and speedy. That's part of why I started using SSH tunnels commonly in all our node installs.
Constantly amazed how many networks in the States are severely impacted and degraded by such foolishness. Much more rare to see it with international / non-US data facilities. The US West coast is particularly bad with these degraded networks. Blaming it on big open spaces is what folks use to do and point to transit like HE being crappy.
Really getting weary with HE as they often seem to be in this mess, but part of that is the el cheapo pricing that gets oversellers abusing their small commits.
@Francisco, question is, what did EGI say about TCP being the only impact? Blame it on your config/routers?
Bingo.
Like I said, we went from an HP Procurve 2848 -> Dell 5324 ( @mitgib was this the right model?) -> Force10 S50's.
Each time speed was better for a little bit then went to crap once more. Understand we're doing basic layer2, no layer3 done by the switches. All of those switches can handle their own and likely have no issues doing line rate layer2 forwarding.
Infact at one point we were looking at a brocade RX but EGI kept speaking poorly of it. Come to find out Rob at Fiberhub has an RX16 (same as an RX-4/8 just in a bigger chassis) and shoves 40Gbit/sec+ through it with tons of ports to spare. His only hindering point is going to be the routing table limits.
As I mentioned, we have a force10 in colocrossing and the only issues we've had over there was their junipers accept nullroutes slower than we liked. If a flood was strong enough, it was knocking our vyatta out before colocrossing would accept the autonull and we were in a nasty catch 22.
I rebuilt the router at the start of the month with the same setup we got in SJ and have no problems handling ~1M pps on gig ports. When we upgrade to 10Gbit in our west coast setup, we'll be good till 6Mpps - 7Mpps or so.
Francisco
@Francisco, and the reason why our SSH tunnel thingy can't fix the problem is vast majority of all our traffic is HTTP. The tunnel is fine for talking to other nodes and backends, but the pile up and slow down still happens to end user where this QoS crap is going on.
Nothing like penalizing yourself/customers/etc. by choosing a busted, de-optimized network, growl.
I frown about vendors whining about gear like that (Force 10). I'd trust them for the big facility stuff, but this stuff, no, it's just a pissy fit by someone with some allegiance to something else.
Amazing throughput there at Fiberhub. Didn't realize they were pushing that much traffic already.
Know you mentioned it / been asked before, but is DDoS protection option going to be available at Fiberhub from you folks when you get moved? Not that I need it, but good to have some nodes with it just as insurance / sanity thing.
Yep. Latency will improve 7ms as well.
Francisco
7ms. That's significant. Could be 10%+ given route and distance.
Awknet is based out of LA so everything peers to LAX. Fiberhub backhauls the majority of their transit from the same POP so the only distance is the usual path it'd have to take anyways (LAX <> LAS)
Right now it's anywhere from 10ms <> 15ms for LAX<>SJ. It'd be less if EGI actually used ANY2IX but I've yet to see a single route take it.
Francisco
I wonder by EGI never used ANY2IX... That is a Coresite sale item and I'd think more affordable than other options and the connection is already available from Awknet to Coresite SJ.
Just a weird setup, but there is always some "logical" reason.
Wondering if Fiberhub is going to be pulling other new providers from same LAX peer point or bringing them in other ways?