FCC DSTAC for a Downloadable Security schemes

Chat with other TGB members about whatever is on your mind.
glugglug

Posts: 391
Joined: Thu Jun 09, 2011 1:34 am
Location:

HTPC Specs: Show details

#21

Post by glugglug » Tue Aug 11, 2015 2:42 pm

If the 1024QAM implies 10 bits per symbol as the name suggests, that would only be 25% more than 256QAM (8 bits per symbol). although I guess combined with using the 800-1200MHz range would give close to 80% more bandwidth overall. The 2 extra bits per symbol would require 6dB better SNR. Meaning 34dB as an absolute minimum, and realistically at least 36dB to not have tons of macroblocking. I only get 38dB with FiOS, on channels in the center of the tunable range, with the copper only running inside the house, not the entire last mile. With cable now I think 30-32dB SNR is more the norm.

There are going to be several compatibility issues with these things. For one, most of the RF splitters used by cable companies today, including both the outdoor ones and those installed within the house, are designed for the frequency range currently used, and do not have good SNR above 850Mhz. They'd have to all be replaced with the slightly more expensive splitters used for Satellite TV. The equipment itself is cheap, but this means sending out installers to everybody's house.

Also, 1150MHz is currently the most commonly used frequency for MoCA. Yeah, it's outside the range of the splitters. MoCA is more tolerant of that. But if you try to set it higher it will usually fail as you get further outside the pass-through range of them. I guess since they are going to need to install better splitters for the cable anyway, the MoCA can start using the 1300 or 1400Mhz bands. Technically, the MoCA 1.0 and 1.1 devices support up to 1500MHz, and I think 2.0 goes above this, but it doesn't work that high with today's typical cable wiring/splitters.

Last but not least, sending the IP streams through multicast gets "interesting". The multicast will most likely need to be received from the coax directly, not passed through the home LAN. The reason for this is that a lot of current multicast applications are buggy and don't reliably broadcast the listening intent, so the home router must be configured not to do smart multicast routing and instead treat multicast as broadcast for these applications to work properly. First example that comes to mind is Chromecast. The multicast listen to find Chromecast devices is ended when the clients are moved to the background, and most of them don't properly reannounce the listen when moved to the foreground, so if the home router is doing intelligent multicast routing (which would be needed for such a high bandwidth application), the Chromecast apps stop working. I've run into issues where the Broadcom "enterprise" targeted NICs used in HP and Dell servers will cause multicast packets to be seen once for each CPU core in the system if hardware acceleration is enabled. Everyone seems to screw it up -- I expect the cable companies will run into similar issues.

mike_ekim

Posts: 174
Joined: Fri Feb 07, 2014 4:12 pm
Location:

HTPC Specs: Show details

#22

Post by mike_ekim » Thu Aug 13, 2015 8:06 pm

glugglug wrote: Last but not least, sending the IP streams through multicast gets "interesting". The multicast will most likely need to be received from the coax directly, not passed through the home LAN. The reason for this is that a lot of current multicast applications are buggy and don't reliably broadcast the listening intent, so the home router must be configured not to do smart multicast routing and instead treat multicast as broadcast for these applications to work properly. First example that comes to mind is Chromecast. The multicast listen to find Chromecast devices is ended when the clients are moved to the background, and most of them don't properly reannounce the listen when moved to the foreground, so if the home router is doing intelligent multicast routing (which would be needed for such a high bandwidth application), the Chromecast apps stop working. I've run into issues where the Broadcom "enterprise" targeted NICs used in HP and Dell servers will cause multicast packets to be seen once for each CPU core in the system if hardware acceleration is enabled. Everyone seems to screw it up -- I expect the cable companies will run into similar issues.
I expect we will see a few premium routers on the market, with the correct settings configured from the factory and with a "fix my video" button. People will throw away their old LAN hardware and replace everything because they are intimidated by having to type in 192.168.x.xxx in a browser.

mike_ekim

Posts: 174
Joined: Fri Feb 07, 2014 4:12 pm
Location:

HTPC Specs: Show details

#23

Post by mike_ekim » Sun Dec 27, 2015 4:21 am

Comcast deployed its first Docsis 3.1 modem.
http://www.techinsider.io/comcast-activ ... -1-2015-12

Information from other articles suggests that it was basically a software/firmware update on the ISP end, a lot of ISP docsis 3.0 equipment (headend etc) can support 3.1 already so when the bugs get worked out it could be deployed quickly. They will likely expand to a larger local trial in Philly, then a few more cities.

Edit: in August Comcast said their footprint would be docsis 3.1 by 2018.

mike_ekim

Posts: 174
Joined: Fri Feb 07, 2014 4:12 pm
Location:

HTPC Specs: Show details

#24

Post by mike_ekim » Sun Dec 27, 2015 5:34 am

mike_ekim wrote:Comcast deployed its first Docsis 3.1 modem.
http://www.techinsider.io/comcast-activ ... -1-2015-12

Information from other articles suggests that it was basically a software/firmware update on the ISP end, a lot of ISP docsis 3.0 equipment (headend etc) can support 3.1 already so when the bugs get worked out it could be deployed quickly. They will likely expand to a larger local trial in Philly, then a few more cities.

Edit: in August Comcast said their footprint would be docsis 3.1 by 2018.
Clarification: apparently Comcast has deployed 3.1 in some employees homes, this was the first customer deployment.

Post Reply