Will Hill wrote: > 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.
Well you'd only get 27::10 if (a) you weren't capped and (b) no one else was sharing your segment and/or attempting to transmit. Those papers I linked to go into a lot of detail on how to make decisions (as a provider) on how many customers should be on a given upstream and optimal (from the providers PoV) bandwidth caps. I've seen some industry articles on traffic engineering to reduce throughput for, say, P2P filesharing apps while reserving capacity for 80,25, VoIP, etc but nobody is doing that on anything more than a local/test scale as far as I know. You should be getting more on the downstream than you list here, though. Not sure where/how you're testing but there are a lot of possibilities. I'd try some of the speedtests on broadbandreports. And you will get a significant benefit from traffic shaping. > 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? Two different issues. I can't speak to the first one as to why it seemed that way for you on @home at that time. To engineer for modulation changes they had to do a number of things: increase number of ports/terminations, subdivide nodes (basically where customers share connection), possible re-arranging RF/fiber combining, make sure noise and other RF impairments were fixed, and a bunch more. > 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. unfortunately, that's really not a true assumption anymore. Lots of people are using more upload than before. It's been a couple of years since I last did the traffic analysis and it was growing rapidly then, far outpacing the assumptions corporate engineering managers were using. That predates consumer VoIP on any significant scale, to name just one example. And it's not just raw capacity that's smaller, its also some of the necessities of DOCSIS design for upstream. Contention is a big problem. In other words, without rate-limiting it would be fairly easy for one user's upload traffic to saturate and entire shared upstream port even if they weren't transmitting at 10Mbps. So upload is the scarce resource in the equation. .5mbps isn't too bad for me and I do use it alot (VoIP, streaming music, constant ssh traffic) Of course I'd like more.... > 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. A few issues in play here. One is the FCC and licensed spectrum and transmission rules. The available upstream spectrum slice is small, riding in a relatively "dirty" area of the RF spectrum (below 50Mhz with the "sweet spot" for modems usually between 25-40Mhz depending on the plant and local conditions) Thus the available channel widths are smaller as well, hence the choices of 1.6 or 3.2Mhz widths. Making a modem that can transmit greater than 50Mhz would be hard to shield and thus leak into licensed spectrum. Since Analog CATV channels start at ~54Mhz they'd have to change that too(1). 900Mhz and 2Ghz unlicensed areas are probably too dirty to be usable; I don't think they can shield out the noise. And the entire existing plant from headend to your house is designed to block anything above 860Mhz(2); most of your off-the-shelf splitters, for example, are 1Ghz splitters. None of the existing equipment in the industry transmits in that slice of spectrum and I'm pretty sure there's some other issues as well that keep them from going into those areas of the spectrum (3) > Here's a cheer for Eatel and competition. I hope neither is thwarted. > Yep. competition is why then went to 5Mbps/512kbps in the first place so more competition can only push things further. (1)Lots of people in the cable industry want to dump analog transport completely and go "all digital" forcing the use of digital tuners (either in boxes are via in-TV cable digital tuners with "CableCards" like satellite) Getting back all those 6Mhz chunks between channels 2 and 74 would be huge for them since they can pack so many more standard digital and HDTV digital signals into a single 6Mhz analog channel. (2) making an assumption here. 860Mhz is the current "standard" in cable plant buildouts/upgrades though there may be some 1000Mhz plant out there. Going above 1Mhz is highly unlikely any time soon so additional tricks with modulation schemes, frequency hopping/spread spectrum tech, and dumping analog as described in (1) is where things seem to be going albeit at a slow pace. It'll be interesting to see if they go from raw MPEG transport to a packetized infrastructure for video as they have with data and voice already. (3)I'm not an RF engineer actually and haven't fooled with this stuff on a day-to-day basis in a couple of years so some of the details are fuzzy. Dustin, I can take this off list unless people really are curious about this minutiae. Just to keep it on topic, Linux journal did a couple of articles recently on gnu radio that talk alot about spectrum usage and other interesting ideas. Some cool things you can do with their software and taking apart a cable modem or two. http://www.linuxjournal.com/article.php?sid=7319 (the september article should be online in a month or two) http://www.linuxjournal.com/article.php?sid=7650 -- Scott Harney <[EMAIL PROTECTED]> "Asking the wrong questions is the leading cause of wrong answers" gpg key fingerprint=7125 0BD3 8EC4 08D7 321D CEE9 F024 7DA6 0BC7 94E5
