Re: [SkunkworksAMA] Interesting Phenomenon

From: David Parenteau <kitfox_at_firstlight.net>
Date: Mon, 12 Dec 2005 00:21:50 -0700

At 08:08 PM 12/9/2005, Axle Gear wrote:
>Been working with computers in general for 13 years. Worked in computer
>repair and for a cable ISP for several years each. Currently work with
>satellite systems.

Ooooh. I could tell you that I've been working with computer systems for
about 15 years, and I currently work as a remote system administrator. I've
worked in computer repair, networking, hardware, help desk, for several
ISP's, some software companies, been flown all over the US... Well...
Honestly, It doesn't mean that I am always right. So, given your
disagreement with my statements, I decided to refresh my information and
see what's up...

>The 8 mbps limitation is the physical (as in: Not networking) limit of
>actual bandwidth. Just like '128k dialup over 56k', it's marketing. You
>compress the data and, duh, you reduce bandwidth consumption. But it's
>still realistically limited at 8mbps, this is because RG59 has that physical
>limit. Approximately 60% of all cable networks still use RG59. RG6 is
>provided in many areas now, and is standard in satellite installations. It
>maxes at a much higher 24 mbps. Finally is RG11, and not many cable
>companies use it. It maxes well over 100mbps. Aside from on Hawaii, I am
>not aware of any internet service that uses RG11, since it's costly and
>usually unecessary. The vast majority use RG59, unless it's for a
>business/commercial account.

Strange... Comcast in most areas of Denver and surrounding area uses 256QAM
on each of its channels, thus achieving a data rate of 38Mbps per digital
channel. (As opposed to the older 64QAM, which achieved approximately
27Mbps per digital channel.) Now, bear in mind that each "digital channel"
is literally an analog channel (2, 3, 4, 5, 6, etc) that has been set to
carry a digital signal at the proper encoding as opposed to the analog
signal. Most cable systems are converting to full digital, as they can fit
more channels total that way. It makes sense, of course, since "channel
10" in analog can only carry "channel 10", but with digital channels
averaging between 2 to 4 Mbps of data per "channel", you can fit at least 8
of those on any given 256QAM-enabled channel, if not many more.



>As for which cable services I used: Comcast, Charter, Roadrunner
>Worked for: Comcast
>Currently using: Comcast (Commercial) [due to lack of DSL availability]

Commercial in Denver 8Mbps costs around $200/month unless you got the
salesperson to give you a disgustingly good deal, or are grandfathered into
an employee plan.

>I've been with almost all the major providers of internet for every
>technology, save fiber optic. Only ever been with BellSouth on that.
>Bellsouth, Qwest, Charter, Comcast, Roadrunner, Earthlink, SBC, Starband,
>and Brighthouse. I've been around.
>
>Not a single one offers a residential package which exceeds 2mbps average.

You do realize that the "Pro" package you have is residential, right? It's
8000/768 QoS on the modem. So obviously you need to rethink that statement.

Or perhaps you are talking about the "Average", based on highly-compressed
data on the cable side? Right... I happen to have 8Mbps down myself... I
download an already-highly-compressed item that is NOT going to get much
more compressed... check my network graphs... and... 7.9Mbps over the
course of a 1.5GB test download.

>You have to keep in mind the market speed is very much NOT what you get,
>it's only the bandwidth >allocation<. It's the same as getting a 128k
>connection on a 56k modem; You're still averaging 48k.

Ahhh, not precisely that even. In fact, the two are VERY different. The
56k Modem running at 48k is due to the fact that the modem is actually
taking a digital signal, tossing it onto an analog system, and then
re-digitizing it. The actual physical limitations of the digital
information going into a single phone line are 8 bits at 8000Hz, thus
64k. But since it has to survive that analog conversion, and back, it just
has some serious trouble being "perfect". 56k is the "Upper Limit" of the
technology, and 42-48k is "average". Thankfully, modems DO compress the
data and therefore can get some higher speeds on well-compressed data, but
that affects data throughput, not the carrier. So the digital CARRIER on a
48k connection from a 56k modem is 48k, regardless of the actual data
throughput.

Now, in the case of a cable modem system, a channel (Saaaaay, 609MHz for
example) is encoded into 64QAM or 256QAM for the purpose of
downstream. Now, in fact, all of the information for you and people NEAR
you is actually broadcast on the same channel in timeslices, and unless the
transcoder at the cable system end has some funky QoS going on for your
modem, all users are treated equally. Toss in your FEC framing, and then
dole out packets across the QAM in order. Of course, with 256QAM, this is
up to 38Mbps. BUT!!! Remember that this "channel" should be dealing with
more than one person! So let's limit them to 8Mbps. The MOST common way
of doing this is to have the cable modem itself perform QoS. It gets told
"Don't use more that 8000kbps (Not true 8Mbps, but ahh well)
downstream."... So, when it gets higher speed sent to it, it holds onto
its acknowledgement packets BACK to the transcoder system, which causes the
stream to pause, waiting for ACK, and thus it can regulate the total
overall flow in a binary manner.

