Comcast problem – bandwidth and pings

GotNoRice

[H]F Junkie
Joined
Jul 11, 2001
Messages
11,955
I was downloading a torrent tonight and I noticed that my internet was being incredibly slow. I opened up a ping to google and yahoo and both were 1000+. I stopped the torrent and everything went back to normal. Now I have everything setup fine and torrents work awesome. At any given time I’m seeding 150+ torrents and usually downloading one or two. I wanted to see what was going on so I opened up my traffic graph and started the torrent.

comcast1.JPG


After the healthy 20+ meg burst, it pegs at ~8.8 which is what the download cap is. Before, it would usually go back down to around that speed after the burst, but it was never as steady as that. Before, after the burst it would usually just fluctuate between like 7-10 megs. It definitely seems like they changed or implemented something different on their end. I don’t really care that it pegs me at 8.8 after the burst, but why in the world does it destroy my ping times like that?

My router has a traffic shaper of it’s own, and if I enable that and set my own caps just slightly below the Comcast caps, the torrents don’t affect my ping in any way. The downside to this that when I implement my own caps it obviously does not allow bursting.

comcast2.JPG


Before, I didn’t need to use my own traffic shaper, I could benefit from bursting, and it would settle down to a ~8.8 average speed without nerfing my ping. I’m trying to figure out exactly what is going on now, or what changed.
 
it's 100% normal for latency to go to shit when torrenting. You're maxing out your download and (possibly) upload. Dial it back & limit the speed / # of connections in your torrent app.
 
it's 100% normal for latency to go to shit when torrenting. You're maxing out your download and (possibly) upload. Dial it back & limit the speed / # of connections in your torrent app.

I’ve had this system in place for over a year exactly how it is, and the problems only started recently. And again, if I implement my own caps via the traffic shaper on my router (at the same speed as the Comcast caps, so I still download at the same speed) my pings are unaffected by the torrenting. In both cases I’m limited to ~8.8megs bandwidth, but if I rely on Comcast to do it my pings go to shit. This did not used to be the case. Rather than peg exactly at 8.8 and nerf my ping, it would just sink down to about an average of 8.8, while the graph would show it fluctuating between ~7-10megs. I have my XP TCP settings tweaked as well as my torrent client set to allow 600 connections and there have been times when I’ve been pounding away at 3-4 torrents at the same time all with 5000+ peers each, it didn’t affect my ping then, why would it affect it now?

I do always implement my own traffic shaper on my upload, so that if it does get maxed out, bittorrent traffic is set to the lowest priority, but in both screenshots I wasn’t anywhere near maxing my upload.
 
Like everyone else said, it is perfectly normal to see your latency rise as you consume more and more of your available bandwidth. As to why you were not seeing this before is anyone's guess...
 
I'd expect changes as Comcast settles in their PowerBoost. When PowerBoost first came out...it was very..hmmm..uncapped in my area...as in the past I've posted screenshots of my bandwidth at over 70 and even 80 megs of download. But a few months ago..it's settled to about 28 megs.

So you enjoyed, as I did, unchecked bandwidth for a while..but now you're where you should be.
 
I'd expect changes as Comcast settles in their PowerBoost. When PowerBoost first came out...it was very..hmmm..uncapped in my area...as in the past I've posted screenshots of my bandwidth at over 70 and even 80 megs of download. But a few months ago..it's settled to about 28 megs.

So you enjoyed, as I did, unchecked bandwidth for a while..but now you're where you should be.

My post doesn't really have anything to do with bandwidth. There is nothing about limiting my bandwidth to 8.8 that should make my ping jump to 1000-1500. Even before they changed whatever they changed, it still settled down to an 8.8 average after the burst without any negative impact on my ping. If it was just a matter of my download being saturated, I'd expect my pings to jump to maybe ~150
 
Like everyone else said, it is perfectly normal to see your latency rise as you consume more and more of your available bandwidth. As to why you were not seeing this before is anyone's guess...

Yet if I set my own caps at 8.8 and "consume all of my bandwidth" my pings don't go up at all. Not even 5 ms higher than they are when my connection is idle. I can peg my connection with 5 torrents all with 500+ seeds each AND download a file from fileplanet (free sub with gold tier comcast lol...) and it doesn't affect my ping then - but if I rely on the comcast caps to limit my connection, the second they kick in my pings jump?

