Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

Comment Re: Great! (Score 1) 260

I don't think he was defending Twitter so much as defending peoples' right to commit the grand error of using Twitter. He even, later, said as much; he believes Twitter should die, but a natural death, one borne of people realizing it sucks, rather than one borne of a few script kiddies attacking it and taking away the freedom of choice that others currently enjoy.

In other words, Twitter should die because we, as a society, exercised our freedom of choice to stop using it, not because a few assholes exerted force to take that choice away from us.

Comment Re: Great! (Score 1) 260

What's funny is... as bad as people thought 4chan was 6 years ago, it's so much worse now. At least there was some substance to some of what's posted there, at some point... Now? Not so much. The best of 4chan has moved on and the worst has multiplied itself. I still browse there on occasion, much for the same reason I still browse here: hope that the good will come return. Not that there was ever that much good on 4chan to begin with, but what there was was really good.

Comment Re:A speed limit (Score 1) 151

Well, I was going to be done with you, but you've finally made clear which part of this you aren't understanding.

Deprioritized packets = inferior quality usage to what one would otherwise have received at the time.

Wrong. When there is no congestion, priority doesn't have any effect and it doesn't matter of you're at the front of the queue or the back. However, when there is congestion, if left unmanaged it causes packet loss as more packets try to fit through the "pipe" than can actually fit, which leads to retransmits; that is, everyone's talking and trying to be heard, bot nobody can really hear anyone else, so everyone keeps repeating themselves. All of this just exacerbates the congestion, as more and more packets are dropped and begin the re-send cycle. It's a snowball effect, at first it's just one dropped packet being resent, so that packet has now been sent twice, but in that time 10 more packets were dropped and must be re-sent; and some of those re-sent packets will get dropped, so they'll have to be sent a 3rd time, maybe a 4th or a 5th, until you've got so many packets not making it through that the bulk of your traffic is retransmits. Eventually, those retransmits will exceed the available bandwidth (on top of new traffic which is already exceeding that physical limit) and the majority of those will be dropped, as well.

In that situation, once the snowball has gotten itself rolling, nobody gets any of their data until everyone shuts up and lets the noise die down. And nobody is coordinating to allow that to happen, so it never does unless network management is applied, to force the issue.

By queuing the packets of some users, you prevent this contention for bandwidth and avoid the dropped packets and eventual retransmit storm.

To be clear: left unmanaged, heavy users get nothing (just like everyone else) on a congested node; managed, they get the data they request.

Did you, after I've explained it several times, honestly not understand that? Or are you attempting to claim an unusable connection is of superior quality to one that is stable and usable?

Comment Re:A speed limit (Score 1) 151

And even if everyone's usage suffers during periods of high congestion, nobody suffers during periods of lower congestion, so it is genuinely possible for companies to offer unlimited packages if they wanted.

Whereas, with properly implemented QoS, as we have here, nobody's usage suffers during periods of high or low congestion.

I'm done trying to educate you, though; you simply do not want to learn, because to do so would require you to admit you were wrong. Peruse my posting history and see what that looks like.

Comment Re:A speed limit (Score 1) 151

What you seem to be missing is that deprioritization of users who have already downloaded more than some threshold in the current billing cycle is still a *limit* on the level of service that those heavy users pay for.

I'm not missing that at all, actually. As I've stated previously, deprioritization increases the overall available bandwidth by eliminating retransmits caused be contention; that is, it stops people from having to talk over each other and repeat themselves, so everyone can talk, hear, and be heard. Without it, when there is congestion, throughout quickly approaches zero, for everyone; with it, everyone gets their data.

It's a logical fact that some (and I mean explicitly some, not all) users must be deprioritized when there is contention over limited available bandwidth (e.g. congestion) in order for the network to remain usable. If you deprioritize every user equally, you may as well have done nothing, the contention remains, and nobody can use the resource.

You suggest that deprioritization increases your ability to use the service, but it does so by explicitly *limiting* the amount that you are allowed to use the service without deprioritization.

And, without it, you're limited to only being able to use the service in the absence of contention over bandwidth.

That is a limit. Properly implemented QoS, which is what T-Mobile has here, is a workaround for that limit.

You very clearly aren't capable of understanding this. Again, I don't fault you for that, it's not something that's obvious (or, really, believable) unless you've actually seen it in action as I have. I'd say we should just agree to disagree, but I can't do that with someone whose opinion is based on a factually incorrect understanding.

It appears we're at an impasse, here.

Comment Re:A speed limit (Score 1) 151

What you're missing, the point I'm really trying to drive home, is that deprioritizing heavier users increases available bandwidth for everyone, even the heavy users . This is true because it frees up bandwidth that would be wasted by the contention it prevents.

A limit, in the context of a service, is something that reduces your ability to utilize the service. This increases your ability to do so, regardless of which side of the queue you are on, ergo not a limit.

Comment Re:A speed limit (Score 1) 151

You're always affected by the contention control, you never transfer so much as a single byte without it. You benefit from it when you're not the one being deprioritized, by being placed ahead of those who are; and you benefit from it when you are being deprioritized, by actually having available bandwidth due to the contention control being implemented in the first place.

I'll repeat: contention control actually effectively increases the limit of overall available bandwidth (e.g. you get faster speeds no matter which side of the priority queue you're on) by preventing people from talking over each other and causing massive floods of retransmitted packets.

I would agree with you if anyone were receiving worse service as a result, but the reality is quite the opposite.

I'm not sure how many different ways I can word that, but I feel as though I'm just repeating myself at this point. Since I'm already repeating myself:

If you've never implemented proper QoS on a congested network and seen the immediate impact it had on the traffic flow, this isn't something that is obvious to most people, so i fully understand how you might think it's a limit of sorts, but the reality is that it enables all users to effectively get their data instead of flooding the data with retransmitted packets as everyone attempts to talk over everyone else.

It's literally the opposite of a limit; it enables everyone to use more data. Period.

Comment Re:A speed limit (Score 1) 151

when they do, in fact, set some limit on how much someone can actually utilize

Funny, I routinely hit 50+GB and have never run into an imposed limit. The limit is that of the network itself, a physical one, minus everyone else's traffic. Implementing some form of contention control ensures that I'm consistently able to access what many people refuse to accept as a scarce resource.

It's not like wireline or fiber, where you just run more cables and everything is good; wireless bandwidth is, really and truly, a scarce resource. Network management is not limiting usage, it's enabling it. That some ISPs *cough*Comcast*cough*AT&T*cough*Time Warner*cough* implement usage limits and hard throttling and call it network management does not make it so.

The reality is that T-Mobile queues the packets of heavier users behind those of lighter users, but it does not drop or refuse those packets (not that would be a limit), and it does deliver them before connections time out (save for network issues, where they would time out regardless of priority).

I get what you're saying, though. I do. It's just logically impossible. You want everyone to be deprioritized equally when there's congestion and, well, if everyone starts out at the highest priority and they, simultaneously, all drop to the lowest priority, they're all still the same priority, there is no hierarchy, everyone's still equal, there's still contention and everyone is still trying to talk over everyone else and the network is still completely unusable.

I'm sure there are providers who do this. Go find one, switch to them, and tell me you still want that.

Comment Re:A speed limit (Score 1) 151

So you'd rather have contention prevent anyone from using the service, rather than network management that allows everyone to use it?

From your previous posts, it seems as though you think there's a speed limit or throttle placed on users exceeding 26GB when this is, in fact, not the case.

Slashdot Top Deals

To iterate is human, to recurse, divine. -- Robert Heller