Thanks, Scott, that's what I was looking for. I still have a few questions, though because the ratios don't seem balanced with the capacity.
I get 60KB/s up now. I saturate my 10 ethernet card on download at about 300KB/s. That's a five fold difference, but the ratio of raw bandwith is more like three, 27::10. Before they got so generous, it was a whole order of magnitude different. Before Cox my upload seemed only limited by my ethernet card. What did they change that required them to have to work hard to bring things up to 60kB/s? The average person does very little uploading compared to their download. Why not limit the upload to a more reasonable expectation of an actual user's demand? It's pointless to limit my uploading by reserving bandwith for people who never use it. Also, it's strange that the channels are not bidirectional. With all manner of devices transmitting and receiving at much higher bandwith on wifi and other $40 networking cards, you would think that bidirectional 6 MHz communications would be easy. I'll take your word for it that is how things are, but I don't have to like it. Here's a cheer for Eatel and competition. I hope neither is thwarted. On Monday 27 September 2004 08:11 am, Scott Harney wrote: > 60KBps = 480kbps . Still a bit off from 512kbps but round trip > latencies and various other potential limiters come into play. Traffic > shaping and possible MTU changes may get you a bit closer though I'd > think you'd never exceed 500kbps (62KBps) on any consistent basis due to > overhead. > > Look into wondershaper (http://lartc.org/wondershaper/ ) if your router > is a linux box. Many of the linux router distributions (smoothwall, > shorewall) incorporate wondershaper. Some of the netgear/linksys > consumer broadband routers out now support limited traffic shaping > abilities as well. Primarily those boxes prioritize VoIP over other > traffic and don't do the kind of real, granular IP traffic shaping that > would best benefit you. > > > I'm not gonna argue with you what may have changed in the past few > years. I'd say a great many things have changed, but the upstream > path's inherent limitation is the primary engineering problem for cable > connectivity and always has been. The math involved is well understood. > > Customers on a single downstream connection in the US share a 6Mhz band > and I'm going to surmise that Cox has gone to 256QAM modulation giving a > raw throughput rate of 27Mbps on a single downstream. On the upstream > side, the widest available channel width is 3.2Mhz and the most > efficient available modulation scheme is 16QAM in DOCSIS 1.0/1.1 > yielding 10.24Mbps raw to share amongst customers on a single upstream > path.(1) DOCSIS signalling and TCP/IP overhead further erode the > available bandwidth. Other factors as well will limit available > bandwidth, typically on the upstream side of the equation. > > Getting to those maximum widths and modulations schemes for cable > vendors is recent as much work had to be done to get the plant to > support that without major issues. (2) A lot of companies out there are > still at 64QAM on the downstream and 1.6Mhz width and QPSK on the > upstream. Cox had to do a significant amount of work and buildup to > support a 512kbps upstream; I talked to a couple of engineers at Cox > about this, actually. > > The biggest improvement DOCSIS 2.0 will offer if it ever gets deployed > is changes in modulation schemes on the upstream, changes in contention > rules on the upstream, changes in resiliency for operating in a "noisy" > RF environments, and great QoS enhancements for supporting > bandwidth-intensive "real time" apps like VoIP. It's all geared towards > increasing the upstream available bandwidth. > > (1)http://www.cisco.com/warp/public/cc/so/cuso/sp/hfcn_wp.pdf page 67, > appendix table. This doc is not an easy read. > http://www.cisco.com/en/US/tech/tk86/tk168/technologies_tech_note09186a0080 >094545.shtml "Understanding Data Throughput in a DOCSIS world" is a better > read mostly for providers but there is some info on customer changes in > PC's and OS that can improve throughput. > http://www.cisco.com/en/US/tech/tk86/tk804/technologies_tech_note09186a0080 >0a9702.shtml is a more "read friendly" document and though a little long in > the tooth in some respects it gives a good overview of how they're making > decisions. www.broadbandreports.com - the goldmine for users for > information on this stuff. > > (2)Did Cox in BR do a good enough job cleaning up the plant, > reengineering, etc is a very subjective question, of course.