I mean common... I'm not naive, I understand full well how bandwidth affect pings when a connection is saturated. That is why I implement a traffic shaper on my upload, because when you only have 768 to work with, you have to do what you can do, but 8.8 megs is enough that I should NOT be seeing such adverse affects just from running one torrent. It didn't do it with whatever caps they had in place before, it doesn't do it when I implement my own caps. Hell, our pings weren't even that high when we were having a LANparty at my friends on his 768/128 DSL account with 7 different people all trying to download a huge steam update at the same time...
 
Maybe they're just discarding packets that are over your limit and the latency you're seeing is the result of retransmits. Your router/shaping would intelligently balance it instead of discarding.
 
Traffic shaping is great, but you only have control over your OUTBOUND traffic shaping. You have no control over inbound traffic, that's controlled by your ISP.
 
My post doesn't really have anything to do with bandwidth.

Actually it still does relate to overall bandwidth..and it's not just download..the other half is upload. Then there's QoS. Then there's the possibility of whatever the heck bad stuff you pick up with that P2P software which may affect your traffic..and even winsock. P2P..you have variables up the wazzoo.
 
OK, so what kind of answer are you looking for if the answer "you are consuming all of your bandwidth therefore RTD times will rise regardless of the fact that you are policing your outbound traffic" is not to your liking?

It's called round-trip delay for a reason, it's the addition of both leg's from said traffic (in this case, ICMP). Therefore, if your link is saturated inbound, then your latency will increase.

If this is that big a deal, then my advice to you is don't rely on Comcast for traffic prioritization or this is the kind of thing you will see. After all, you are talking about a shared service that is not exactly known for it's reliability in the first place.

Capping it yourself at the perceived ISP cap may or may not be a valid test depending on what they may or may not be doing at the time or what kind of traffic exists at the time.
 
Traffic shaping is great, but you only have control over your OUTBOUND traffic shaping. You have no control over inbound traffic, that's controlled by your ISP.

I can setup traffic shaping on inbound traffic just fine, so long as I set the cap at a value lower than the cap set by Comcast. That really is the issue here – if I do that and leave it enabled everything works fine (see 2nd screenshot), but if I do that then I can’t take advantage of bursting.

Actually it still does relate to overall bandwidth..and it's not just download..the other half is upload.

In both screenshots, you can clearly see from the traffic graph that I wasn’t using more than 200-300k upload out of 768.

Then there's QoS.

What about QoS? I would think that even a basic QoS implementation would prioritize ICMP, etc, in which case my pings should be the last thing to be affected like this.

OK, so what kind of answer are you looking for if the answer "you are consuming all of your bandwidth therefore RTD times will rise regardless of the fact that you are policing your outbound traffic" is not to your liking?

I’m really just looking for more information about what is possibly going on, so I can make the most informed decision possible in regards to maximizing my connection using the tools at my disposal.

It's called round-trip delay for a reason, it's the addition of both leg's from said traffic (in this case, ICMP). Therefore, if your link is saturated inbound, then your latency will increase.

Yet in my 2nd screenshot my connection is just as saturated as it was in the first screenshot, but my pings are not affected – fancy that.

If this is that big a deal, then my advice to you is don't rely on Comcast for traffic prioritization or this is the kind of thing you will see. After all, you are talking about a shared service that is not exactly known for it's reliability in the first place.

That might be what it comes down to, but at the moment I’m still exploring my options in regards to being able to torrent while maintaining the benefits of bursting. Right now I can have it either way but not both ways (both ways being how it’s been for the last 4+ years)

Capping it yourself at the perceived ISP cap may or may not be a valid test depending on what they may or may not be doing at the time.

It is a valid test in terms of trying to find out exactly where the new bottleneck is, and making sure it’s not on my end.
 
You aren't getting it. You have no control over what comes IN from your connection. You control what gets to your network from the cable modem, but you have NO CONTROL over what comes in to the cable modem. This is where your problem lies. If you saturate the inbound, then latencies go up. No amount of tweaking on any router in your control will help with this. Only comcast can implement QoS on your line once it leaves your local network.

