When there's only one

...there's only one choice
Everything here is my personal opinion. I do not speak for my employer.
May 2012
June 2012

2012-05-26 »

Here are some MoCA test results from my experiments at home, with some totally off-topic comments thrown in for extra flavour.

I had heard rumours that MoCA ("Multimedia over Coax Alliance", one of the most terrible names for a standard since 802.11ab) only works on an otherwise "interference free" home coax network: that if you had actual cable TV and/or cablemodem traffic, it would interfere. That's why companies like FiOS (which delivers its data over Fiber, not cable) provide MoCA; because those now-idle coax cables in your home can be put to good use.

Anyway, the rumours are wrong. I have digital cable TV (as of Thursday) and DOCSIS 3 cable modem, and now MoCA (as of Friday) and it all works together on the same wires. Here's a FAQ: http://mocablog.net/faq/ . The key observation is that MoCA uses a frequency range around 850-1550 MHz, while cable TV comes in under 850. (The FAQ tells us that satellite TV does use those higher frequencies, so MoCA isn't compatible with a satellite signal. I have no way of testing this but it makes sense.) While I was researching, I read up on DOCSIS 3, which of course is an extension of the earlier DOCSIS (cable modem) standards. The only big change it makes is it allows "bonding" of multiple upstream/downstream channels to increase your transfer rates.

This, in turn, gives me a clue about how DOCSIS works: it literally takes over unused TV channels and uses them for data. Kind of neat. And knowing that, we can also conclude that DOCSIS comes in under 850 MHz as well, so it also doesn't conflict with MoCA.

