Internet routing / Network /ethereal guru needed

[D'Ecosse]

I apologize in advance - this will have no interest for many & it's a very lengthy post, but maybe someone can help - I have great confidence in the diversity of knowledge on this forum & that there is some expertise who can help.

I am generally pleased with the speed of my Comcast connection here in East Bay Area CA. I measure the advertised 4096 kbps - pretty good (& consistent)

But I have problems however receiving adequate bandwidth from a specific site in the UK from which I receive streaming soccer video through a subscription service. (No ...it's not porn!)

Here's the dilemma - I can use the exact same hardware configuration (i.e. my laptop) and go 1/4 mile down the street to the nearest Starbucks & get a perfect transmission received at full speed (~500K)with no stalling or buffering. Therefor there is no problem with the source having inadequate output. (I've repeated this test several times & get consistent results)

i.e. Same hardware & local settings -> Same target (but reached through different ISP);
One works flawlessly, the other doesn't (has ~50% loss of bandwidth from source media)
Therefor problem must between source & target, right?

But .... If I do a ping & trace route from each location I actually get WORSE latency results from the one that gives me flawless bandwidth transmission (i.e. The Starbucks T mobile connection has worse pings but no bandwidth issue) - I'll post the results below.

When I try to explain the situation to Comcast, it's most frustrating - they either say there's nothing wrong with my ping (which is reasonable) or that there is a problem at step "x" and that is off their network therefor not their problem. When I try to reply there is a response from a different "tech support" agent each time & they never read all the previous details that show it clearly isn't a source or a local equipment/hardware issue. They appear to be answering from pre-scripted "idiot guides" rather than seriously analyzing the issue.

But clearly I have the problem with my Comcast connection, yet not with an alternative (I also get similar good results from my work connection); on my home Comcast connection, it makes no difference whether I use my laptop or home pc; whether connected through the router, or directly to the cable modem, it is unchanged.

How can I diagnose the source of the problem, where it is choking bandwidth, yet the pings appear to be adequate???

Any assistance/suggestions will be most appreciated.

The Starbucks/T-Mobile route - delivers perfect bandwidth at required speed:


Now the Comcast connection suffers quite a loss in bandwidth ~ 1/2 of the required 500kbps

edit: removed the pings & tracert's as found the target media was hosted off the primary site. The problem statement is still accurate & the tracert to actual target is in subsequenst posts below

So maybe I'm getting some packet loss in the TCP handshake?

I downloaded Ethereal so maybe a guru intimate with that can analyze below for me? (I can also forward the entire capture by e-mail if that is helpful?) I've extracted some areas that look like problems ....

(click-able link to full-size picture)


Here is an image of the windows media statistics -

.

 

[NSX-Racer]

Just to sort one problem out: Did you try the same connection with your laptop connected via Ethernet to your router/DSL modem (IP 192.168.1.1) or only wireless? As you have seen pings alone don't show the whole truth.

BTW: Do you really know that Starbucks has the same hardware than you (rx/tx, router, modem)?

 

[D'Ecosse]

Just to sort one problem out: Did you try the same connection with your laptop connected via Ethernet to your router/DSL modem (IP 192.168.1.1) or only wireless? As you have seen pings alone don't show the whole truth.

BTW: Do you really know that Starbucks has the same hardware than you (rx/tx, router, modem)?

Thanks for quick reply -

When I say same hardware, I mean that I am using MY same hardware i.e. the same laptop, so rules out hardware/software variabilities; yes, also I have eliminated my own router from the equation by connecting directly to the modem, with the same results.

I think one thing I have realized from my own inspection of the ethereal log is I see that the contact is to 213.19.180.88 - that is servcast.com - I believe that provides the host service for the parent site; therefor I believe the above-posted routes are incorrect and the connection would go directly to 213.19.180.88 rather than 82.112.114.114

New trace still shows OK latency however so still suspecting packet loss

Tracing route to 213.19.180.88 over a maximum of 30 hops

1 3 ms 1 ms 1 ms 192.168.1.1
2 11 ms 11 ms 10 ms 10.145.96.1
3 13 ms 12 ms 10 ms 12.244.97.161
4 11 ms 11 ms 11 ms 12.244.67.78
5 11 ms 13 ms 13 ms 12.244.67.82
6 14 ms 12 ms 11 ms 12.127.32.65
7 12 ms 11 ms 12 ms tbr1-p012301.sffca.ip.att.net [12.123.13.173]
8 13 ms 11 ms 12 ms ggr2-p300.sffca.ip.att.net [12.123.13.190]
9 14 ms 12 ms 13 ms so-8-1.car3.SanJose1.Level3.net [209.0.227.29]
10 14 ms 16 ms 14 ms ae-1-55.bbr1.SanJose1.Level3.net [4.68.123.129]
11 156 ms 153 ms 154 ms as-0-0.mp2.Amsterdam1.Level3.net [212.187.128.13]
12 154 ms 154 ms 153 ms ge-7-0.ipcolo1.Amsterdam1.Level3.net [213.244.165.7]
13 155 ms 157 ms 156 ms 213.19.180.88

Trace complete.

 

[NsXMas]

I wonder if Comcast has a proxy server / firewall that reduces the flow due to hardware limitations, inspection routines, or other processes/traffic that puts additional load on their network.

 

[2slow2speed]

Hi Ken,

FYI, Having low latencies that are recorded by the icmp echo request and replies does not directly imply that you will have low latencies for the streaming video.

ping and traceroute both make use of ICMP, the streaming video might be using some other protocol that runs over IP such as UDP, RTP and others, as such the path that is taken by a ICMP packet might not be the same as the one for UDP/RTP etc if some kind of load balancing is done based on the network layer protocol field source destination port numbers, etc, etc. In other words packets that are bound to the same destination might take different paths through the network.

It is also possible that packets might be arriving out of order as well, due to the different ways that load balancing is done.

You also have to remember that for the most part IP is best effort for the consumer market unless you have some kind of SLA (Service Level Agreement) for premium services. Cable in general is a shared media, as such there are no guarantees on the amount of BW that is readily available at a given time. One of your neighbors down the road might be running some kind of p2p application and using up a lot of the BW, it's a very hard thing to try to limit these applications because in general they change port numbers all the time on a per session bassis.

There are many other possibilities of why you are having problems with the connection. It's a real pain to diagnose bottlenecks by just using ping, traceroute, etc, etc.

Those are only used to determine wether or not a particular destination is reachable and via what route for a particular ICMP packet. I wish that I could give you better ideas on how to diagnose your problems, but I don't really have any right from the top of my head

Ken

 

[2slow2speed]

FYI,

You could try netstat and try to parse through the output, and see if that gives you any other hints.

Ken

 

[D'Ecosse]

.... I wish that I could give you better ideas on how to diagnose your problems, but I don't really have any right from the top of my head
Ken

Thanks for reply Ken - nice to have a knowledgable person understand the issue. As you say, it's not simple to diagnose & the problem is that there is no-one knowledgable when I try to speak to Comcast about it - all they do is test for latency (ping & tracert) & say it's fine. I'm no expert but I'm convinced I know more than the morons that just refer to a canned idot-guide & cut n paste responses.
The problem is that it only appears to be to this one site - if I do a speed test to Megapath I get 4Mbps so don't think a neighbour is hogging my bandwidth. (Incidentally it doesn't get any better regardless of time of day & is consistently bad)
On the media protocol, it does say it's TCP not UDP - I'm not at all intimate with the ethereal analysis, but isn't it failing to handshake on the TCP and thus having to retransmit?

...You could try netstat and try to parse through the output, and see if that gives you any other hints.

How does that work? Another program?

 

[NsXMas]

run>cmd > netstat

 

[Tom239]

Does the video stream ever work OK at home, or is it always problematic?

Is there an indication to confirm that you are experiencing packet loss between you and the server? The traceroutes and pings you posted show no packet loss; do they ever show some? Did you try running traceroute and/or ping at the same time you're running windows media player (without good results)? If the problem is IP packet loss, there may not be much you can do except wait for overloaded links (quite possibly outside of Comcast) to get upgraded.

A word about traceroute--
it lists the machines that forward your packets to the remote host; it doesn't show you the route in the other direction (outbound and inbound packets may take different routes).

Does your version of windows media player allow you to specify which protocol type(s) to use? Can you try UDP instead of TCP? Can you increase the buffer size? (I'm not experienced in troubleshooting windows media problems, I'm just suggesting some experiments.)

Does the content provider offer any tips or support?

 

[Malibu Rapper]

Have you tried explaining the problem to the subscription site? Maybe they have some ideas on how to better test this? Perhaps they have dealt with this issue before. Maybe you can find someone else with a Comcast connection and have them try it?

What would be interesting is to do a very basic FTP test to the provider, if they have a site where you can download something and upload something to see if the bandwith is good.

Not knowing how they stream their media, it could be latency, packet loss, even a blocked out port(s)(which ISPs have been known to do). Sounds like bandwith is not the issue. What format are they streaming in?

 

[2slow2speed]

Thanks for reply Ken - nice to have a knowledgable person understand the issue. As you say, it's not simple to diagnose & the problem is that there is no-one knowledgable when I try to speak to Comcast about it - all they do is test for latency (ping & tracert) & say it's fine. I'm no expert but I'm convinced I know more than the morons that just refer to a canned idot-guide & cut n paste responses.
The problem is that it only appears to be to this one site - if I do a speed test to Megapath I get 4Mbps so don't think a neighbour is hogging my bandwidth. (Incidentally it doesn't get any better regardless of time of day & is consistently bad)
On the media protocol, it does say it's TCP not UDP - I'm not at all intimate with the ethereal analysis, but isn't it failing to handshake on the TCP and thus having to retransmit?


How does that work? Another program?

TCP is reliable so even if there is packet loss it should be able to handle it properly (same thing with reordering of packets as well). TCP is also adaptive and over time it increases it's transmit window size until it starts to experience packet loss, at that point it goes back down in size and tries again.

FYI, By default ping uses a small ICMP packet, you might want to specify a packet size of about 1400 bytes and see how that goes, sometimes there are scenarios where the smaller packet goes through and the larger packet experiences packet loss. Depending on the OS that you are using the option to specifcy the size might be different, just type ping and it should show the options that are available for the command.

In addition many of the ISP backbones actually use MPLS instead of native IP to carry the traffic, so there might be some problems with the way that the Maximum Transmition Unit (MTU) has been configured, so at least being able to ping with a larger sized packet might help diagnose the problem.

Most ISP backbones are either based on SONET or Ethernet (maybe some of them are still using ATM but I can't really recall) as such an IP packet with a MTU of 1500 bytes should not experience IP fragmentation along the way.
(You can double check this by setting the don't fragment flag in the ping command and see if you can determine if there are problems when the don't fragment flag is being set).

Since you mentioned that the application is using TCP, you can issue the netstat command and see the protocol statistics for TCP, and see if errors are being reported. (BTW: Having an idea of the OS that you are using would help too)

There are programs like ttcp that can be used to test TCP performance but it requires that both ends run the program in order to be able to measure the relative performance.

BTW: I just noticed that you had some ethereal screenshots enclosed, it seems that you have packet loss every once in a while, the packet size being used by the application seems to be fairly large as such the ping of packet size 1400 might show the problem. Just do a continuous ping with a large packet size and see what the rate of packet loss is.

I used to work on this stuff so I should know it by heart, but I think that I've chosen to forget quite a bit of it, pretty bad for a so called *expert in the field*, LOL

 

[paladin]

The main problem i see, is that even once you're able to pinpoint the problem, it is likely on comcast's end, and they're unlikely to be able to help you.
If you can try to get the number or extension of a higher-tier tech, then if you show them some data they might be able to tell you a little bit about their network setup.
I'm inclined to think its a problem with them closing off ports

 

[2slow2speed]

The main problem i see, is that even once you're able to pinpoint the problem, it is likely on comcast's end, and they're unlikely to be able to help you.
If you can try to get the number or extension of a higher-tier tech, then if you show them some data they might be able to tell you a little bit about their network setup.
I'm inclined to think its a problem with them closing off ports

FYI,

Based on the ethereal output it is not that they are closing ports, there is packet loss that is happening in the network and there is some retransmition that is happening at the TCP level. I doubt that Comcast has the ability to close ports dynamically on a per session bassis (given what I know about their network and the equipment that they run in it currently (unless my info is outdated)).

Most of the SF Bay Area Comcast network was inherited from AT&T Broadband, and most of that was based out of Cisco 12K or 7500's, and either 7500 or 7200 acting like CMTS's, as such I would not be too surprised if they are having performance issues given the large number of subscribers.

In general using ping/traceroute to determine network performance is useless given that most routers have rate limiters configured/set to prevent Denial of Service Attacks via ICMP echos or replies, so packet loss via pings might not indicate an actual packet loss in the network, the intermediate routers might just be limiting the amount of traffic. In addition handling of the ICMP echo request/reply happens in the slow path, and forwarding of transit traffic that traverses the router is handled in the fast path, so what seems to be packet loss in one does not directly correlate to loss in another.

Just to make things clear ping/traceroute only provides reachability checks that tells that the user that the destination is reachable via *some* route and nothing more nothing less, sometimes it's useful for checking MTU settings on a given route, but that can be confusing as well under some circumstances.

That is what makes trying to diagnose performance problems so hard in networks, if you can narrow it down to the router in question that is having problems and then down to the link that is having problems, then it might be possible to determine if the packet loss is happening because the link is having errors in the physical layer, data link layer or the network layer. But in some cases it might just be that the router is either running out of cycles to forward packets (both in SW based forwarding or HW based forwarding) or that the link is simply congested and some kind of QOS/COS policy is being applied to drop packets. Some routers make use of RED (Random Early Discard) to discard TCP packets with a higher probability when experiencing congestion to force the TCP window to shrink on the sender which in turn tells the sender that congestion was experienced, this in general should result in higher TCP peformance under congestion, but that's not the case 100% of the time.

If it would be possible to tinker with the TCP configuration, one way to get around this problem might be to just set the MSS (Maximum Segment Size) for the TCP session to be lower than the default, then again I'm not really sure how that is done for some OS's or wether or not that is even doable for some TCP stack implementations.

There are many other things that ISPs do in order to prevent non profit generating traffic from eating up the BW in their networks, they might reclassify the traffic that is comming from non-paying non-premium sites to have a lower quality/class of service and thus resulting in a higher probabilty of packet loss, etc, etc.

Anyways, most of the stuff that I wrote probably does not make sense to 99.9% of the folks who read it, so I'll just leave it at that.

I should just go back to the "selective amnesia" mode again

Ken

 

[D'Ecosse]

Some good suggestions here.
More data -
I'm running XP Pro SP2 on my home system & Windows 2000 Pro on my laptop; both have the same issue and the laptop is obviously common to both the good results (from T-mobile) or my Comcast. Not quite sure what my laptop MTU is - I haven't messed with that - but my home system is 1500 with a large RWin of 46200. It;s not really as simple as running a longer buffer - it would have to be significantly large to eliminate the issue.

I'm not having much luck getting any help from the host - I've explained the situation & even asked them if they host their media at different locations, as I have managed to identify a couple of specific files that play problem free. I dicovered only through the ethereal capture that the media was actually coming form servecast.com as opposed to driectly off their own IP address
The response unfortunately is just "we're fine, problem with your ISP" which is not unreasonable since I have proved they are OK when connecting to them from another ISP. However, as you say, a little help would be appreciated. Oddly enough "Live" match day events are flawless & I though they might be able to give me some clues as to the difference in format or source of this media vs their recorded streams.

Pings never show a problem - here's 35 at 1400

C:\>ping -n 35 -l 1400 -f 213.19.180.88

Pinging 213.19.180.88 with 1400 bytes of data:

Reply from 213.19.180.88: bytes=1400 time=159ms TTL=113
Reply from 213.19.180.88: bytes=1400 time=159ms TTL=113
Reply from 213.19.180.88: bytes=1400 time=159ms TTL=113
Reply from 213.19.180.88: bytes=1400 time=159ms TTL=113
Reply from 213.19.180.88: bytes=1400 time=159ms TTL=113
Reply from 213.19.180.88: bytes=1400 time=165ms TTL=113
Reply from 213.19.180.88: bytes=1400 time=159ms TTL=113
Reply from 213.19.180.88: bytes=1400 time=160ms TTL=113
Reply from 213.19.180.88: bytes=1400 time=160ms TTL=113
Reply from 213.19.180.88: bytes=1400 time=159ms TTL=113
Reply from 213.19.180.88: bytes=1400 time=160ms TTL=113
Reply from 213.19.180.88: bytes=1400 time=159ms TTL=113
Reply from 213.19.180.88: bytes=1400 time=162ms TTL=113
Reply from 213.19.180.88: bytes=1400 time=159ms TTL=113
Reply from 213.19.180.88: bytes=1400 time=160ms TTL=113
Reply from 213.19.180.88: bytes=1400 time=160ms TTL=113
Reply from 213.19.180.88: bytes=1400 time=159ms TTL=113
Reply from 213.19.180.88: bytes=1400 time=160ms TTL=113
Reply from 213.19.180.88: bytes=1400 time=161ms TTL=113
Reply from 213.19.180.88: bytes=1400 time=160ms TTL=113
Reply from 213.19.180.88: bytes=1400 time=162ms TTL=113
Reply from 213.19.180.88: bytes=1400 time=160ms TTL=113
Reply from 213.19.180.88: bytes=1400 time=159ms TTL=113
Reply from 213.19.180.88: bytes=1400 time=159ms TTL=113
Reply from 213.19.180.88: bytes=1400 time=159ms TTL=113
Reply from 213.19.180.88: bytes=1400 time=160ms TTL=113
Reply from 213.19.180.88: bytes=1400 time=158ms TTL=113
Reply from 213.19.180.88: bytes=1400 time=158ms TTL=113
Reply from 213.19.180.88: bytes=1400 time=160ms TTL=113
Reply from 213.19.180.88: bytes=1400 time=159ms TTL=113
Reply from 213.19.180.88: bytes=1400 time=160ms TTL=113
Reply from 213.19.180.88: bytes=1400 time=161ms TTL=113
Reply from 213.19.180.88: bytes=1400 time=159ms TTL=113
Reply from 213.19.180.88: bytes=1400 time=159ms TTL=113
Reply from 213.19.180.88: bytes=1400 time=159ms TTL=113

Ping statistics for 213.19.180.88:
Packets: Sent = 35, Received = 35, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 158ms, Maximum = 165ms, Average = 159ms

I ran this while downloading media from the same host address so that made no difference

I ran a tracert again on the source & then pinged each element individually

C:\>tracert 213.19.180.88
Tracing route to 213.19.180.88 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms 192.168.1.1
2 9 ms 13 ms 10 ms 10.145.96.1
3 11 ms 10 ms 12 ms 12.244.97.161
4 10 ms 12 ms 11 ms 12.244.67.78
5 12 ms 11 ms 11 ms 12.244.67.82
6 14 ms 14 ms 12 ms 12.127.32.65
7 15 ms 12 ms 12 ms tbr1-p012301.sffca.ip.att.net [12.123.13.173]
8 12 ms 12 ms 15 ms ggr2-p300.sffca.ip.att.net [12.123.13.190]
9 13 ms 13 ms 13 ms so-8-1.car3.SanJose1.Level3.net [209.0.227.29]
10 14 ms 14 ms 13 ms ae-1-55.bbr1.SanJose1.Level3.net [4.68.123.129]
11 154 ms 153 ms 158 ms as-1-0.mp1.Amsterdam1.Level3.net [212.187.128.26]
12 153 ms 153 ms 159 ms ge-10-2.ipcolo1.Amsterdam1.Level3.net [213.244.165.99]
13 157 ms 153 ms 155 ms 213.19.180.88

Trace complete.

C:\>ping -n 20 -l 1400 12.123.13.173
Pinging 12.123.13.173 with 1400 bytes of data:
Request timed out.
Reply from 12.118.38.5: Destination net unreachable.
Request timed out.
Request timed out.
Request timed out.
Reply from 12.118.38.5: Destination net unreachable.
Reply from 12.118.38.5: Destination net unreachable.
Reply from 12.118.38.5: Destination net unreachable.
Request timed out.
Reply from 12.118.38.5: Destination net unreachable.
Request timed out.
Reply from 12.118.38.5: Destination net unreachable.
Request timed out.
Request timed out.
Reply from 12.118.38.5: Destination net unreachable.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from 12.118.38.5: Destination net unreachable.

Ping statistics for 12.123.13.173:
Packets: Sent = 20, Received = 8, Lost = 12 (60% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms

C:\ >ping -n 20 -l 1400 12.123.13.173
Pinging 12.123.13.173 with 1400 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from 12.118.38.5: Destination net unreachable.
Reply from 12.118.38.5: Destination net unreachable.
Reply from 12.118.38.5: Destination net unreachable.
Reply from 12.118.38.5: Destination net unreachable.
Request timed out.
Reply from 12.118.38.5: Destination net unreachable.
Reply from 12.118.38.5: Destination net unreachable.
Request timed out.
Request timed out.
Reply from 12.118.38.5: Destination net unreachable.
Request timed out.
Request timed out.
Reply from 12.118.38.5: Destination net unreachable.
Reply from 12.118.38.5: Destination net unreachable.
Request timed out.

Ping statistics for 12.123.13.173:
Packets: Sent = 20, Received = 9, Lost = 11 (55% loss),

Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms

C:\ >ping 12.123.13.173

Pinging 12.123.13.173 with 32 bytes of data:
Request timed out.
Request timed out.
Reply from 12.118.38.5: Destination net unreachable.
Reply from 12.118.38.5: Destination net unreachable.

Ping statistics for 12.123.13.173:
Packets: Sent = 4, Received = 2, Lost = 2 (50% loss),Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms

looks like I have a problem to 12.123.13.173, which is AT&T New Jersey

Why doesn't the problem show up on the whole route ping? Or am I chasing a red-herring?

I also noticed quite a few instances of repeated sequential TCP requests in another ethereal capture - I think this means it didn't make it, right?

 

[2slow2speed]

Ken,

FYI, some of the routers/next-hops that show up in your traceroute might not be pingable because they might reside inside a MPLS tunnel where the IP route is not known by the outside world on how to reach them (this is a common thing to do in order to prevent hackers from screwing around with the routers that show up in traceroute) or they might just have firewall filters/access lists that prevent ICMP echo request from being processed. As such not getting any replies frrom pings might be a normal situation (IE you might be chasing a red herring)

Sorry to tell you this, but trying to resolve your problem will take a lot more than just going down a list of traceroute outputs, ping outputs etc, given the flaky nature of the problem. It's a lot easier to diagnose reachability problems than to diagnose performance issues in a network.

In the past I've done lot's of triaging on live networks working alongside with the TAC (Technical Assistance Center) folks as well with the folks at NOC's (Network Operating Centers) for most of the ISP's in the world and most of the times that a problem such as yours arises and it's deemed critical a maintainance window is usually required in order to be able to isolate the problem down to the faulty equipment/configuration/etc/etc, isolating the problem usually requires tests to be performed using various tools as well as known paths. The worst ones are those where isolating the network makes the problem go away

In addition because of the common use of server load balancing it might be possible that although to the outside world it might look like a TCP session is being established to a single server that in reality that TCP session has been handed off by a load balancing switch to one of many *physical* servers that have been configured to provide the service.

You also need to take into account web caching as well, were frequently accessed media is cached in a server that might be located in different portions of the network (in some cases even at the ISP that you belong to)

I wish that I could say or do something that might give you more leads but without having explicit knowledge of the given network topology as well as the equipment that Comcast uses it's almost impossible to diagnose the problem in a rational and cohesive manner that might result in some real answers on where the bottleneck/problem really lies in.

I'll sleep on it a bit, and will post if I can come up with any other bright ideas or more suggestions to help.

Ken

 

[D'Ecosse]

Thanks Ken - whether you can resolve this or not I certainly have no doubt you are presenting knowledgeable responses in what you have offered here vs what I get from Comcast support

 

[NeoNSX]

What's going on here... i visit prime to escape computer problems and nerdy talk.

 

[Hrant]

What's going on here... i visit prime to escape computer problems and nerdy talk.

At least you are able to follow the lingo they are talking in here :redface:

I for one, have been totally bemused and have absolutely no clue of what is being said, and I will ascribe that to one or two generational gap :tongue: :wink:

 

[D'Ecosse]

I hope this isn't considered abuse of the "off-topic" definition.

Isn't it neat though how 'Prime members are willing to help each other, regardless of the subject matter, and there's always an expert to be found?

 

[paladin]

I certainly have no doubt you are presenting knowledgeable responses in what you have offered here vs what I get from Comcast support

"Have you tried turning the power off on the little black box?"
"Yes, i'm a CCNA and MCSE certified engineer. please transfer me to tier 2.
"I cant do that until you answer the question sir"

 

[ccns23]

This probably won't make any difference at all, but have you tried changing your DNS server to something other than a Comcast DNS server? I know there are others out there (I think one is from Level 3) that might help a little.

Just a thought. I know the DNS Server shouldn't matter too much as far as speed is concerned, but it's something to try. Ya never know in the wacky world of computers.

 

[ccns23]

"Have you tried turning the power off on the little black box?"
"Yes, i'm a CCNA and MCSE certified engineer. please transfer me to tier 2.
"I cant do that until you answer the question sir"

It's funny cause it's true..... :biggrin: :biggrin:

 

[fkong777]

ISP have different Backbone connections that can cause the difference in connection speed.

For the company I work for. One of our T1 ISP overloaded there backbone connection with another one of our FIBER ISP so those 2 office VPN connected dog slow. They avoided giving me an explaination. After numerous escalated trouble tickets FIBER ISP finally tells me have my T1 ISP call them because they overloaded their gateway to the FIBER ISP. So I told the T1 ISP to straighten it out with FIBER ISP via ISP to ISP troubleshooting. Our problem straigthen out the next day.

After setting up our WAN connection to 5 offices. I realize that I not all high speed connection are created equal. You being a end user customer you may not be able to get this issue resolved.