Hi Eric, thanks for the critique. You note,
"I think you may be trying just a tad too hard and are taking things a bit too literally."
I've been cited by AHhaha at times in other venues as being overly cautious because I use too many caveats and qualifiers, to the point of distraction, almost. I have to do this, especially in mixed company, for the very reasons you have presented me with here today.
Eric: "Whew. It was a rhetorical question! [The poster] had just calculated the absolute worst case and said "how likely is that anyway".
Of course, and that's one of the reasons I discounted its validity. It had no value in real terms, but was useful for discussion.
I knew that the poster's question was not specific, and it could be regarded as rhetorical as you say, but I factored that in and discounted any self-liability I might otherwise incur, in my introductory statements.
I made a claim that gave me license to expand as I saw fit. I used his question as fodder, in that respect, and I stated as much. You'll see this if you go back and read the intro wherein I referred to some of my own content as being a bit much for the purposes of his specific query, and stated that one of the reasons for my response was to answer other [which were in large part your] questions. Not in those exact words, but since you've highlighted the matter, I felt that I must explain it the way it is.
As for the remainder of your points, the one about the streaming data was very well put, and I've expanded on it with qualifiers, below.
But you either didn't take the time to read the wording in my post very carefully in other spots, or I was unclear in those areas. Let's go over your observations.
Original Poster: "... what are the chances that all 125 subs are on at the same time, and receiving information simultaneously?"
FAC: "These kinds of exercises have a place in engineering for their theoretical qualities, in order to characterize the steady state of a system, for bench marking purposes, but they are not realistic and have little place when assessing real world contention issues.
The poster's question was useful to the extent that it afforded me the opportunity to take it off the table. No harm done there, only benefit, because I both reaffirmed one of his notions that it was unlikely anyway, and then went on to use the scenario in two contrasting what if examples. I fail to see anything objectionable here, as well.
You stated that the line was shared in a time scale domain. No argument, if by that you mean sequential delivery of data for all users, when their individual turns come up. They don't share the channel at the same time, is what I was stating.
Eric: "Of course the lines are being shared! Its a matter of time scale. What you are doing is the same as looking at a TV picture and saying that the picture is not really there because its actually a single electron beam scanning over the screen."
[What about the times when the picture really isn't there and you wonder about where and why that is? No fast scanning taking place there at the moment, I presume.]
If you read my statement again, you'll see that I've factored your interpretation into the formula, too. Concerning the fact that the line channel itself was not shared in a simultaneous manner,
FAC stated: "I believe this to be so, in part because they [common opinion] assume[s] that users are actually sharing a line at some point, or that all users are sharing the same line at the same time, in a synchronized manner..."
The bolded qualifiers in the preceding sentence from my original post should serve to make my point clear and exonerate me at the same time, hopefully.
And of course, I continue to maintain that posture, and I refute the assertions you've made which would lead the reader to conclude otherwise. The individual 6 MHz downstream channel is not used by any more that one user at a time. Period. Which was the point that needed to be made in debunking the notion that users would ever collide on the same channel with one another. In contrast, you seem to be intent on perpetuating that notion in a fuzzy kind of way, for some reason.
It's important enough to state one more time: It doesn't happen.
When multiple downstream channels are used because of upgrades that have been signaled by heavy usage, even those individual channels in the downstream (which must be tuned or selected separately at the STB by different user groups) are not shared in the manner your message would lead readers to conclude. I made this point in the upstream, as well.
Later on in my tome, I went on to talk bout increasing bit rates versus realized gain on HFC systems. My comments were predicated on an understanding of time of propagation in half-duplex messaging systems, sluggishness incurred during interchanges, protocol turnaround time dynamics, and various lessons learned in fundamental application profiling. I stated, in response the the poster's question:
FAC: "At best, doubling the fundamental bit rate might yield a 60% or 70% increase in overall realized throughput gain, and less, as the distances increase."
Your reply, "Fortunately this is not true in the times when it counts the most, large numbers of users using streaming media or downloading large files, then the scaling is nearly linear with bit rate and independant of distance."
Granted, when sustained flows exist, you are correct, and the mitigating factors I mentioned are themselves reduced.
But when short bursty traffic, as characterized by the bulk of web traffic is the rule of the day, then turnaround times and the ensuing proportionate gains assumed to result from increasing the bit rate, are even worse than those which I've stated.
Performance varies in the middle ground, accordingly. While I will concede to you your point about streaming data, if we take all types of traffic into account that could be expected to traverse the line, then my statement still holds true. on average.
Hand shakes and turnaround times are indeed affected by not only the slowness, relatively speaking, of the upstream, but also the modem's reticence at times to transmit anything in the upstream until conditions are right. The user's modem is constantly listening to the line for this reason, or is governed by algorithms which have the same effect.
I regard your remaining statements as actually agreeing with what I stated, although your phrasing has a curious tone to it, to me. In any event, thank you for replying, and I look forward to more of the same.
Regards, Frank Coluccio |