All the QoS in the world won't help you once the traffic leaves your house over the cable line. At that point you have lost control. You are in the Matrix and you need to swallow the blue pill already.
 
You aren't getting it. You have no control over what comes IN from your connection. You control what gets to your network from the cable modem, but you have NO CONTROL over what comes in to the cable modem.

I don’t see how that is pertinent other than maybe if I was getting hit by a DoS attack.

This is where your problem lies. If you saturate the inbound, then latencies go up. No amount of tweaking on any router in your control will help with this.

First of all, “tweaking a router” is exactly what I did that fixed the problem. It doesn’t matter what comes in to my cablemodem, if I set my inbound traffic cap below the Comcast cap on my router, it does not allow more than that amount of traffic in, thereby making it impossible for anything outside of my network to be the bottleneck (at least in terms of the new ghetto caps that nerf ping kicking in). That is why once I enable traffic shaping on my inbound traffic, I can torrent to my hearts content and still maintain ~20ms ping times. What is it exactly that I’m “not getting”?

All the QoS in the world won't help you once the traffic leaves your house over the cable line. At that point you have lost control. You are in the Matrix and you need to swallow the blue pill already.

None of my problems are related to my upload in anyway, so I fail to see what point you’re trying to make here.

Since you’re apparently a genius at networking, please explain to me why if I set my inbound traffic shaper cap to 8.8, that I can hammer away at my connection much more savagely than I was when I was running that one single torrent yet maintain perfect ping times. Please, tell me, since I apparently just don’t “get it”.

To be honest, for inbound traffic shaping to work best I need to set my inbound cap at ~90% of my inbound ISP cap, not 100%, but the fact that I can set it at 100% yet still dodge the negative effects of the Comcast cap is just another part of the mystery I’m trying to figure out here. It seems like the cap is only triggered if you allow it to burst, but that is just speculation at this point.
 
All you are doing is limiting the amount of traffic your firewall let's through to your local LAN, that's it. You have no control over what traffic actually hits the outside of your firewall, only the traffic (or in this case, amount of traffic) that you let in...

Does this make sense or are you not understanding how traffic shaping, policing, etc. works with a connection where you only have control over one end?
 
Phunball is correct. You DO NOT HAVE CONTROL OVER YOUR INBOUND CONNECTION!

Everyone in this thread has told you, but you continue to argue that you can control it. You can't. You have no control over what hits your cable modem. None whatsoever. That's great if you set an inbound cap on your WAN>LAN bandwidth, but that has nothing to do with what's hitting the cable modem.

I could cap my connection at 100k but that doesn't stop data from coming in at 5mbps to my cable modem. It just means my firewall/router is essentially dropping all the excess packets. Which ones does it drop? Who knows. This is essentially what happens on your cable modem as well.

You have a cap at the CO of 10mbps. But 15 mbps of traffic is trying to reach you. Do you think that comcast will let YOU decide which ones it sends you? No, of course not, that's absurd. So what happens with that other 5mbps of traffic that isn't hitting your modem you ask? Well, comcast is dropping it, or qeueing it. Hence, the 1.5 second ping times. Since you have more traffic headed for you than your line supports, comcast just decides what you should or shouldn't receive.

And I'm starting to doubt your traffic shaper's abilities or how you have it set up. You only put a cap on the bandwidth? That's not a traffic shaper. A traffic shaper should give you the ability to prioritize ACKs and other important traffic. (ON THE OUTBOUND!!!!!!111one!!!)
 
Phunball is correct. You DO NOT HAVE CONTROL OVER YOUR INBOUND CONNECTION!

Everyone in this thread has told you, but you continue to argue that you can control it. You can't. You have no control over what hits your cable modem. None whatsoever. That's great if you set an inbound cap on your WAN>LAN bandwidth, but that has nothing to do with what's hitting the cable modem.

I could cap my connection at 100k but that doesn't stop data from coming in at 5mbps to my cable modem. It just means my firewall/router is essentially dropping all the excess packets. Which ones does it drop? Who knows. This is essentially what happens on your cable modem as well.

