FDX/Unified DOCSIS

fmd · 2025-02-13T20:05:09+00:00

While we wait for the announcement that N+X deployment has officially begun... Unified is the new version of FDX that has downstream going all the way to 1.8 GHz (currently limited by old taps). The return still stops at 684 MHz. Comcast has presented this spectrum layout to begin with: This is sufficient to offer symmetrical 2 Gbps. When more of the legacy channels go away, higher speeds can be offered. 3.1 modems that get FDX-L (limited) firmware can use the FDX channels.

videomatic3

fmd i dunno i bought it a long time ago, is it no longer necessary?
theres also no access to logs so i have no way of knowing

fmd

videomatic3 Do you have an internal MoCA network that is connected through a splitter to the outside world? Otherwise no.

videomatic3

fmd
it was more so there to protect myself from other people that could potentially back feed into me, maybe the isolation on newer taps work better.
removed the moca filter and there it is!
thank you
i wonder if the xb8 would have seen this channel too?
will post speedtest when i can finally find a server that can do both directions maxing out. giving up, heres one maxing out the download, already sent one of the upload earlier.
now that i look at it more closely it the same channel that didnt lock on before, that aint a 108mhz, its 1086mhz

fmd

videomatic3 I just realize that your orginal post was showing this with snr 0. It wasn’t a low frequency OFDM. 🙂

fmd

videomatic3 i wonder if the xb8 would have seen this channel too?

It has built-in MoCA protection when set to mid-split operation, so it will not even try (not part of the bonding group for this modem)

hex0101

videomatic3 I was told MoCA is not available on the XB10 (MoCA sunset). MoCA runs from 1150-1675 Mhz and would interfere with the DOCSIS that is capable of running up to 1.8 Ghz on the XB10. Presents issues for Comcast when they decide to use 1.2 Ghz FDX in the future and MoCA is interfering at 1150 Mhz. Could be wrong though. @fmd may be correct and that it is a firmware bug currently.

Supposed to also be a direct run from the drop/ground block to the XB10 without any splitters or MoCa filters as well to ensure signal integrity for FDX.

TV customers will have all of their boxes swapped to Xi6’s by the technician during the FDX installation.

fmd

hex0101 may be correct and that it is a firmware bug currently.

I saw it mentioned here: https://code.rdkcentral.com/r/c/rdk/components/generic/rdk-oe/meta-rdk-ext/+/109232

videomatic3

the comcast server finally gave me good results. now i need a computer with 10gbit just to try it out…
and the 10gbit nic made virtually no difference.

hex0101

videomatic3

videomatic3 maybe this is what you meant by moca?

Yep.

videomatic3 youtube uploads seem to remain around a disappointing 200-300mbps

On a 1 Gbps Frontier Fiber XGS-PON connection, I was only seeing 300-400 Mbps sustained when uploading to YouTube as well. It may be a YouTube limitation. Lon. TV said he got 600-700 at times when uploading from his Gigabit X10 connection. I think it just depends on how busy the YouTube servers are at the time of upload (amount of users uploading video around the world at the same time). Not sure if YouTube CDN’s are used for uploads or not. Google Drive also topped out at 250-300 Mbps.

ViRGE

hex0101 IMO, if you’re looking to max out your upload speeds, then the current web tests aren’t very well suited for that. They tend to stop a bit too soon, and are on networks optimized for (what is to them) outbound transfers.

Instead, I’d recommend running iperf3 against some of the big public servers. LeaseWeb appears to have very good peering with Comcast, for example.

iperf3.exe -c speedtest.sfo12.us.leaseweb.net -p 5201 -t 30 will get you the SFO LeaseWeb server and run an upload test for 30 seconds.

cypherstream

Your second big OFDMA was centered around 1086 MHz - or at least that’s where the main subcarrier is located. Moca filter starts to really drop off around 1030ish MHz and it’s a sharp cliff around f 1050 MHz. The modem was aware but the channel was deleted hence the -38.5 signal level.

These filters are being installed today on new installs when the’ll just have to be removed for FDX. They enjoy creating more work for themselves.

This is history though. Put it through its paces and give us the full review after using it for a few days.

Any change in peering or lower pings? Does it do low latency docsis L4S/LLD?

videomatic3

cypherstream
peering is unchanged latency is unchanged, if anything the l4s/lld seems worse, a couple speed tests i ran the upload made local pings triple digit, so as far as that goes im not impressed.
download was only fine here because it didnt peg the download completely.

i ran the bufferbloat test from whatever website thats from, but it wasnt able to peg the upload and download, it ran about 1700mbps in both directions, so it gave me an A

videomatic3

cypherstream
heres a day graph from samknows

hex0101

videomatic3 I think it was this one, which Jason shared on Reddit: https://test.libreqos.com
In beta currently but seems to work well.

fmd

videomatic3 Is your router still configured to DSCP mark ICMP packets (we talked a little bit about that on the old site)? I still get the distinct feeling that something goes wrong in that setup, because the packets seem to be hit by the same upstream queueing delay as the “classic” packets.

videomatic3

hex0101
i could see how this one is probably a great test for slower connections, it hardly even stressed this.

HardlyWorthit

videomatic3
Here is another:
https://www.waveform.com/tools/bufferbloat

videomatic3

i was noticing some single digit pings to 8.8.8.8 so i ran a trace. this is while utilizing _600mbit upload
and i do remember reading that latency will be better under load vs idle on docsis 3.1

cypherstream

videomatic3 some of those traceroute responses are very similar to Comcast Metro Ethernet.

How the latency spikes when under load though needs a little work. Some QoS or limiters maybe. The A+ / A’s are good grades though. Guess in most situations you wouldn’t max it out anyway, so others on the network shouldn’t feel any effects.

az8831

videomatic3 These are some pretty decent first hop latency numbers compared to what mine were. I typically had 10-15ms versus your 5-7.

videomatic3

HardlyWorthit https://www.waveform.com/tools/bufferbloat

yea this one only did 1.7gbps on both directions on my first try, maybe it was just the time of day
the results are terrible

videomatic3

ViRGE

videomatic3

fmd yes it is, the rule is icmp change packet to dscp 45 post routing out interface wan interface, just like how jl told us to change packets to 45 for dns on a windows machine. I’ll give the iperf and bufferbloat test a try later
the counter counts up as the pings go through so i can only assume its working.
disabling the rule and re enabling the rule while running the iperf test makes no difference on latency, so its also safe to assume it does nothing as far as the dual queue.

Test-User

fmd That’s quite interesting! Could you elaborate, or point me in the direction of the info on this? Also, are you saying that an XB8 in a mid-split area, does not require a MoCA filter at the point in which it connects inside the Xfinity box on the side of the home, or alternately at the connection point in to the XB8? Perhaps I’m misunderstanding, but I’d definitely like to learn more about it, if that’s the case. I had heard that the XB10 running X-Class plans above 500 Mbps needed the MoCA filter removed in order to function properly, but that’s all. And almost no one is talking about that, even. Much appreciated!

fmd

videomatic3 If you change action to set TTL instead (set it to 1), does that give the expected result?

« Previous Page Next Page »