| [INTERNET] When Can We Expect Cogeco to Increase Upload Bandwidt If I recall correctly, I had 1 Meg upload with Cogeco in early 2000's. Surely they have had time since then to work on their infrastructure, to facilitate this. Even Bell (and I hate Bell) is offering better uploads, if your in the right area and close enough to the DSLAM.
I shoot videos and upload to Vimeo and You Tube all the time.
Canadian ISP really need to get their act together, in my opinion anyway!!! |
|
| Re: [INTERNET] When Can We Expect Cogeco to Increase Upload Band Yes, I would certainly agree. This is one of the major where Cogeco (and and I suppose all the broadband cable providers) must work on improving. A measly 2 Mbit uplink just doesn't cut it today. |
|
|
|
| reply to Reno_William
I am wondering this as well, and agree 100%.
I have a 2 Mbit upload speed as well. However, when I connect to a VPN, I get 10 Mbit/s speed. I'm not sure why this is, but now I always use a VPN when I upload.
Anybody know when they will upgrade the speeds, or why a VPN allows for faster uploads? |
|
| reply to Reno_William
Answer: When ever Cogeco decides to invest in infrastructure and not foreign ISP's in portugal that lose money.
It would be a huge overhaul and huge investment, it's not just a simple switch to turn on. Generally Cogeco would start in Burlington with this and move outwards.
If you want higher uploads have to go with Teksavvy on the Bhell network. Simple as that. |
|
1 edit | I understand that it doesn't just happen overnight, but they've had over 10 years as I said.
Also, as you point out, other isps are offering more, in the same market. They face the same challenges to upgrade their infrastructure. So, is it poor forward thinking, or just greed. When I first had Cogeco's service it was the mid nineties, and you had unlimited bandwidth usage without usage caps. The argument for setting caps was congestion on the network. So now they have more revenue stream as a result.
Anyway, Hopefully we will see tiers in the no too distant future, of 5 or 10 meg upload speeds. |
|
 GonePremium
join:2011-01-24
Fort Erie, ON
kudos:4
 ·Start Communicat..
