Reviews:
 ·Shaw
 ·TELUS
| [BC] This is getting ridiculous... Tech was out today to supposedly do a modem swap, which never happened. Supposedly they'll be replacing the tap over the next couple of days. Although what I'm seeing from pingplotter logs, it's probably not even the tap, but the gateway. The gateway is where the packetloss originates.
Unfortunately changing the tap isn't going to deal with the oversold node either.
--
Anon filter enabled. Register an account if you want to be taken seriously. |
|
| Head on down to the Shaw outlet on Cloverdale and Maple street, they had plenty of cisco modems when I was down there last week. If you have the patience to stand in line for an unexpected amount of times that is an option. |
|
Reviews:
·Shaw
·TELUS
| There's nothing wrong with the modem. It's the gateway and all the other hops on the shaw network. The graph on the bottom of the screen cap is a 10min sample. Every red block is an error.
--
Anon filter enabled. Register an account if you want to be taken seriously. |
|
 ShawSean
join:2010-07-16
Vernon, BC
kudos:12 | reply to Lesaonar
Sent you a pm Lesaonar. |
|
| reply to Lesaonar
said by Lesaonar:There's nothing wrong with the modem. It's the gateway and all the other hops on the shaw network. The graph on the bottom of the screen cap is a 10min sample. Every red block is an error.
It looks like the end point on your ping plotter is not getting packet loss? am I interpreting your graphic wrong?
If that's the case, I'd suggest that what you are seeing is that many routers prioritize ICMP packets low and will drop them if the interface or router module is busy with other work.
Motorola CMTS are known for doing this at their gateway IP. Normally actual packet loss will cause EVERY hop after the faulty link/interface to error equally. I'm seeing that your last hop is showing no packet loss? |
|
| That would be true if it was ICMP packets. It's set to TCP packets. |
|
| Great test!
Does look like there is an issue then |
|
|
|
Reviews:
·Shaw
·TELUS
1 edit | reply to ShawSean
Line tech arrived just after 8am. And replaced the line to the house, not the bridge on the pole. Hops 2, 3 and 4 are ranging between 3-10% packet loss, better than yesterday, and hop 5 is ranging between 20-30% packet loss, the same as yesterday. Pages are still timing out on a regular basis, including DSLR which took 5 refreshes to actually load.
The 2 prior techs have inferred that the next visit the bridge should be replaced, due to it's age. Since everything passes through the bridge, and 2 prior techs have troubleshot it to the bridge, would it not make sense to actually replace the aging bridge?
I'll continue collecting data, but even the last 24hrs shows issues within Shaw's network.
On a positive note, the issues we were having with the picture/sound freezing hasn't occurred yet and no messages about the gateway not being able to communicate with the portals. Although I've only spent about 15min sitting in front of the TV, since I have work to do. Will update tonight when I have more time to actually watch TV.
--
Anon filter enabled. Register an account if you want to be taken seriously. |
|
| The Gateway and portals use MoCA (a protocol that operates above 1GHz) inside the home to talk. If you are having issues there it would be an unrelated problem. There is a MoCA filter installed before the gateway/portals to ensure that everything above 1GHz inside your house does not leave, and nothing above 1GHz from outside comes in. |
|
Reviews:
·Shaw
·TELUS
| But an issue with the drop could/would cause issues with the gateway system. Have been watching TV off and on the last 30 mins with not a single "freeze", before there'd have been 10+. So replacing the drop seems to have at least fixed that issue.
And major kudos to Sean and Nathan for going above and beyond attempting to get these issues worked out. Account's been flagged for a modem swap, so will head down 1st thing tomorrow.
--
Anon filter enabled. Register an account if you want to be taken seriously. |
|
Reviews:
·Shaw
| said by Lesaonar:...
And major kudos to Sean and Nathan for going above and beyond attempting to get these issues worked out..
Ya those 2 are awesome, lol. just had a couple local Shaw techs come out and "troubleshoot" my line, when they saw my PC they didn't even take their laptop out of the bag, using my PC to run speed tests claiming "i have never seen 200Mbit before, our laptop isn't even capable", next they thought i was on the fiber package to get that 200Mbit but after a call into their RAC they were quickly corrected :P. 2 of them showed up together and apparently one was a high ranked local tech (assuming second one was a trainee).
After dealing with Nathan and Sean I almost can't wrap my head around the disparity in professionalism/knowledge that the support staff out here in Edmonton lacks in comparison. Granted the 2 local techs did give me a straight up answer and i can appreciate their honesty, they were both courteous and polite. Regardless of the fact that the answer does not reflect well on Shaw itself. |
|
ShawSean
join:2010-07-16
Vernon, BC
kudos:12 | Heh, thanks guys. I'll pass along the kudos to Nathan.
Anyway, I've pm'd you back Baud1200, we'll be in touch.
Cheers.
--
Sean
Twitter - @Shaw_Sean |
|
Reviews:
·Shaw
·TELUS
| Modem swapped, issue continues. Far less PL between hops 1-4, but exactly the same on 5.
--
Anon filter enabled. Register an account if you want to be taken seriously. |
|
| You still have no packet loss to the last hop. That makes 0 sense. |
|
Reviews:
·Shaw
·TELUS
1 edit | Because it does both tracert as well as ping? It tracerts the route and pings each individual hop. The final Hop obviously has no PL during it's sample. You also have to take into consideration that you're not watching the tool in real time and are only seeing the snapshot(s) that are posted. Usually the hops that aren't in the double digits, will at times, level out and show no PL at all, since during that sample they're not showing PL in the echo reply.
--
Anon filter enabled. Register an account if you want to be taken seriously. |
|
| said by Lesaonar:Because it does both tracert as well as ping? A traceroute is a series of ICMP Echo messages (pings) with the TTL starting at 1 and then increasing until it hits the destination hop and gets a response back. Then the process is ended and your traceroute is complete.
I have a lot of experience with ping plotter.
As your last hop is showing 0% packet loss I'd say your connection is working fine. ICMP is being dropped by routers on the internet, which is very common, but your traffic to the destination on that ping plotter display, and the only screenshot when you show the graph of the final destination all show 0 packetloss to the last hop.
This indicates everything is working normally.
Most CMTS and a lot of internet routers treat ICMP as low priority and drop it if they are doing someone more important. Your screenshots look typical to my experience with ping plotter.
In my experience ping plotter will ALWAYS drop packets on the first 'gateway' hop in the Shaw network (the CMTS) due to ICMP prioritization. |
|
Reviews:
·Shaw
·TELUS
| We've already been through the ICMP discussion, as per your post on the 8th. It's not using ICMP packets, it's set to use TCP packets. This isn't a packet prioritization issue.
--
Anon filter enabled. Register an account if you want to be taken seriously. |
|
| said by Lesaonar:We've already been through the ICMP discussion, as per your post on the 8th. It's not using ICMP packets, it's set to use TCP packets. This isn't a packet prioritization issue.
I still disagree with you.  |
|
Reviews:
·Shaw
·TELUS
| reply to ravenchilde
said by ravenchilde:Great test!
Does look like there is an issue then
Oooook.
--
Anon filter enabled. Register an account if you want to be taken seriously. |
|
Cornat
join:2011-10-17
Kelowna, BC
1 edit | While this situation would be easily explained if it were using ICMP packets, I do see your version of the program is able to use TCP packets.
»www.pingplotter.com/manual/stand···ype.html
My next thought would be make sure that the TCP option is enabled. Maybe try a test with the default ICMP and one with TCP to compare?
Edit:
This article from the same site helps explain Raven's point.
»www.pingplotter.com/manual/faq.html#Anchor4 |
|