You have a cap at the CO of 10mbps. But 15 mbps of traffic is trying to reach you. Do you think that comcast will let YOU decide which ones it sends you? No, of course not, that's absurd. So what happens with that other 5mbps of traffic that isn't hitting your modem you ask? Well, comcast is dropping it, or qeueing it. Hence, the 1.5 second ping times. Since you have more traffic headed for you than your line supports, comcast just decides what you should or shouldn't receive.

And I'm starting to doubt your traffic shaper's abilities or how you have it set up. You only put a cap on the bandwidth? That's not a traffic shaper. A traffic shaper should give you the ability to prioritize ACKs and other important traffic. (ON THE OUTBOUND!!!!!!111one!!!)

TCP is throttleable by using sliding windows. It won't effect unrequested incoming traffic (e.g. DoS), but is workable for established connections. That's part of the C in Transmission Control Protocol.
 
TCP is throttleable by using sliding windows. It won't effect unrequested incoming traffic (e.g. DoS), but is workable for established connections. That's part of the C in Transmission Control Protocol.

That would be great if no one still used UDP.
 
Right, but the OP is talking primarily about torrents crowding out everything else. Bittorrent is a TCP based protocol.

But he's complaining about ping times. Ping uses ICMP, which is even less complex than UDP.

So, it's pretty relevant to the problem he's having.

And with torrents, when people connect to a tracker, and your IP is listed as a peer/seed, the new client will try to negotiate a connection to the peer. With him seeding 150+ torrents...and only downloading two, it would seem that alot of people will be requesting connections from him. Those connections won't be able to negotiate a friendly speed until after they have been connected and realize that packets are being lost. That's how TCP works. It's rate adaptive not rate controlled.

Regardless of the underlying technologies, I still fail to see an issue here. Ping times go up when you torrent.
 
Phunball is correct. You DO NOT HAVE CONTROL OVER YOUR INBOUND CONNECTION!

Everyone in this thread has told you, but you continue to argue that you can control it. You can't. You have no control over what hits your cable modem. None whatsoever. That's great if you set an inbound cap on your WAN>LAN bandwidth, but that has nothing to do with what's hitting the cable modem.

I could cap my connection at 100k but that doesn't stop data from coming in at 5mbps to my cable modem. It just means my firewall/router is essentially dropping all the excess packets. Which ones does it drop? Who knows. This is essentially what happens on your cable modem as well.

Except that:

comcast2.JPG


For the vision impaired, allow me to narrate: What you see here is my incoming bandwidth being fully saturated by a torrent, yet because the traffic shaper is enabled on the INCOMING TRAFFIC, my ping times remain in the 20’s. Do you think the screenshot is fake? Do you doubt that this is actually happening?

And I'm starting to doubt your traffic shaper's abilities or how you have it set up. You only put a cap on the bandwidth? That's not a traffic shaper. A traffic shaper should give you the ability to prioritize ACKs and other important traffic. (ON THE OUTBOUND!!!!!!111one!!!)

I suppose I’ll humor you:

shaper.JPG


That is the page where I setup the pipes for incoming and outgoing traffic. The download pipe is set at 100000 as that is just the value I throw in when I essentially want traffic shaping disabled on the download. The normal value I usually have in here is 7920, which represents 90% of the Comcast cap and gives it room to work with the traffic it receives; though I can set it at 8800 if I just want to prevent the Comcast caps from kicking in.

shaper3.JPG


Here is where I setup the various prioritization queues, for both outgoing AND incoming traffic.

shaper2.JPG

shaper4.JPG



This is what the rules page looks like. The list of rules is pretty long, with stuff like bittorrent traffic taking the lower priority queues and my games with the higher priority queues. Works great, especially for my vonage phone which had issues when I would torrent but worked flawlessly after I setup the rules.
 
But he's complaining about ping times. Ping uses ICMP, which is even less complex than UDP.

So, it's pretty relevant to the problem he's having.

And with torrents, when people connect to a tracker, and your IP is listed as a peer/seed, the new client will try to negotiate a connection to the peer. With him seeding 150+ torrents...and only downloading two, it would seem that alot of people will be requesting connections from him. Those connections won't be able to negotiate a friendly speed until after they have been connected and realize that packets are being lost. That's how TCP works. It's rate adaptive not rate controlled.

