Uncategorized

Comcast Xfinity vs CenturyLink in Denver – Side by Side Comparison

Posted on

So when the guy knocked on the door and offered a free trial of CenturyLink I said, “Why Not?”  He was a likeable guy who got me through the process with a limited amount of paperwork and phone call confirmation. He scheduled a phone call and most importantly of all, didn’t take my credit card.. nobody did, so fingers crossed the cancellation process is smooth.

This is a comparison of the best services that both companies can offer to me, and includes Speedtest outputs, and my open ping and 1gb file downloads (using SABNZBD).

Getting Connected

Firstly the good.  The century link guy arrived on the day he was supposed to. There was no time window specified but I wasn’t required to be home. He was a good guy and did the job quickly and efficiently and even used his tone device outside to help me work out if my internal wiring was good (which it wasn’t).  So, full points for helpfulness there. He could have said that internal wiring isn’t part of the job and gone on his merry way and left me without a good starting point.

Now the bad.  The wiring from the riser to the panel on the house was dead, and my neighborhood has a no overhead cable policy so he had to run a temporary wire over the ground and schedule a crew to come out and replace it with a buried cable.. which would have to go through sprinkler territory so not so keen on that.  Still. Can’t exactly give them a bad mark for what the previous owner probably is to blame for – a broken underground cable.

So, next step was to fix internal wiring.  Didn’t take long.. took a voltage reading at the box where the signal was coming in, and crawled around the basement trying to find the wire that went in to the house, then traced the wire from the socket where my modems live back to the basement and connected both together. Good to go. Same voltage at the plug as the external box, so seems good to go.

 

Setting up the modem

Full marks here.  No “You must have Windows or a Mac” tragedy.   Simple physical connect followed by browser based signup.  As I couldn’t find my ethernet dongle I was happy to find a note in the instructions about wireless that the wireless SID and password were on the modem, and they were, and they worked and that’s how I signed up.  The process got stuck at 44%, “Getting your computer ready to use the network” but behind the scenes it finished anyway, and a refresh saw me surfing the web.

 

About the Testing

This is where things start to go downhill very quickly.  CenturyLink were only able to their lower end service to my address.   It wouldn’t surprise me if that got upgraded over time as my Comcast service has, but the starting offering is quoted as 10Mb/s down, 1Mb/s up.    I only thought about trying this because when you talk to CenturyLink people they always talk about what a big wide pipe they have.. and talk about how Comcast speeds are really artificially high when you test them, because they boost the first bit of traffic spike, then throttle things down to something more sane.  This is definitely true.  On Comcast you can download a 1mb file instantly, but it takes more than 1000 times the time to download a 1gb file.  So, this claim of initial burst is true, but it’s a great feature. Apart from big downloads and streaming movies, typical web surfing is just a long series of small bursts.

Speedtest.net results – Xfinity vs CenturyLink performance and speed

So.  here are the side by side comparisons using Speedtest.net from the same machine connected by ethernet cable to the respective modems.

CenturyLink.. Oh My!

Through default test location

Ping: 42ms

Download: 10.29Mb/s

Upload: 0.68Mb/s (ouch)

Through Stockholm (a non local test center unlikely to be trying to bias Speedtest.net)

Ping: 192ms

Download: 6.14

Upload: 0.65

Comcast / Xfinity

Through default test location

Ping: 30ms

Download: 57.82Mb/s

Upload: 11.25Mb/s

Through Stockholm (a non local test center unlikely to be trying to bias Speedtest.net)

Ping: 182ms

Download: 7.9Mb/s

Upload: 4.33Mb/s

 Speedtest.net conclusions

Interesting.  Well no matter what way you look at it, Xfinity is faster.. and based on these numbers one would say faster by a number of magnitudes.  At twice the price, Xfinity represents value for money here.  What is interesting through is the Stockholm based result.  It still shows that Xfinity is faster, but it would infer that Xfinity is also intentionally or accidentally benefiting from whatever backbone connection they have between them and the default speedtest.net test server for this area.  That could just be my lack of understanding of the limits of the transcontinental backbone so if you have more understanding please hit me up in the comments.

Big Fat File downloading – Real life performance.

For this selected a file out there in the ethers of 1.3Gb and used SABNZBD to download it, noting the throughput displayed in the SABNZBD admin.  Not exactly scientific, but the results don’t really need much precision to show a massive difference in throughput.

Xfinity download started off through the roof then settled down to a steady 6.8Mb/s.   This is exactly the reason that I wanted to try CenturyLink.. who don’t have that throttle.  I waited with bated breath, fingers crossed wanting to see a stead and FASTER Turtle vs Hare performance. In the same test on the same machine, Centurylink clocked in a miserable result of around 1Mb/s give or take 0.2.  That’s aweful.

 

Conclusions.