| reply to Reno_William
Cogeco is already running four 64QAM return channels across a whole bunch of their nodes and many more are running three. The huge overhaul and huge investment has already been done and has been done for a while. Higher upload speeds are probably closer than one would think.
The convenient thing Cogeco has to fall back on as far as competition goes is that most of their footprint does not have access to the higher speed Bell tiers beyond 5M/800k. That will change in the next 1-2 years as Bell completes the rollout of their FTTN network and more and more greenfields are being lit up with GPON from the get-go. Cogeco has no choice but to respond.
They're now also running eight forward channels in most areas, so higher download speeds will probably go along with it. |
|
| If they do have 4 64 qam return channels than it would be for docsis 3 compliance and not much else.
Remember docsis 2 was fully capable of having much higher upload speeds and download speeds but cogeco has some weird provisioning policies. So they never even got close to what docsis 2.0 was capable of, and to add to that it's not all Internet channels.
Cox cable just did a 356Mbps upload on a 5 - 85MHz return path, which is pretty sweet, but will people see that kind of speed at a home user level anytime soon? I doubt it. |
|
GonePremium
join:2011-01-24
Fort Erie, ON
kudos:4 Reviews:
·Start Communicat..
| said by Uploader :If they do have 4 64 qam return channels than it would be for docsis 3 compliance and not much else. Um, DOCSIS 3 is more than "compliant" with just one single QPSK or 16QAM return channel, let alone anything 64QAM.
The only reason any provider would implement multiple 64QAM return channels would be to increase return path bandwidth on a node. That increased can be used to facilitate higher upload speeds. That is a fact. Whether Cogeco decides to do it is their decision.
Any claims contrary to this has no basis in fact.
Also - DOCSIS 2, while adding support 64QAM modulation for the return path, did not support any level of bonding what so ever. It was all single channel. You could *not* do a subscriber 10Mbit/s upload profile on a DOCSIS 2 node and expect any sort of realistic outcome. |
|
| said by Gone:The only reason any provider would implement multiple 64QAM return channels would be to increase return path bandwidth on a node.
Not true, as DOCSIS 2.0 also specifies 6.4 MHz, but can use the earlier, narrower channel widths for backward compatibility.Where 3.0 can not. So unless Cogeco plans on forcing everyone to Docsis 3 then it will not matter.
On the Data Link layer they would need the extra channels for S-CDMA for spectral efficiency. |
|
GonePremium
join:2011-01-24
Fort Erie, ON
kudos:4 Reviews:
·Start Communicat..
| said by Uploader :Not true, as DOCSIS 2.0 also specifies 6.4 MHz, but can use the earlier, narrower channel widths for backward compatibility.Where 3.0 can not. So unless Cogeco plans on forcing everyone to Docsis 3 then it will not matter. DOCSIS 3.0 can still use - and bond - narrow 3.2MHz channels. So you're wrong.
Bonded 64QAM return channels provide additional return bandwidth on a node. The only reason a provider would do this is to either provide additional upstream bandwidth to customers, or to delay node splits. They are not "required" for DOCSIS 3 compatibility, as DOCSIS 3 will even work with a single 3.2MHz 16QAM or QPSK DOCSIS 1-compatible return channel. These are the facts. Whether you chose to believe them or not is your choice. |
|
| said by Gone:DOCSIS 3.0 can still use - and bond - narrow 3.2MHz channels. So you're wrong.
You're only talking about the physical layer and ignoring the data link layer. So you're wrong. As you are only understanding half of the technology. |
|
GonePremium
join:2011-01-24
Fort Erie, ON
kudos:4 | There is no requirement that DOCSIS 3 use S-CDMA, so I'm understanding this better than you think I am. And you're still wrong. |
|
| said by Gone:There is no requirement that DOCSIS 3 use S-CDMA, so I'm understanding this better than you think I am. And you're still wrong.
There is no requirement that qam channels indicates what user end upload will actually be either. So you're wrong. |
|
| Yes it does, because the capacity of your upstream depends on the modulation you are running and channel width, you cannot offer a 10meg upload package on a 3.2MHz QPSK channel because there is not that much capacity in the pipe to begin with!
And a lot of the 2.0 cable modems are not able to reach those speeds due to hardware, so its not all the ISP doing.
Docsis 3 and channel bonding changed everything. |
|
MarcerPremium,VIP
join:2007-07-08
Hamilton, ON
kudos:12
1 edit | reply to Uploader
»www.cablelabs.com/specifications···1117.pdf
quote:
6.2.3 Modulation Formats (Page 27)
The upstream modulator MUST provide QPSK, 8-QAM, 16-QAM, 32-QAM, and 64-QAM modulations for TDMA
and S-CDMA channels.
quote:
6.2.11.1 DOCSIS 3.0 Modulation Rates (Page 38)
In TDMA and S-CDMA modes, the CM upstream modulator MUST provide all modulations at 1280, 2560, and
5120 kHz.
Now the upstream modulator implements a Root-Raised Cosine Filter @ 25%, meaning that given a modulation bandwidth and the filter width one can calculate the total channel width.
I.E. 2560kHz * (1 + filter = 1 + 0.25 = 1.25) = 3200 kHz I.E. a 3.2 Mhz Channel
So... Per the cable Lab's Physical Layer Specification for DOCSIS 3.0, regardless of modulation mode (in which you'll note S-CDMA is not an exclusive requirement), upstream modulators (I.E. Modem Hardware) MUST support 1.6, 3.2 and 6.4Mhz upstream channels, at QPSK through to 64-QAM bit rates per symbol.
P.S. Modulation type is a Physical Layer specification, Data Link Layer (MAC layer in DOCSIS) has to do with addressing and control. |
|
| said by Marcer:P.S. Modulation type is a Physical Layer specification, Data Link Layer (MAC layer in DOCSIS) has to do with addressing and control.
The Data Link Layer is NOT the mac layer. Also per IP speed/upload is limited by request grant latency. That typically limits upload speed to 1-3 mbps.
If you want to understand, read this:
»www.cisco.com/en/US/tech/tk86/tk···45.shtml |
|
GonePremium
join:2011-01-24
Fort Erie, ON
kudos:4
1 recommendation | Uhhh, I think everyone here can say with confidence that Marcer understands this far more than you could ever hope to. |
|
| said by Gone:Uhhh, I think everyone here can say with confidence that Marcer understands this far more than you could ever hope to.
Just because someone is a Cogeco "Technician" dosen't mean they know everything. They are never told or know what engineers/developers are doing. There is a whole other world above them.
There is MUCH more to Docsis technology than just the physical layer. If you don't want to understand, that's ok. |
|
GonePremium
join:2011-01-24
Fort Erie, ON
kudos:4 | Aside from the fact that you clearly don't know what Marcer actually does at Cogeco, he has demonstrated more practical knowledge about the DOCSIS specification here than you have. |
|
MarcerPremium,VIP
join:2007-07-08
Hamilton, ON
kudos:12 | reply to uploader
said by uploader :said by Marcer:P.S. Modulation type is a Physical Layer specification, Data Link Layer (MAC layer in DOCSIS) has to do with addressing and control.
The Data Link Layer is NOT the mac layer. Also per IP speed/upload is limited by request grant latency. That typically limits upload speed to 1-3 mbps. If you want to understand, read this: » www.cisco.com/en/US/tech/tk86/tk···45.shtml 1. The "Data Link" layer exists within the OSI model, which is a theoretical model used to break down a protocol or system of protocols to comparable layers. 2a. The DOCSIS 3.0 specifications published by Cable labs Include The Physical Layer (linked to in above post) and the
"MAC and Upper Layer Protocols Interface Specification" which includes all "data link" layer details with regards to addressing and flow control. 2b. As you appear to prefer Cisco Documentation over Cable Labs, they happen to have an illustration that might clarify our positions better: »docwiki.cisco.com/wiki/File:CT842204.jpg
(from »docwiki.cisco.com/wiki/Cable_Acc···l_Layers so the context of the image is not lost)
You will clearly see "DOCSIS MAC" located to the right of "Data Link" 3. "IP" is Network layer, request grants are "Data Link" layer. While I realize the Network layer's Packets are encapsulated within the Data Link layer's frames... it's easier to stick to the same layer and "compare apples to apples". 4. The Cisco Document you provide regarding DOCSIS speeds was published nearly 5 years ago, and makes not one reference to DOCSIS 3.0. It does however note in the Results section under the heading of "Single Modem Speeds" that quote:
"27.2 Mbps at 98 percent US utilization was achieved with the Motorola and Ambit CMs."
which would indicate no limit of the upload speed at 1-3 Mbps. 5. With regard to the specific concern of request grant latency, this only impacts best effort traffic; high priority traffic is scheduled through the "UGS" (Unsolicited Grant Service). Grant Piggybacking and Frame Concatenation also improve best effort traffic throughput in the context of request grant latency by reducing the latency, and improving the per-request throughput respectively. |
|
| I'll just correct the major errors with your posts:
said by marcer said :1.
The "Data Link" layer exists within the OSI model, which is a theoretical model used to break down a protocol or system of protocols to comparable layers.
The Data Link Layer is layer 2 in the osi model which every Computer science student learns first year. The mac layer is one of MANY sub layers and protocols. So saying the mac layer is the Data Link Layer is incorrect.
said by marcer said :5.
With regard to the specific concern of request grant latency, this only impacts best effort traffic; high priority traffic is scheduled through the "UGS" (Unsolicited Grant Service). Grant Piggybacking and Frame Concatenation also improve best effort traffic throughput in the context of request grant latency by reducing the latency, and improving the per-request throughput respectively.
You are confusing QOS services with request protocols.
Moving on:
Docisis 3.0 supports QAM128 for upstream, while D2 supports only QAM64.
Docsis 3 specs use 108 mhz to 1.002GHZ downstream,5mhz to 85mhz upstream
Docsis2.0 specs use 88mhz to 860Mhz downstream, 5mhz to 42mhz upstream.
Cogeco would use D3 binding to pack more clients into a node, not to increase upstream.
So when I say if you see multiple QAM channels, it dosen't directly relate to Cogeco increasing upload as there are many reasons.
There are many more misunderstandings to point out but I don't have the patience or time to bother. There is a lot more to this than the physical channels MUCH more, hopefully you understand at least that.
So it all comes around to this Marcer, why hasn't cogeco increased the provisioned upload rate? One year from now, will your answer still be the same? |
|
GonePremium
join:2011-01-24
Fort Erie, ON
kudos:4 Reviews:
·Start Communicat..
1 edit | said by uploader :Docisis 3.0 supports QAM128 for upstream, while D2 supports only QAM64. What the copy and paste from Speedtest.net didn't tell you (»www.speedguide.net/faq_in_q.php?qid=390, nice copy and paste job by the way) is that QAM128 is only supported in S-CDMA mode, which has the same effective bandwidth as 64QAM in TDMA or ATDMA mode.
A QAM128 S-CDMA return channel is more spectrally efficient, while sacrificing wiggle room as far as power levels and plant noise goes.
Edit - DOCSIS 2.0 also supports QAM128 for return channels, so even your copy-and-paste job was incorrect. |
|
| reply to Reno_William
lol.....now if we could just get more upload. |
|
| reply to Reno_William
lol.....now if we could just get more upload. |
|
| said by Reno_William:lol.....now if we could just get more upload.
Well according to the forum "experts" it's just as simple as a flick of the switch, because of 4 qam channels...lol
We can come back a year from now and see who was right. When we still have 1-3 mbps upload. I am sure gone will apologize to me, that happens all the time when someone is wrong on the internet, right?  |
|
| reply to Gone
Nothin wrong with checking specs on google, professionals do it all the time. In fact it would help to have more reference and less "interpretation".One last correction as I think I am just being trolled with so many wrong statements:
said by Gone said :is that QAM128 is only supported in S-CDMA mode
Incorrect.
Upstream data (data from cable modems to the headend or Internet) is carried in Ethernet frames encapsulated inside DOCSIS frames modulated with QPSK, 16-QAM, 32-QAM, 64-QAM or 128-QAM using TDMA, ATDMA or S-CDMA frequency sharing mechanisms.
Link: »en.wikipedia.org/wiki/Cable_mode···n_system
also
»www.cisco.com/en/US/prod/collate···per.html |
|
 your moderator at work
 hidden : Other reason
