Skip to content
QSSTPRO's profile

Visitor

 • 

4 Messages

Thursday, January 16th, 2014 8:00 AM

Odd bandwidth limit encountered

We've encountered what appears to be some sort of hard limit where we can't sustain more than 1.5 mbps transfer in either direction.

 

When using any of the Ookla based speed tests it appears that we have the advertised speeds, but when using non-Ookla speed tests, we experience totally different numbers.

 

But, regardless of the line speed test results, the maximum transfer that can be sustained is 1.5 mbps measured using a variety of methods.  I've even tested this by running multiple processes that normally run at various transfer rates and they will each only be able to take a portion of 1.5 mbps, rather than combining (for example, if one is running at 1.5 mbps and I start a second, the first will reduce to say 900 kbps, and the second will use 600 kbps; then when the first is stopped the second will move up to 1.5 mbps.)

 

We first noticed this trend by monitoring transfer rates using SNMP data polled with MRTG.  We spent some time thinking it was the hardware and our own traffic shaping for VOiP related QoS might have been the culprit but we eliminated that by hooking another router behind the Comcast device and experiencing the same exact results with a router from another manufacturer with nothing but a basic configuration.

 

This was first noticed after we implemented some regularly occurring large file transfers to an offsite location for Data Protection Manager (which is also a Comcast Cable connection.)  It seemed that we were previously running rather effecient initially, then after a while it just seemed we no longer saw our graphs with period of heavy spikes but rather with everything with a hard cap of 1.5 mbps which is way less than the 50/20 mbps that we are paying for.

 

I know I keep seeing messages that say "we don't 'throttle' we 'manage'", well, we definitely have the perception that we are being 'managed' and this is really frustrating.

 

Thanks in advance!  I can provide additional information if desired.

 

Sample MRTG graph showing the hard cap encountered...

1.5 mbps hard cap

Accepted Solution

Visitor

 • 

4 Messages

11 years ago

We had a tech work with the modem remotely and also had a tech dispatched who initially stated that unfortunately he couldn't find any problems.  When pressed (after I saw the power levels had changed in the gateway's interface), he admitted he had increased power levels.  He kept using the Ookla speedtest results as if the were the end all be all in the Comcast world. 

 

I've come to the conclusion that what was perceived as a "cap" was esentially the ceiling for non-burst (or prioritized) data.  I had been speaking in kBps, but it is probably more digestable as mbps so I modified my router graphing and came up with the following image:

 

Comcast 24 hr graph

 

You can see we don't really make it above 12.8 mbps with sustained data usage.  *But* what I am noticing (and touched on before) is that the Ookla based speed tests all show miraculous numbers where other speed tests do not.  With a finer graphing I can see them spike well above the normal perceived cap.

 

So, it seems that we're getting about 20% of my advertised (and paid for) speed on a regular basis, but in Comcast's eyes we have no issues because they can do a speed test and get a temporary burst of our advertised speed so all is well.  For as much as we pay for this, I'm wondering if we reduced to a lower advertised speed if we'd have our true sustained transfer rate drop, or if we would just lose our maximum burstable amount.  I could care less about speed tests, I just want to move bits at the rate I pay for.

 

On another note, the remote tech was concerned at the uptime of our modem (82 days, which to me didn't seem a whole lot.)  He said it should be power cyvled every thirty days.  Not terribly impressive.  We will be adding it to a remote-power device that will power cycle as specicied (every month at an off time, 30 seconds off, then back on.)  This will mess up sync jobs and people accessint remotely from the other side of the world, but if they claim it helps, we'll try it.

 

Anyway, thanks for the consideration and assistance!

Problem solver

 • 

305 Messages

11 years ago

I imagine this recently started, or has it been going on for some time? Have you contacted Comcast about this? 

 

Also, what do your modem stats look like? Down stream/upstream power level, SNR? 

 

 

Visitor

 • 

4 Messages

11 years ago

It started shortly after we started doing the offsite syncs.  Here are the modem stats:

 

Downstream Channel

Downstream Frequency578.998047 MHz584.999268 MHz597.001831 MHz602.998535 MHz
Lock StatusLockedLockedLockedLocked
Modulation256 QAM256 QAM256 QAM256 QAM
Symbol Rate5.360537Msym/sec5.360537Msym/sec5.360537Msym/sec5.360537Msym/sec
Downstream Power-7.930452 dBmV-7.799046 dBmV-8.187001 dBmV-8.142974 dBmV
SNR36.844463 dB37.092701 dB37.092701 dB37.355988 dB

Upstream Channel

Upstream Frequency30600150 Hz25300036 Hz36999974 Hz
Lock StatusLockedLockedLocked
Modulation64QAM64QAM64QAM
Symbol Rate5120 KSym/sec2560 KSym/sec5120 KSym/sec
Upstream Power43.7500 dBmV42.0000 dBmV45.5000 dBmV
Channel ID111012

Problem solver

 • 

305 Messages

11 years ago

Your Downstream Power level seems to be a bit low in my opinion. Your upstream level appears low as well. While both are within acceptable ranges it is possible you could be seeing some issues due to that. 

 

Do you have any splitters before the modem? If so, try removing that from the equation to see if that helps. I'd conact Comcast and see what they say. May ask them to "roll" or "reprovision" your modem.  

Visitor

 • 

4 Messages

11 years ago

Thanks.  I'll have the onsight folks check things and then get ahold of Comcast.

Visitor

 • 

3 Messages

11 years ago

We have a very similar situation with almost exactly the same results from troubleshooting with the Comcast technician. 

 

He at first replaced the modem, but the issue continued, with him scratching his head on the speed tests vs reviewing the data we recorded during one of the (almost daily) events.  Ours seems to occur during evening hours (7-10PM PST) during data back-ups (from remote location to us) and downstream transfer (some of it streaming) of videos for training reviews. 

 

Low end of transfer rates you mention are very typical of what we are seeing during this daily time period,  We've moved back-up traffic to later in the evening, but are still encountering the restrictions during “prime time” evening hours.