These theoretical results bear out in practice. With my system fully connected (cable -> cablemodem -> linksys -> 100Mbit ethernet -> MoCA master -> MoCA slave -> laptop, speedtest.net measures 48MBit/sec downstream and 5.6MBit/sec upstream, which is comfortably close to what I'm paying for, 50MBit/sec down and 6MBit/sec up. During that test (which, note, is using the same cable to transmit MoCA and DOCSIS), the TV keeps on coming, glitch-free.

A quick one-stream TCP iperf test between the two MoCA devices gives 60 MBits/sec, which is less than I get when the two are isolated on their own network with just a short coax cable between them, but still more than Wifi, which is the important thing. There's also next-to-no packet loss, which is much better than Wifi.

Speaking of packet loss, my experiments with an HDHomerun Prime (cable TV to IPTV converter) box, and separately/together with some slightly-hacked-up DVR software have been quite informative. The HDHomerun device is very classy: zero configuration (there's a web interface but it has no settings). You just plug in a cable to one side and ethernet on the other side, and there's a really simple control protocol along with some sample software. The software just uses the simple control protocol to ask it to tune to a particular channel and beam the packets - it's already a digital video stream, after all - to a given unicast or multicast UDP address:port. Programs like VLC then know how to receive UDP video streams and display them. And that's that.

What's informative, though, is noticing what happens in case of packet loss in such a stream. UDP doesn't guarantee delivery of any particular data: if it gets dropped, it gets dropped. This is nice for something like a digital cable converter, because it can work with basically zero buffering: no retries mean no buffer required. Just fire-and-forget the packets as fast as you can. On a typical non-overloaded ethernet or MoCA network, there will be virtually no packet loss, so you get a clean video stream with the minimum possible latency. Sweet.

However, Wifi networks pretty much always have packet loss. Certainly mine does. And when it does, you inevitably lose part of the video stream; this manifests as those weird digital noise blocks like you see on cable TV occasionally, and satellite TV even more often. Depending on your tolerance and Wifi network quality, the lossage ranges from "mostly okay" to "unwatchable." Plugging your VLC viewer into a wired network with the HDHomerun eliminates the loss and gives you nice, high-quality, low-latency video.

DVRs are different. They can tune into an HDHomerun stream, but they record shows and beam them back to your viewer, with features like "pause live video" and fast forward/rewind. Such a design is inherently buffering, and unlike HDHomerun, works fine on lossy connections. A quick tcpdump reveals why: because they use TCP, not UDP, so they can recover from packet loss. The tradeoff is that buffers mean you end up with added latency. Running in a cabled setup and yanking the cable gives us a clue about exactly how much latency, for the particular viewer software I was testing: about 2-3 seconds. For TV, nobody cares (and it can blast-fill that 3 seconds of video buffer on your client on a LAN in much less than 3 seconds, if your programmers aren't idiots) so this is a great tradeoff.

The next layer of cool is that you can combine the two: if you put a wire between your DVR server and your HDHomerun, then you can watch live TV on your laptop over Wifi, glitch-free. Your DVR server is essentially a very expensive buffer.

(TIP: You can tell the difference between TCP and UDP video on lossy networks just by looking. UDP video gets glitchy - the telltale garbage blocks in the middle of a frame - and in the worst case, drops out, and when it comes back you've missed something. TCP should never get glitchy (unless the upstream signal was glitchy, like if there's a satellite uplink involved); it just freezes, rebuffers and eventually resumes where it left off. For this reason, if you're writing real-time video chat software, you should not be using TCP. With two-way conversation, you'd rather have a glitch than a delay. But if you're doing a presentation you probably want TCP. Are we clear yet? Good.)
Speaking of wires, out of curiosity I did some tests of MoCA sync time (the time it takes a newly-booted MoCA device to connect to the other). MoCA, by the way, although it appears like an ethernet device to the OS, has more in common with old 56k modems than with ethernet. That's because it involves tons of complicated signal processing: it needs to work over wires that were never intended for data transfer, so it has to do frequency analysis to figure out which frequency ranges work, and which ones are doomed. So, like a 56k modem, it takes a few seconds to do its magic before data can get flowing. In my tests, I found that the baseline connection time on the simplest possible network - a short bit of coax from one device to the other - takes about 3.9 seconds. On my now-much-more-crowded network involving three layers of radio shack splitters, a TV receiver, and a DOCSIS modem, the same MoCA devices now take a little over 10 seconds to connect. And they drop out and come back whenever the topology changes in any way (including, for example, unplugging/replugging my receive-only HDHomerun device). This is probably because it changes the resistance/capacitance/reflectivity of the line, which means it has to redo the 10-second characterization step. It comes back shortly, though, and as the doctor says, "Don't do that then." More importantly, if you aren't messing with the topology, MoCA stays reliably connected and has super-low packet loss.

And speaking of radio shack splitters, those were the fiddliest part of the whole mess. I tried a few different things, and certain splitter configurations cause various devices to fail completely to connect. In theory, my expensive Electrical Engineering education should help me explain this, but as usual, it's a failure, offering simply that it will never work because, "Um, hello, improper line termination, duh." I am so going to fail this exam.

What I can tell you empirically is that there's definitely a difference between radio shack splitters of the form "in, out (-3.5dB), out (-3.5dB)" and "in, out (0dB), out (-5.7dB)". I'm quite sure this has something to do with the aforementioned line termination, though I'm too lazy to calculate what. My general inkling is that when splitting a signal cable, there's no free lunch: you can't just send the same signal to two guys and have them both get the full signal strength. You can either divide it by two (in other words, -3.5dB) or distribute it unfairly (full strength and much-lower strength, ie. -5.7dB). I found that connecting MoCA devices with a -5.7dB between them killed the connection; putting -3.5dB between them was acceptable. (My DOCSIS signal has obviously been around the block a few times - er, literally - and was unoffended by being on the -5.7dB port. It still gets full speed and no loss.) Furthermore, on splitters there's some kind of difference between "in" and "out", which are romantic historical terms that made sense when TV was one-way, but which make no sense whatsoever in a world of two-way MoCA and DOCSIS. My expensive education does add something here, because I can understand the cute little diagrams on the splitters that indicate diodes between in and out, with a comment "DC pass-through" on some but not others. I also know that diodes are more complicated than you think, given that they have different response characteristics between DC and high-frequency current. It doesn't just mean "all the electrons go only one way" like it sounds.

Anyway, the short version of my experience with splitters, in short, is "splitters are the problem." This makes MoCA fiddly and error-prone. For example, a five-port gold-plated radio shack splitter didn't work for MoCA; combining it in serial with a three-port -3.5dB splitter (so there was less total loss between the two MoCA devices) did work. On the other hand, as an experiment, putting the HDHomerun on the "in" port and the outside cable line on the "out" port really did block the cable signal from reaching the HDHomerun, so yeah, diodes.

Probably people like FiOS installers have been trained in which kind of splitters to put where, and have a truckload full of them, instead of having to buy overpriced ones from Radio Shack at the last minute.

Epilogue

Oh also, don't bother with ethernet-over-powerline products. I got the DLink DHP-300's a while ago. They are junk. MoCA is way better. Use that instead. (In fairness, at least coax cable was intended to carry a signal, while powerlines never were. But it shows.)

Why would you follow me on twitter? Use RSS.
apenwarr-on-gmail.com