|
GonePremium
join:2011-01-24
Fort Erie, ON
kudos:4 Reviews:
·Start Communicat..
| reply to uploader
Re: [INTERNET] When Can We Expect Cogeco to Increase Upload Band You're - again - wrong. The table above was taken from your Cisco link and clearly shows 128QAM (with TCM) is only supported on S-CDMA. The following text was also right from those documents. Perhaps you should read you're own links, eh?
said by www.cisco.com/en/US/prod/collate···per.html :
DOCSIS 2.0 brought the cable industry higher upstream per-channel data throughput, increasing the maximum to as much as 30.72 Mbps. DOCSIS 2.0 supports 64-QAM in the upstream - plus 8-QAM and 32-QAM - and optionally supports 128-QAM trellis coded modulation (TCM) encoded modulations for synchronous code division multiple access (S-CDMA) channels.
said by www.cisco.com/en/US/prod/collate···per.html :
• S-CDMA (optionally) offers support for 128-QAM with TCM; however, the maximum data throughput remains the same as for 64-QAM.
|
|
|
your moderator at work
hidden :
|
Reviews:
 ·Cogeco Cable
·Bell Sympatico
·Cooptel
| reply to Reno_William
Re: [INTERNET] When Can We Expect Cogeco to Increase Upload Band When does docsis 3.1 is coming ? Should that be able to handle symetrical connexion or at least a 0.75 up : 1 down ratio ? Does cogeco is thinking using docsis 3.1 when available ?
The funny thing about that is that my area is actually only at docsis 2.0 lol
Max |
|
