You are here: Home | Forum | Uddingston upstream 3 channels?
You are currently viewing our boards as a guest which gives you limited access to view most of the discussions, articles and other free features. By joining our Virgin Media community you will have full access to all discussions, be able to view and post threads, communicate privately with other members (PM), respond to polls, upload your own images/photos, and access many other special features. Registration is fast, simple and absolutely free so please join our community today.
it doesn't work like that dude. The modulation directly corresponds to bandwidth and the amount of data that can go over that channel (it is to do with the number of bits per symbol). To keep it nice and simple qam64 provides a 50% increase in bandwidth from qam16 so I think you are roughly looking at going from 20mbits/channel to 30mbits/channel.
If you are using three channels (on qam16) then it is 3x20mbits=60mbits. Using your example, adding the three channel modulations to make qam48 would give you far less than what you currently have access to. What you are missing out on is 3 x qam64 channels which is 3x30mbits/channel=90mbits potential bandwidth.
You haven't got anything to worry about being stuck on qam16, it has been the normal for the last couple of years. In order to achieve the higher modulations your (or VM's network) has got to be a far higher standard and there has got to be less noise. This is why we have seen upstream channels fall back to qpsk in the past; slower connections but more noise tolerant. What some users have already reported seeing is being moved to qam64, but as issues crop up with noise they temporarily fall back to qam16. Things are moving in the right direction and as the shubs re only capable of using 4 bonded upstream channels the way forward for VM is to change the modulation and try and squeeze as much juice out of it as they can.
Doesn't work like what? You answered my question. "Is this indicative of anything?"
__________________
Join Date: Jul 2008
Location: Coventry
Services: FusionFibre/CityFibre (900Mb FTTP; Asus GT-AX11000 +3 iMesh nodes; Humax 2Tb TV box; Synology DS920+ used as Plex server (PlexWindblown)
Doesn't work like what? You answered my question. "Is this indicative of anything?"
lol, look at you trying to pull a fast one. Your original post which was edited before I had chance to reply:
Quote:
Originally Posted by roughbeast
My three channels are 16QAM each = 48QAM. Is this indicative of anything?
Clearly not 64QAM.
I was expecting somebody to pull me up for it and ask me what I was going on about but I didn't expect it to be you So yes I did answer your question quite precisely.
lol, look at you trying to pull a fast one. Your original post which was edited before I had chance to reply:
I was expecting somebody to pull me up for it and ask me what I was going on about but I didn't expect it to be you So yes I did answer your question quite precisely.
Yep, minor edit within 1 minute of me originally posting it. I removed the bit that said 16QAM x 3 = 48QAM. I thought that was stating the obvious and the QAM64 bit because obviously I didn't have 64QAM per channel. Didn't need saying.
__________________
Join Date: Jul 2008
Location: Coventry
Services: FusionFibre/CityFibre (900Mb FTTP; Asus GT-AX11000 +3 iMesh nodes; Humax 2Tb TV box; Synology DS920+ used as Plex server (PlexWindblown)
it isn't stating the obvious because you still sound like you have got yourself in a pickle which is why I tried to explain it for you. 3 x qam16 is not qam48. Read through my explanation again, I probably didn't explain it clearly enough but I can go into more detail if needs be.
---------- Post added at 22:06 ---------- Previous post was at 22:05 ----------
Quote:
Originally Posted by RubberyDuck
Sure...
82.7.217.x
Cheers. Combination of curiosity and checking if it's actually supposed to be 4 upstreams so that you don't hit issues if someone accidentally pushed the button
if the capability is already there to bond 4 upstreams shouldn't VM "hit the button" and do everyone is one go right now? Surely it is a win-win and can only help VM by reducing congestion? (similar to making 8 downstreams available to everyone whether they need them or not). It would definitely give them some breathing room while they sort qam64 out.
if the capability is already there to bond 4 upstreams shouldn't VM "hit the button" and do everyone is one go right now? Surely it is a win-win and can only help VM by reducing congestion? (similar to making 8 downstreams available to everyone whether they need them or not). It would definitely give them some breathing room while they sort qam64 out.
It can break things. It's not as simple as pushing the button.
I'm not entirely sure why they are choosing to upgrade some but not others in the same areas.
If there's no congestion there are zero reasons to potentially cause problems by bonding more channels though.
Yep, minor edit within 1 minute of me originally posting it. I removed the bit that said 16QAM x 3 = 48QAM. I thought that was stating the obvious and the QAM64 bit because obviously I didn't have 64QAM per channel. Didn't need saying.
I am very capable of getting myself in a pickle when it comes to network technicalities. On this occasion I hadn't because I had read earlier posts.
My interest in the details on this occasion are driven by a keen enthusiasm for any signs that the network might be getting upgraded for future speed hikes.
__________________
Join Date: Jul 2008
Location: Coventry
Services: FusionFibre/CityFibre (900Mb FTTP; Asus GT-AX11000 +3 iMesh nodes; Humax 2Tb TV box; Synology DS920+ used as Plex server (PlexWindblown)
Wonder when the 2ac will get the new firmware? Having said that my upstream power has jumped up from 47 to 52dBmv since yesterday, so I'd rather that was sorted first.
Join CF
You are here: 
So yes I did answer your question quite precisely.