Well with out a doubt, Xfinity stuff Centurlink in terms of performance at my location, and based on these conclusions, that would still be the case if CenturyLink could connect me at their fastest service.

That means that the only reason to go with Centurylink is if your only concern is the bottom line – but even then –  a call to Xfinity to try to get some deal so you don’t switch is worth a try.

Also interesting, is that even through the speedtest.net numbers and real life download numbers are vastly different, they are at least different by the same ratio.

Now.  How to cancel this damn service.  I simply can’t justify the $38 / month to use CenturyLink as a backup when tethering to my cellular phone is almost as good!  Likewise, I can’t justify keeping it and load balancing it as a second WAN connection through my router because in doing so I would have to specify the ratio to use each, and I think the most likely result will be net slower!

There you go.  It was only a waste of time if nobody ever finds this and finds it useful 😉

Advertisements

Ruby RSS curl trick / partial download beats Conditional GET any day

Posted on Updated on

I’ve been playing with RSS injestion and I gotta say there are some issues.  Life is made MUCH easier by gems like Feedzirra, but all is not perfect in RSS world.

Here are some challenges that I came across:

  1. RSS Feeds can be HUGE. There is no way to get around the fact that if you have time sensitive RSS needs, then simply pulling an RSS feed every minute doesn’t cut it. Even if after you get it make sensible choices based on Feed timestamp and item publish dates, still.. you don’t want to grab 2mb / minute if you don’t have to.
  2. 304s suck.  The idea that you can do a conditional GET on a page, by passing either the last-modfied or etag attribute, and have the server say “304 – nothing new” just doesn’t work very well.  You are absolutely at the mercy of the server you are calling and that’s a problem.  Not sure if it’s just inherently janky, or the issue might be the result of actually hitting different RSS feeds under a load balance, I don’t know.. but it’s a bit hateful.
  3. My first thought after giving up on 304s was to use net/http to just grab the header, and compare things in it with what I found the last time.. Make sense, right?  You have modified-date, etag, content-length to play with, but the sad truth is that these change for reasons you don’t think of.  RSS feeds get updated not just because something has popped in to the top, but also sometimes because it’s a feed covering X hours, and something has dropped off the bottom.  RSS providors also adopt caching strategies.. and their systems dumb as they are, will recreate the same content after 90 seconds, “just because” and from a header perspective, it’s “new”.  Still this was working out for me pretty well.  I went from 4mb / MINUTE injestion across various feeds down to a point where that 4mb was spread over about 5 minutes when I actually got a header match that I trusted. Still.. UGH..  some of these feeds are stale for HOURS over the weekend, but the headers infer that they are working their brains out making me grab a big ass RSS feed every 90 seconds or so just so I can throw it away.
So.. thinking outside the box.. What are we REALLY interested in?  What is the real goal?
  1. Find out if there is a new RSS entry
  2. Do so in a way that is time / resources / bandwidth / cpu efficient.
Well when you put it like that..

$ curl -r 0-2000 http://www.somedomain.com

Say what? EURETHRA! BOOHYA.. etc.
No really.. I know curl has been round the block more than yo mama, but hey once in a while the wonderfully beautiful elegance of Rails can benefit from a bit of ghetto.
So what curl does with -r is simply grab the first 2000 bytes of a page, then call it quits.  How nice is that??  Just curl enough to get the first item title, do something smart with it, and yer done.
We aren’t there yet though.  So I looked at about 12 ruby curl wrappers, and maybe I’m missing something, but I didn’t see support for the myriad of curl parameters, and I needed proxy, user-agent AND this -r wizardry.. so what the hell.. let’s just go ghetto.
So let’s be clear, we don’t really need to get the REAL title.. we just need to do something consistent where if we do it twice in a row and get a different result, then we know there is a new item.
There are many ways you can go with this, but here’s what I do centered around this method:

def get_rss_MD5(url,length)
  data =`curl -r 0-#{length} --connect-timeout 10 --fail  #{url}`
  if data.include? '<item>' and data.include? '</title>'
    return Digest::MD5.hexdigest(data.split('<item>')[1].split('</title>')[0])
  else
    return nil
  end
end

Pass it a url, and a length (that you find is enough to get through the rss headers and get to the first post title + some) and what you get back is an md5 hash of the first item title. It’s probably going to have some junk around it, but that doesn’t matter for our purposes.  Store the result. Next time you hit the RSS feed, if it’s different then you have new content.

It’s soooooooooo fast, so efficient, and so beautifully ghetto.  Sure – it means an extra http request when there is data, but my bandwidth has been cut by 95%!

Looking down the road, there are even more possibilities for optimization.  Right now I’ve added this method to the rails app process that gets fired off by a cron every minute.   I could instead write the “check if it’s changed” logic into a ruby script, or even a bash script so that an actual rake task and all the heavy plodding that goes along with it only happens when I’m sure that there is a new RSS entry.

Good times had by all.