how-to block ads
|
|
Share Topic
 |
 |
|
|
|
| reply to yyonline
Re: Intermittent Speed/Latency/Connectivity issues An update -
Turns out this was DNS related. Comcast assigns 3 DNS servers. Turns out the first one was really slow resolving names. If I manually enter the second as the DNS, pages loads fly. Pages that were taking 20-30 seconds to load now load in 3! I really noticed this on news sites, where many names get resolved. Seems some news sites have different servers for text, images, comments, etc. (ie, images.site.com, comments.site.com, etc.) Throw a few banner ads in the mix, and that's alot of names to resolve.
I thought this wasn't a DNS issue, as I tried using OpenDNS for a few days. For me at least, it seems OpenDNS wasn't any faster than the original Comcast DNS.
So...Two questions remain.
First, Is there any good way to tell Comcast one of their DNS servers is slowing down page loads? Techs seem to get annoyed when people call in "knowing" what the problem is. I can relate to this, as I work in tech support for a living. Still, if there is an issue, it should be fixed.
Second, regarding the smokeping tests... I'm in PA, so the NY test rarely shows any loss. The CA test shows some occasional packet loss. Does anybody know if a small amount of packet loss is normal or acceptable with the smokeping tests? | |
1 edit | I've seen occasional issues recently. Slow DNS to both some Comcast DNS servers and OpenDns server. And some web sites slow down at different times, including dslreports.
I ran thru many different diagnostics and tools and came to the conclusion that Comcast is experiencing congestion in some routers on some paths on a sporadic basis. Whether this is related to their maintenance work as they rollout Docsis 3 or not is the question I would have. But it is possible that as they modify their systems they are experiencing congestion on some paths thru the internet.
I didn't bother pursuing this through Comcast Support because you can never get to the real network engineers that can discuss and solve these types of problems. Level 1 & 2 CSRs just can't do anything but open a ticket and then you never hear what solved or didn't solve a problem.
I will say that the last 2 days have been slowdown free and all we can do is hope for the best as system wide changes are being done.
P.S.>> here is a Q&A and some code put together by someone here at dslreports that can test DNS lookup delays to multiple DNS servers at 1 shot:
»SBC DSL FAQ »How do I test DNS lookup latency with ns_bench?
--
My BLOG .. .. Internet News .. .. My Web Page | |
 koitsuPremium,MVM
join:2002-07-16
Mountain View, CA
kudos:14 | reply to yyonline
said by yyonline:Second, regarding the smokeping tests... I'm in PA, so the NY test rarely shows any loss. The CA test shows some occasional packet loss. Does anybody know if a small amount of packet loss is normal or acceptable with the smokeping tests? Whatever that tool is (smokeping), it's horrendous. The graphs tell me very little, and are nearly impossible to read (I love all the blurring, and it isn't image compression since you're using PNG). I don't know how you put up with that.
To answer your question: "it depends". I don't know how smokeping works, so I don't know if it's similar in methodology to that of WinMTR, mtr, or traceroute.
If the tool attempts to send a packet (of any type; TCP, UDP, or ICMP) to a router at each hop between you and the destination, then yes, some of those hops are very likely to show packet loss due to ICMP de-prioritisation. This does not mean the packet you sent the destination is being dropped or de-prioritised -- only the individual hops (to routers) along the way. This is completely normal in this day and age, which is sad, because it makes troubleshooting a pain in the rear; I cannot tell you how many times I've had to argue with peering providers when they try to use the ICMP de-prio excuse at incorrect/inappropriate times.
If smokeping simply sends an ICMP packet to the destination (e.g. does not operate like WinMTR, mtr, or traceroute), and you're seeing packet loss there, then that also "could" be normal -- some IP stacks of servers will discard excessive numbers of ICMP packets if received, others can be configured to drop a certain percentage of traffic of any type (ICMP is common).
Honestly, it would be much more beneficial if you could use a tool like PingPlotter (which requires some configuration changes to be effective) or WinMTR and see if there's an increase in packet loss at a specific hop that "trickles down" through further hops.
Miscellaneous:
Your modem signal levels look okay, except for your upstream power, which is a little on the high side.
"Started Unicast Maintenance Ranging - No Response received - T3 time-out" messages that recur are normal. Most of us see this sort of thing regularly. If you see FEC framing loss, or "broadcast maintenance" messages, those will indicate loss of frame (cable sync loss).
--
Making life hard for others since 1977.
I speak for myself and not my employer/affiliates of my employer. | |
|