So, in the case of the 48kbps, that is the carrier on the
line. Compression can hike up the data throughput rate. In the case of
the Cable modem, the carrier is either 27Mbps or 38Mbps, depending on the
QAM used, and the cable modem picks out its data from amidst all the data
designated for other cable modems on the same node trunk.

>And btw, who the fuck do you have cable with!? 43 ms latency? That's worse
>than most dialup i've had, christ! (BellSouth was only 20 ms on standard
>56k)
>Averages for dialup are 50-400, depending on how far the uplink is. Cable
>averages 18-40. And DSL averages 10-80, depending on how far the uplink is.

I'm not talking about uplink latency (Mine is an average of 8, by the way),
I'm talking about real latency. Specifically, my average latency to a
sampling of geographically close (As opposed to network-close) systems with
sufficient bandwidth as to not add a massive quantity of latency on their
end. I think that if you, for example, send 100 ping in the direction or
www.l.google.com, you will quickly discover your latency to be around
40-50ms for google as well.

By the way, the DSL average latency depending on the distance of the uplink
is somewhat misleading, as it is true, but the distance is actually
affecting the total possible uplink speed, and the uplink speed affects the
latency. Uplink speed (Both Up and Down bandwidth) is going to be the
biggest determination of latency, unless you have some funky equipment
going on.

Let's take a quick look at why, which I'm certain you already know, but
other folks may be interested in. How we measure latency is simple: Say
something to another place, and have it say the same thing back. We assume
that the other place is going to send the information back as SOON as it
gets it, so we can measure the time between when we say it, and when we
hear it back, and that is latency. Since we are dealing with short-hop
connections, we don't have to deal with the speed limit of C, like you do
with satellites or long distance links, so we won't worry about that.

Now, let's take an arbitrarily (And unusual, but much easier to calculate)
sized packet: 100 bytes. Then, let's take a serious extreme: 75 bps
(Wow! The Slowen Old Days!)... Now, if we can fit 75bps across the line,
and assuming (for simplicity again) absolutely no transport overhead, we
have to take that 100 bytes, or 800 bits, and shove them all across the
line in the direction of what we are checking the latency on. SO we drop
it there, start counting, and the data starts going. AT 75bps, those 800
bits take 10.67 seconds to get there. Then, it promptly starts sending it
all back. Assuming 75bps back, you're looking at another 10.67 seconds to
get back, or 21.34 seconds total latency. Eww. But extreme, so it works.

Right... Let's go with something REAL then...
48kbps down, 31kbps up. Oooo... Modems...
Okay, so for simplicity, we'll say that we're actually talking 48,000 bits
and 31,000 bits per second respectively. So we take our 800 bits, and drop
them, then start counting. Well, it ends up getting to the other side in
0.0258 seconds... or approximately 26ms. Then it gets echoed back. Coming
back along a faster path, it hits here in 0.0167 seconds, or about 17ms.
Add those together, and you get 43ms latency. But that's in PRECISELY
PERFECT situations. Slower connections, slower responses, and many other
things can slow that down.

Right, then let's look at some Cable speeds: 2Mbps down, 128kbps
up. Right... Again, we'll use 2,000,000 and 128,000 for calculations, just
to make things easier. The same 800 bits, heading up, take a comfortable
0.00625 seconds, or 7ms (rounded up). Heading back DOWN, they only take
0.0004 seconds. Less than 1ms. (Wouldn't it be NICE if both directions
were the same higher speed?) Altogether, 7-8ms. Oooooooo. Nice. But
then, of course, that would be talking to the machine that talks to the
cable modem ONLY... anything else then adds latency for each and every
extra network router you go through.

>Most cable companies don't have the newer DOCSYS specifications on their
>modems. This includes Comcast as of right now [Beleive me, I recently had a
>long fight with them over that and port blocking], or charter as of last
>year [not sure about currently]

Huh. Well, true, Comcast doesn't use DOCSIS 2.0 (The current "newest"),
though they do use 1.1, and most of the the modems are capable of
2.0. However, notably, DOCSIS is not really a speed indicator. It defines
the Radio Frequency Interface, Operations System Support Interface,
Baseline Privacy (Remember how the 38Mbps channel is carrying everything
for you and a bunch of other people also? Baseline privacy is the
definition the modem uses to decide to toss out all the data that belongs
to somebody else.), and of course just general equipment operations and
specifications. So that does not really actually matter that much.

>Also, it's false that different frequency doesn't affect
>bandwidth/TV-Internet conflict. Both still send a physical signal across
>it, and ALL cable companies use the tv-signal (usually 'Null' channels) to
>piggyback the internet data. Not only is the pipeline and bandwidth shared,
>but also the packets. Cable modems are extremely simple devices, all they
>do is remove the TV/Audio portion of the signal and digitize or translate
>the remaining signal. This is the source of most of the cable's latency.

Oooo... No, blatently incorrect, nuh uh, no way, no how. What old system
are you talking about? Wow...