Regardless of the underlying technologies, I still fail to see an issue here. Ping times go up when you torrent.

Ping times were secondary / for testing/metric purposes only (albeit flawed) - he noticed slow HTTP browsing (TCP) first. A lot of people will be requesting connections - but how long is it really going to take for each one to throttle down? I don't think he's necessarily complaining that torrenting is slowing his connection and looking for a solution - he's already found one. He's curious as to why it was fine w/o shaping/capping on his end and now it isn't - going beyond just finding a way to fix it, but understanding the reasons/how/why it works. It's most likely a change on comcast's end - I think the real reason for posting was to find out if anyone knew or could speculate as to what that change could be.
 
Ping times were secondary / for testing/metric purposes only (albeit flawed) - he noticed slow HTTP browsing (TCP) first. A lot of people will be requesting connections - but how long is it really going to take for each one to throttle down? I don't think he's necessarily complaining that torrenting is slowing his connection and looking for a solution - he's already found one. He's curious as to why it was fine w/o shaping/capping on his end and now it isn't - going beyond just finding a way to fix it, but understanding the reasons/how/why it works. It's most likely a change on comcast's end - I think the real reason for posting was to find out if anyone knew or could speculate as to what that change could be.

Thank you GOD, I had lost all hope. :)
 
Well, have fun with your incoming traffic shaping. I'm sure soon you'll have two WANs from two different ISPs and do inbound load balancing on them without BGP or an AS#.


Perhaps you should spend some more time on the monowall forum instead of HardOCP, and see what the folks there have to say about inbound traffic shaping.
 
Perhaps you should spend some more time on the monowall forum instead of HardOCP, and see what the folks there have to say about inbound traffic shaping.

Except that the purpose of this thread was a question about Comcast, lol…
 
Except that the purpose of this thread was a question about Comcast, lol…

I was suggesting that if you intend to use a feature of a product, that you should probably visit that particular products website/wiki to learn more about that feature than a general comptuer forum like H can teach you.

Oh, and BTW, the first thing that you should realize is that a CAP of your actual line speed is a bad idea. You should set it at 80-85%. And your incoming connection isn't 100 megabit. They aren't referring to the physical link speed between your fw and your LAN.

So really, go visit the monowall forum.
 
Oh, and BTW, the first thing that you should realize is that a CAP of your actual line speed is a bad idea. You should set it at 80-85%. And your incoming connection isn't 100 megabit. They aren't referring to the physical link speed between your fw and your LAN.

No shit. I gave my reasoning for setting it to that value right below that particular screen shot (reading comprehension, it’s a valuable skill).

That is the page where I setup the pipes for incoming and outgoing traffic. The download pipe is set at 100000 as that is just the value I throw in when I essentially want traffic shaping disabled on the download. The normal value I usually have in here is 7920, which represents 90% of the Comcast cap and gives it room to work with the traffic it receives; though I can set it at 8800 if I just want to prevent the Comcast caps from kicking in.

Really, what the traffic shaper is doing or isn’t doing is irrelevant, it serves the purpose I need it to serve, which is to prevent the caps on Comcast’s end from kicking in; and it still accomplishes that even with the pipe value set at 100%, because from what I’ve been able to tell the caps only engage if you burst above the cap value for a specific period of time. They changed something in regards to how they implement their bandwidth caps that is having an adverse affect on ping, etc above and beyond what can be explained simply by downstream bandwidth saturation (at least, compared to how it was before). This is what I’m trying to find more information about.

Slightly offtopic:

http://digg.com/tech_news/Comcast_admits_bandwidth_cap_200_GB_month_and_is_a_moving_target

Check out some of the comments there. Comcast does occasionally give people 1 year bans for excessive downloads.

(I'm not sure if you are d/ling @ 8+Mbps 24/7/365 since that would add up to ~2,590 GB per month)

I only download about ~50 gigs a month or so. The only reason I have so many things seeding is because they are from private trackers where it’s in my best interest to maintain a good ratio, but only a few of the ~150 or so that I’m seeding are usually uploading at any given time, and often times only at like 5-20K.
 
You also may have better luck at broadbandreports - they're more on top of changes in isp networks.
 
Back
Top