tlhIngan
join:2002-07-08
Richmond, BC
kudos:1 | reply to ShawSean
Re: [ALL] Ask ShawSean Now just to figure out if Shaw will exchange the boxes. After all, if you got the channels, it would definitely suck if you're paying for 'em and can't get 'em. (I wonder if one could arrange for a few dollar discount on service for getting channels you can't receive...). |
|
EK
join:2011-10-16
Calgary, AB | reply to ShawSean
i read online that student bundle pricing is expiring tmr? (Oct 15, 2012)
is this true?
also, can you tell me what the current prices should be for someone on the student promo Sean?
I just wanted to double check my bill and see if im being charged correctly or if there is something missing
i have sent u a PM also with this...but i thought i should post here too in case the student promo expiring is legit |
|
| The student promo will likely be expiring, I would have thought it would before this...
If you are on it, then you have your promo, but no new signups after the 15th.
--
Yes, I am not employed and looking for IT work. Have passport, will travel. |
|
 ShawSean
join:2010-07-16
Vernon, BC
kudos:12 | reply to EK
Hey EK - I'll have someone contact you and follow up regarding your account and pricing - I don't have details sorry.
Cheers.
--
Sean
Shaw Community Manager |
|
| reply to ShawSean
Hello ShawSean, I've been having some really poor speed issues here in Edmonton for the past couple of weeks. I think I might have tracked the problem to a lossy router of a transit provider Shaw is peered with. Here is an mtr from myself to my server:
|---------------------------------------------------------------------------------- ------- -|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|----- -|
| 192.168.2.1 - 0 | 101 | 101 | 0 | 0 | 16 | 0 |
| No response from host - 100 | 101 | 0 | 0 | 0 | 0 | 0 |
| tl11ni.ed.shawcable.net - 0 | 101 | 101 | 0 | 14 | 63 | 15 |
| 66.163.78.170 - 0 | 100 | 100 | 15 | 27 | 47 | 16 |
| rd1he-ge4-3.rd.shawcable.net - 0 | 100 | 100 | 15 | 31 | 47 | 31 |
|ix-3-1-0-0.tcore1.00S-Seattle.as6453.net - 0 | 100 | 100 | 62 | 72 | 109 | 78 |
| if-14-2.tcore1.PDI-PaloAlto.as6453.net - 0 | 100 | 100 | 78 | 86 | 141 | 78 |
| if-2-2.tcore2.PDI-PaloAlto.as6453.net - 1 | 100 | 99 | 62 | 73 | 125 | 62 |
| Vlan3254.icore1.SQN-SanJose.as6453.net - 14 | 100 | 86 | 62 | 75 | 94 | 78 |
|te0-7-0-2.ccr22.sjc03.atlas.cogentco.com - 0 | 100 | 100 | 78 | 94 | 110 | 94 |
|te0-2-0-3.ccr22.sjc01.atlas.cogentco.com - 0 | 100 | 100 | 78 | 84 | 94 | 78 |
|te0-0-0-4.ccr22.sfo01.atlas.cogentco.com - 0 | 100 | 100 | 78 | 85 | 110 | 93 |
|te0-1-0-2.ccr22.mci01.atlas.cogentco.com - 0 | 100 | 100 | 78 | 95 | 157 | 93 |
| te4-3.ccr01.stl03.atlas.cogentco.com - 13 | 100 | 87 | 78 | 137 | 359 | 203 |
| 38.104.162.66 - 24 | 100 | 76 | 78 | 88 | 187 | 78 |
|static-ip-209-239-125-4.inaddr.ip-pool.com - 25 | 100 | 75 | 93 | 96 | 110 | 94 |
| dragon305.startdedicated.com - 9 | 100 | 91 | 78 | 93 | 110 | 94 |
|________________________________________________|______|______|______|______|______|_____ _|
WinMTR - 0.8. Copyleft @2000-2002 Vasile Laurentiu Stanimir ( stanimir@cr.nivis.com )
I know mtr isn't really fool proof since a lot of backbone routers prioritize traffic directed at them differently than what is routed through them. However I believe the as6453.net routers to be the source of this problem. I did some further testing using looking glasses from both as6453.net and cogentco. From the as6453 looking glass pinging back to me there was packet loss in 2 out of every 5 runs, but no packet loss when I ran the test going forward to the server I mtr'd. Using the cogentco looking glass pinging back to me there was also packet loss pinging back to me, but no packet loss pinging toward the server again. So I'm fairly certain the problem lies with as6453. If you could help me with this issue I'd be very grateful. Thanks! |
|
| said by kaugustino9:Hello ShawSean,
I've been having some really poor speed issues here in Edmonton for the past couple of weeks. I think I might have tracked the problem to a lossy router of a transit provider Shaw is peered with. Here is an mtr from myself to my server:
[snip]
I know mtr isn't really fool proof since a lot of backbone routers prioritize traffic directed at them differently than what is routed through them. However I believe the as6453.net routers to be the source of this problem. I did some further testing using looking glasses from both as6453.net and cogentco. From the as6453 looking glass pinging back to me there was packet loss in 2 out of every 5 runs, but no packet loss when I ran the test going forward to the server I mtr'd. Using the cogentco looking glass pinging back to me there was also packet loss pinging back to me, but no packet loss pinging toward the server again. So I'm fairly certain the problem lies with as6453.
If you could help me with this issue I'd be very grateful.
Thanks!
I took a look at your destination from my connection in Calgary. While I don't end up routing through as6453.net I still end up with a large amount of packetloss near the end of cogentco's network (more than you were seeing). Wanting to avoid any re-prioritization of ICMP packets I re-ran my test using TCP SYN packets to port 80, followed by a RST packet, by the bucketful (assuming a bucket is 100 packets for each respective TTL :P) I didn't want more than 100 since that could be seen as a SYN flood. The same principle applies with the default *nix UDP traceroute though; when a packet expires an ICMP packet should be sent back indicating the original packet expired in transit.
You can have a look at my results (and the command I ran) here »pastebin.com/q4W4eVSe - its pretty huge and I didn't want to clutter up this forum.
What I see is that around hop 15 ("around" because there are different routes used for each packet right from the get go [I enforced a start TTL of 4, and even then we had divergent routes], not that different routes are necessarily a bad thing) the 'time exceeded in-transit' packets were starting to be reliably unseen.
A few hops further, however, (around 17) we start to see reliable 'time exceeded in-transit' responses again. This means that while these cogentco routers are not sending the 'time exceeded in-transit' packets (either load related or design related), they are not seeing much packetloss; the TCP SYN packets are making it through when the TTL is high enough.
The last hop (18) is supposed to be your target (dragon305.startdedicated.com), but due to the differing paths 209.239.152.4 shows up for ~50% of the responses. Since it is listening on port 80 we should see SYN ACK packets back from it (i.e. packets that would not be re-prioritized or preferentially dropped by the network in between). The 209.239.125.4 responses there are the same-old 'time exceeded in-transit'. If we prune out the divergent route responses (and only focus on the SYN ACK responses we need to look at), I count 52 responses and 2 lost packets, just shy of 4% packetloss right at the destination.
If you have a linux machine, or can get a linux VM running, I would try to run the same test from your location to see if your results match mine. |
|
| Thanks for taking the time to help test.
I ran an mtr from the server to the first hop listed in your test to see if the return route would be much different than the forward route. It was, it does use as6534 going back to you (well as close as I could get back to you since I don't know your IP):
Packets Pings
Host Loss% Snt Last Avg Best Wrst StD ev
1. static-ip-69-64-35-253.inaddr.ip-pool.com 0.0% 101 2.5 2.7 1.3 7.2 1 .5
2. static-ip-209-239-125-2.inaddr.ip-pool.com 0.0% 100 0.5 3.6 0.4 54.3 10 .3
3. te3-7.ccr01.stl03.atlas.cogentco.com 0.0% 100 18.2 46.0 0.6 460.6 75 .9
4. te0-2-0-5.ccr22.ord01.atlas.cogentco.com 0.0% 100 7.7 7.6 7.4 8.0 0 .1
5. te0-5-0-3.ccr22.ord03.atlas.cogentco.com 0.0% 100 7.8 7.8 7.6 8.1 0 .1
6. ix-1-3-1-0.tcore1.CT8-Chicago.as6453.net 7.0% 100 18.4 24.3 17.7 71.5 10 .7
7. 66.110.14.14 4.0% 100 29.7 24.7 19.0 34.4 3 .6
8. rc2ec-tge0-0-1-0.il.shawcable.net 3.0% 100 22.4 22.1 18.9 72.5 5 .6
9. rd2cs-tge1-1-1.ok.shawcable.net 3.0% 100 38.1 38.4 34.3 42.4 2 .3
10. rc2so-tge0-3-0-0.cg.shawcable.net 7.0% 100 73.5 72.8 70.8 77.3 1 .3
I haven't done a forward test like you did yet, but will shortly. |
|
|
|
| reply to Jumpy
Here is the tcptraceroute from home to the server: »pastebin.com/hjnZdgD7
Looks like it gets bad toward the end of as6534 again... I don't know if this is really a reliable test since we are still sending packets directly to routers...they may still deprioritize tcp packets sent to them.
Please tell me your thoughts on these results.
Thanks. |
|
| You aren't sending them directly to the routers; you're still addressing your packets to your destination (dragon305). The only difference between the tcptraceroute and a tcp connection is that tcptraceroute artificially limits the TTL of the packet, causing the normal packet handling of each router along the way to encounter an 'expire' condition which _should_ be dealt with by sending an ICMP packet in response. This ICMP response packet is what is used to determine the route the packets are taking.
Looking at your paste, I see the same thing I saw in mine. One router (66.198.97.10, hop 10) shows a bunch of timeouts. This simply means that the ICMP response packet was never seen. The very next hop (11, 154.54.12.21) shows no timeouts. This means that your TCP packets are making it through just fine and the SYNACK response is making its way back just fine.
Actually, it is only hop 10 that is showing any sort of issue. Since we know that it is relaying the TCP packets properly, and that there are no timeouts that occur after it, I don't think we can blame anything on a network issue. I added a longer wait (add -w 10 somewhere in that command) to my trace and the final hop for me showed no loss (some 3 second + responses that were not seen prior to that final hop though). I'd start by opening a ticket with your hosting provider (I assume that dragon305 is your host). |
|
| I have opened tickets with the server host, they think that its a problem with as6453 too, but they don't have a peering agreement with them so they can't complain about it. Shaw does have a peering agreement with as6453 though, so I was kind of hoping they could complain about the loss. I can download fast from that server using other servers that don't route through as6453. |
|
 Pooya
@genuineguidegear.com | reply to ShawSean
Hi guys,
I have BB50 and back in March 2012 i contacted ShawSean and he changed the code on the account so i could get 5Mbps instead of 3, but last 2 weeks i am back at 3Mbps and tried contacting Sean again with no luck, so i asked shaw and this is the reply i got
Ok the speed is provisioned correctly for the node you are currently on. As the upgrades to the node are finished and Phase 2 starts rolling out the upload speed will be bumped up to 5 mbps. That process was only starting last month. You are getting the upload speed you are supposed to be getting right now. The code added to the account in March is the same one that is one your account now. If you were getting 5 mbps then you shouldnt have been.
I am a bit lost, specially since my office is like 5 min from my house and is getting 5Mbps on BB50 !!! Can someone please help me?
Really appreciate this. |
|
ShawSean
join:2010-07-16
Vernon, BC
kudos:12 | Hey guys, sorry for the delay in my responses - I've been extremely busy lately but I'm here now to help get these things figured out.
@kaugustino9 - still having speed issues? If so pm me your account details and we'll investigate further.
@Pooya - I know there have been some codes changes made recently that most likely effected your upload limit. Please send me your account details again and I'll see if there's anything I'm able to do.
Cheers.
--
Sean
Shaw Community Manager |
|
| No Problem.
The speed issue seemed to clear up last night and the speed is still good today.
I'll let you know if it gets bad again.
Thanks for the reply! |
|
ShawSean
join:2010-07-16
Vernon, BC
kudos:12 | Sounds good - keep me posted.
--
Sean
Shaw Community Manager |
|
| reply to ShawSean
I am curious as to why Shaw has gone and changed the Broadband 100 upload speed for Calgary from 10Mbps to 5Mbps? |
|
ShawSean
join:2010-07-16
Vernon, BC
kudos:12 | Hey John,
Can you pm me your account details so I can investigate further? Not sure why that's happening.
Cheers,
Sean
--
Sean
Shaw Community Manager |
|
| reply to JohnYYC25
50 mbps used to have 5 mbps upload, now has 3 mbps as well |
|
| Well this isn't looking good for areas that haven't been upgraded yet, was really hoping to see those faster upload speeds.
Kind of disappointing that they go and increase prices, and then decrease their speeds. |
|
ShawSean
join:2010-07-16
Vernon, BC
kudos:12 | If customers have been downgraded from a higher upload rate it's just due to our dnu transitioning with their accounts - this is temporary as we adjust the system to work properly with the new limits.
If this has happened to your account please contact me and I'll do my best to get things sorted out.
Cheers.
--
Sean
Shaw Community Manager |
|
dondon
join:2004-07-22
Victoria, BC | reply to ShawSean
Re: [ALL] Ask a Shaw Rep Any idea when phase 2 is rolling out in Victoria? A tech told me "September" back in July. Apparently they were waiting for Western communities (Langford, Sooke) to have infrastructure upgrades or something, so the entire CRD could be switched over at the same time. Well it's now November. Would really like to have that 10mbps upload. Metro Vancouver seems to be getting done piecemeal (West van has 10mbit on Shaw's site, for example, while Vancouver itself is still listed at 5).
price keeps going up, but speeds don't.  |
|