In ALL circumstances, the cable modem data is on its own channel, whether
it be encoded 64QAM or 256QAM, and almost invariably separate from channel
data. Yeah, TECHNICALLY if they had a very small allocation for internet
traffic, they could pump video data over the same channel, but VERY few do
this. None that I know of. Now, the definition of "Channel" is basically
one RF "channel" on the cable. (Yay for Radio over Wire!). One channel
can carry either an analog (Your TV by itself can see it) or digital
(requires a decoder, usually cable box) transmission on the RF carrier. In
analog, it can only carry ONE video channel. In digital, it carries 27 or
38Mbps depending on QAM.

So, that means that if more people turn on their TV's, it takes more
bandwidth, right? Nope! ALL of the data is broadcast. This means that
it's ALWAYS there all the time, the TV or cable box or cable modem just
choose which chunks to look at. All of those lovely analog TV channels are
just a broadcast on a different frequency, completely unaffecting the
frequency or data on which the cable modem is operating. The channel on
603MHz has no effect on the cable modem on 609MHz, which doesn't affect the
next channel on 615MHz.

If you look at it from an analog point of view, with only ONE channel
designated 64QAM (27Mbps) for internet data, then the TV data is ALWAYS
there, and no digital internet data is "piggybacked" on it, just the cable
modem tunes in to the proper downstream channel to find the QAM.

Now, technically, it is possible for the cable system to actually tell the
cable modem to change channels frequently to get data from a lot of
channels (Yay BROADband!) but in practice, this is not used very often, as
it takes a lot more work to insert internet data into EVERY RUDDY CHANNEL'S
TRANSCODER, timeslice it properly, and still get things running
properly. In technicality, this COULD be more efficient, allowing faster
speeds as a whole and supporting more folks per trunk, but in practice it's
less common.

However, this being said, even if you take a 100% digital system, with
internet piggybacked in spare frames on a multitude of channels, you still
have a solid, constant, and stable quantity of audio and video stream being
BROADCAST constantly on each virtual channel, thus "more people turning on
their TV's" will have absolutely no effect on the internet traffic, as the
data is always there, the TV turned off just ignored all of it, and turned
on just picks out the specific data it wants.

Now, the next thing to consider is your 8Mbps claim...

If you have 70 cable frequencies (a VERY low estimate), each running
256QAM, you have a total bandwidth there of 2.66 GIGAbits per second, all
coming over that pretty little 75ohm cable running into your house, being
split up into happy parts by your cable decoder box and cable modem, and
sometimes even into phone lines in some Comcast areas.

>As for fiber optic.... yes. A 1mbps up/down fractional T1 would cost me
>$100/mo. And I gotta buy my own equipment.

Erm... T-1 is RARELY optical... It's generally brought to the CSU/DSU by
four copper wires. In fact, due to the COST of putting optical in TLM (The
last mile), anything that CAN go copper usually does. And this is most
everything below a T-3. And of course, in that $100/month, you're
forgetting the local loop charges, which are dependant on your distance
from the CO. In my case, for example, 15,000 feet of wire from the CO, my
local loop for that $100/month fractional T1 would cost $285 or so!

>I basically said "Fuck you,
>Qwest" and got Comcast commercial. 8down1up. It's okay. But they don't
>offer higher upstream in the Denver area.

Well, quite honestly, given the technology difference in upstream vs
downstream in cable modem technology (Downstream is 100% server-based
timeslices. Upstream gets a bit messier from dozens of modems talking on
the same upstream channel at once. Plus the frequency of the upstream
channel is MUCH lower, thus reducing the digital capability of the analog
carrier), I seriously doubt you'll see much above the 768k (not 1M) you are
getting from Comcast right now. They might bump it up a bit in the future,
but that'll be a ways off. Doesn't make sense much honestly otherwise.

>Way to size to the population,
>Comclash. No wonder Qwest has a HQ here. Not that their coverage is
>sensible either. XD I'm caught between two really big, really retarded
>giants.
>For now, i'm okay (not satisfied) with Comcast's $79.95 package. I get 5
>IPs (all they offer), 8/1 mbps, and a bunch of blocked FTP ports.

Actual QoS settings on your modem are almost invariably 8000/768 BTW, not
8000/1000. Blocking inbound ports? Well, yeah, since they prohibit server
activity unless you get the "recently released to 'home offices' as well"
commercial package for over $200/month.

>It's that or Qwest's "Fringe Coverage Package" of 256/128 kbps for
>$29.99/mo, with awful latency (100+) and packet loss.

Beats the pants off the 192/128 they offer in Boulder.

Anyway, all stated facts confirmed within the past 3 hours. Experiences
for all folks may not be the same, many cable companies DO suck the
donkey's left nut, and differences in technology use may differ from
location to location. But hopefully some folks now know more about cable
modems than they ever wanted to know.
Received on Mon Dec 12 2005 - 00:03:28 CST

This archive was generated by hypermail 2.3.1 : Sat Nov 30 2019 - 17:52:09 CST