Upload Speed Issue - Comcast

[nanobot]

Ah, then it would make sense that all those aggregates only added up to 21Mbps, but the single file at 500KiB/s is still really slow.

No chance it's a Hard Drive speed issue is there?

Thanks,

EBrown

[ERIC8585]

Nope it's a SSD. Have the same upload issue on my wired gigabit desktop Windows machines too.

[nanobot]

That's pretty bad, there's definitely some funk going on there.

Thanks,

EBrown

[ERIC8585]

That's pretty bad, there's definitely some funk going on there.

Thanks,

EBrown

Here we go again! At 2pm after 16 hours it's fine again.... until 10pm

[nanobot]

That's really bad. Definitely a Comcast thing.

 

Thanks,

EBrown

[jimharle]

Just to throw it out there, this could be the result of packet loss somewhere along the path vs. throttling on Comcast's part. That's one way to explain the limited single threads but still "normal" in the aggregate.

[nanobot]

If it were packet loss it would not be so symmetrical. I mean, when you look at those results it's extremely predictable and completely symmetric.

Thanks,

EBrown

[jimharle]

If it were packet loss it would not be so symmetrical. I mean, when you look at those results it's extremely predictable and completely symmetric.

Thanks,

EBrown

 

Perhaps, but the default view of the FileZilla client is to show the average throughput for each stream - I always set it to show the "momentary" speed instead of the average speed (look at the "Interface" section under Settings). Additionally, it's possible that packet loss due to a congested route could be "symmetrical."  All I'm really trying to say is that it's not a forgone conclusion that Comcast is shaping.

 

Another approach to take, is to compare results from different ISPs to the same endpoints, during the troubles on the one.  Isn't there also a "pingpath" test that Damon offers?

[nanobot]

Even so, his streams so 333KiB/s down in the first 1%, that's not a very good speed, really.

Thanks,

EBrown

[ERIC8585]

Comcast still hasn't fixed the issue...

[ERIC8585]

Isn't my upstream power level low when I remove the -10db attenuator?

[nanobot]

Doesn't really seem low to me. Mine's 50dBmV.

The downstream power looks a bit low though. Are you a large distance from the last mile device?

Thanks,

EBrown

[ERIC8585]

The downstream is high at +10. the upstream power is 38 which is lower than yours.

[nanobot]

Huh, guess you're right. Yeah, the Downstream is wayyyy higher than mine. With a downstream that high I would think there wouldn't be a lot of attenuation in your upstream signal, but there very well could be.

Thanks,

EBrown

[CA3LE]

I don't know if you're being throttled.  Personally, I don't think so.

 

If they were going to shape your bandwidth during a specific time... I think they'd do it during peak hours.

 

You have something that's happening on a regularity that you could bet money on... right?  So 10-11 tonight it WILL happen and last until 1-2 PM tomorrow?

 

Have you tested with the modem directly connected to your PC?  Have you had a chance to test other computers and they return the same result?

[ERIC8585]

Yeah it was happening every day between ~11pm and ~2pm the next day.  However, the past few days the timing has not been consistent.  For example, this past Tuesday and Wednesday i was having the issue at least the whole day and it was still happening when I went to sleep at around 10 or 11.

 

I've tried connecting the modem directly to the computer and I've tried multiple computers.  It didn't make any difference.  I also replaced the cable modem and have had around 4 techs look at the tap outside, and replace coax connectors & the splitter.  They also claimed to have removed some Uverse connection down the street that might have been causing noise.  Lately they're trying to place the blame on the other networks that I'm connecting to.

 

The strange thing is that my tests to speedtest.net and the "comcast speedtest" don't really change. I'm assuming those are multithreaded tests? However, my test to San Jose on testmy.net and all my upstream transfers to various networks (e.g. youtube, SFTP client at work (both with and without a VPN established to my home server)) show the drop off for individual connections. ShaperProbe also returns a messages saying the upstream test was aborted due to high packet loss during the time period when I'm having the issue.

 

I also noticed that the speedtest.net app on my iphone does show the upstream drop off so maybe that app is not running a multithreaded test?

 

Here's some more screenshots. There's a youtube test during the issue and one when I'm not having a problem. Also the shaperprobe screenshot.

[jimharle]

Eric, have you tried a pingpath test, both when the problem is occurring and when it is not?

 

Another way to validate that packet loss is occurring, is to run a Wireshark packet capture during both times (filtering for a specific endpoint to remove noise), and using the Analyze --> Expert Info feature of Wireshark to look at the number of retransmissions.

 

We have known packet loss at our office, and we have compared the same transfer from the same endpoint from a "known good" ISP (which, ironically, is Comcast for this), and here are the results:

 

Office:

 

 

Comcast:

 

 

See the difference?

[ERIC8585]

I haven't tried the pingpath test yet. I didn't notice any difference with tracert.  I was thinking about trying Wireshark but I've just been too lazy to try that I guess.  Let me try both those things and let you know...

 

Thanks

[ERIC8585]

I haven't used wireshark in a long time so I'm not sure what I'm doing.  Here's a screenshot of the expert screen while I'm uploading to YouTube.

[nanobot]

Those duplicate ACK messages could be problematic.

Thanks,

EBrown

[jimharle]

Yes, and a lot of retransmissions. Is this during the problem time?

[ERIC8585]

Yes that was during problem time.  Here is the same file being uploaded a couple minutes ago during "non problem time."  I let it run until 3% instead of 2% like the initial test.

[nanobot]

Yeah there is a much smaller number of Duplicate ACK messages.

That would be your issue there.

Thanks,

EBrown

[jimharle]

So if I were in your shoes, I would want to demonstrate to Comcast where the packet loss is occurring. Firstly I would identify several static endpoints to test with, and ones where they are not part of a pool of possibilities (in other words, when uploading to YouTube, I'm not sure that you're hitting the same endpoint(s) every time you do an upload - I would include endpoints that don't change such as FTP servers).

 

I would then gather the packet captures for the multiple endpoints (during the problem window), to show that the packet loss is not specific to one endpoint (which they could argue might be part of the problem).

 

Next I would take my laptop (always testing with the same computer rules out issues on it) to my in-laws' house (who live in a different suburb but still have Comcast) and do the same packet captures from there. Assuming no problems from there, I would submit the information, along with traceroutes, to Comcast to show that the problem is always at your house, and doesn't follow your laptop or other locations you test from.

 

When we were narrowing down the problem in our office, I had the advantage of being able to run packet captures on the remote end (an FTP server) at the same time as the client side, to show there were not [excessive] packet loss issues with different client locations, and that our office was demonstrably different than another endpoint using the same ISP where the traceroute differed in only the last couple of hops (the "last mile" of our connection).

 

Does this make sense?

[ERIC8585]

I sent them screenshots of a transfer from my SFTP server at home to a client on my corporate network at work showing the issue as well.  I guess I can do the same with wireshark. I feel like I'm being forced to do their job because they're incompetent.