Just wondering if anyone else has noticed that Shaw seems to be having systemic problems with their network? I've run tests from several different locations and all of them seem to show significant intermittent packet loss to the first hop (gateway). It comes and goes and some days are worse than others but it is persistent. -- John Lange www.johnlange.ca
I get persistent packet loss to the first hop gateway if I'm doing any heavy work. Heavy, as in downloading something via http. It's been happening forever. Gerald ----- Original Message ----- From: "John Lange" <john@johnlange.ca> To: "MUUG Roundtable" <Roundtable@muug.mb.ca> Sent: Tuesday, October 19, 2010 10:28:37 AM Subject: [RndTbl] Shaw packet loss Just wondering if anyone else has noticed that Shaw seems to be having systemic problems with their network? I've run tests from several different locations and all of them seem to show significant intermittent packet loss to the first hop (gateway). It comes and goes and some days are worse than others but it is persistent. -- John Lange www.johnlange.ca _______________________________________________ Roundtable mailing list Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
On 10-10-19 10:28 AM, John Lange wrote:
Just wondering if anyone else has noticed that Shaw seems to be having systemic problems with their network?
I've run tests from several different locations and all of them seem to show significant intermittent packet loss to the first hop (gateway).
It comes and goes and some days are worse than others but it is persistent.
Funny you should mention that... Today I noticed the updates for Mint 9 are really slow. This is while they are giving me a month of upgraded speed. Over all I didn't notice any change in speed other than the occasional peak. Since you mentioned it, today seems to be particularly bad. Not worth the extra $10/month if you ask me. Then there is their policy of slowing down the entire connection if they determine someone is using bittorrent on a LAN (even if the user caps the up and down speeds). BTW, I'm only using Firefox and Thunderbird at the moment. Things are pretty bad. Later Mike
On Tue, Oct 19, 2010 at 10:36 AM, Mike Pfaiffer <high.res.mike@gmail.com>wrote:
Then there is their policy of slowing down the entire connection if they determine someone is using bittorrent on a LAN (even if the user caps the up and down speeds)
Do you have a source for this? Are you sure it's not because you're starving out your upstream and therefore not able to get ACKs out? Sean -- Sean Walberg <sean@ertw.com> http://ertw.com/
On 10-10-19 10:39 AM, Sean Walberg wrote:
On Tue, Oct 19, 2010 at 10:36 AM, Mike Pfaiffer<high.res.mike@gmail.com>wrote:
Then there is their policy of slowing down the entire connection if they determine someone is using bittorrent on a LAN (even if the user caps the up and down speeds)
Do you have a source for this? Are you sure it's not because you're starving out your upstream and therefore not able to get ACKs out?
Sean
Give it a try. Grab a movie or something. Use a bittorrent client capable of capping the up and down speed. Ktorrent can do this. See what you can get for both up and down uncapped. Then try running say Firefox and look at its performance. Stop the bittorrent transfer and look at Firefox again in a few minutes. Set up a cap in bittorrent say 10K on both the up and down (bear in mind this is supposed to be a multi-megabit connection). Restart your bittorrent and see what happens with Firefox. You'll notice the bittorrent will transfer to what ever maximum you set while other programs will barely function on the internet. Local transfers on the LAN are fine though. Later Mike
Mike, that sounds more like your gateway router running out of CPU cycles than Shaw doing traffic management. I work with an ISP: doing the sort of thing you're describing *is* possible, but insanely difficult and expensive, especially on Shaw's scale. I have a 2GHz router, it should handle it - I can test later this week. -Adam -----Original Message----- From: Mike Pfaiffer <high.res.mike@gmail.com> Sender: roundtable-bounces@muug.mb.ca Date: Tue, 19 Oct 2010 10:57:39 To: Continuation of Round Table discussion<roundtable@muug.mb.ca> Reply-To: Continuation of Round Table discussion <roundtable@muug.mb.ca> Subject: Re: [RndTbl] Shaw packet loss On 10-10-19 10:39 AM, Sean Walberg wrote:
On Tue, Oct 19, 2010 at 10:36 AM, Mike Pfaiffer<high.res.mike@gmail.com>wrote:
Then there is their policy of slowing down the entire connection if they determine someone is using bittorrent on a LAN (even if the user caps the up and down speeds)
Do you have a source for this? Are you sure it's not because you're starving out your upstream and therefore not able to get ACKs out?
Sean
Give it a try. Grab a movie or something. Use a bittorrent client capable of capping the up and down speed. Ktorrent can do this. See what you can get for both up and down uncapped. Then try running say Firefox and look at its performance. Stop the bittorrent transfer and look at Firefox again in a few minutes. Set up a cap in bittorrent say 10K on both the up and down (bear in mind this is supposed to be a multi-megabit connection). Restart your bittorrent and see what happens with Firefox. You'll notice the bittorrent will transfer to what ever maximum you set while other programs will barely function on the internet. Local transfers on the LAN are fine though. Later Mike _______________________________________________ Roundtable mailing list Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
On 10-10-19 11:03 AM, Adam Thompson wrote:
Mike, that sounds more like your gateway router running out of CPU cycles than Shaw doing traffic management. I work with an ISP: doing the sort of thing you're describing *is* possible, but insanely difficult and expensive, especially on Shaw's scale. I have a 2GHz router, it should handle it - I can test later this week. -Adam
d-link EBR-2310. As a 10/100 router it should be faster than the connection I get from Shaw. Transfers on the LAN side are pretty much unaffected no matter what I do. No time-outs. No "Can't find server" messages. That sort of thing. Then again it's local to the house. It looks like it'll be later in the day before I can do the tests suggested by everybody. All the tasks in a queue... Later Mike
-----Original Message----- From: Mike Pfaiffer<high.res.mike@gmail.com> Sender: roundtable-bounces@muug.mb.ca Date: Tue, 19 Oct 2010 10:57:39 To: Continuation of Round Table discussion<roundtable@muug.mb.ca> Reply-To: Continuation of Round Table discussion<roundtable@muug.mb.ca> Subject: Re: [RndTbl] Shaw packet loss
On 10-10-19 10:39 AM, Sean Walberg wrote:
On Tue, Oct 19, 2010 at 10:36 AM, Mike Pfaiffer<high.res.mike@gmail.com>wrote:
Then there is their policy of slowing down the entire connection if they determine someone is using bittorrent on a LAN (even if the user caps the up and down speeds)
Do you have a source for this? Are you sure it's not because you're starving out your upstream and therefore not able to get ACKs out?
Sean
Give it a try. Grab a movie or something. Use a bittorrent client capable of capping the up and down speed. Ktorrent can do this. See what you can get for both up and down uncapped. Then try running say Firefox and look at its performance. Stop the bittorrent transfer and look at Firefox again in a few minutes. Set up a cap in bittorrent say 10K on both the up and down (bear in mind this is supposed to be a multi-megabit connection). Restart your bittorrent and see what happens with Firefox. You'll notice the bittorrent will transfer to what ever maximum you set while other programs will barely function on the internet. Local transfers on the LAN are fine though.
Later Mike
_______________________________________________ Roundtable mailing list Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
_______________________________________________ Roundtable mailing list Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
On Tue, Oct 19, 2010 at 10:57 AM, Mike Pfaiffer <high.res.mike@gmail.com>wrote:
Give it a try. Grab a movie or something. Use a bittorrent client capable of capping the up and down speed. Ktorrent can do this. See what you can get for both up and down uncapped. Then try running say Firefox and look at its performance. Stop the bittorrent transfer and look at Firefox again in a few minutes. Set up a cap in bittorrent say 10K on both the up and down (bear in mind this is supposed to be a multi-megabit connection). Restart your bittorrent and see what happens with Firefox. You'll notice the bittorrent will transfer to what ever maximum you set while other programs will barely function on the internet. Local transfers on the LAN are fine though.
Like you, I haven't done any formal testing, but my wife has uT going non stop and I haven't had any problems with my download speed unless she forgets to cap her upstream. uT is running forced encryption, FWIW. It's almost a certainty that Shaw has DPI policies dealing with torrent. I'm not disputing what you're seeing, but correlation does not equal causation. As a start, try doing some Wireshark I/O graphs on the various streams with and without a torrent running. Do the bandwidth of the non torrent flows change? Is there a change in the TCP setup times? Are ACK packets being delayed? Are you seeing loss? Sean -- Sean Walberg <sean@ertw.com> http://ertw.com/
On 10-10-19 11:07 AM, Sean Walberg wrote:
On Tue, Oct 19, 2010 at 10:57 AM, Mike Pfaiffer<high.res.mike@gmail.com>wrote:
Give it a try. Grab a movie or something. Use a bittorrent client capable of capping the up and down speed. Ktorrent can do this. See what you can get for both up and down uncapped. Then try running say Firefox and look at its performance. Stop the bittorrent transfer and look at Firefox again in a few minutes. Set up a cap in bittorrent say 10K on both the up and down (bear in mind this is supposed to be a multi-megabit connection). Restart your bittorrent and see what happens with Firefox. You'll notice the bittorrent will transfer to what ever maximum you set while other programs will barely function on the internet. Local transfers on the LAN are fine though.
Like you, I haven't done any formal testing, but my wife has uT going non stop and I haven't had any problems with my download speed unless she forgets to cap her upstream. uT is running forced encryption, FWIW.
Without encryption the problem IS worse.
It's almost a certainty that Shaw has DPI policies dealing with torrent. I'm not disputing what you're seeing, but correlation does not equal causation.
Quite correct. As you hint in the next paragraph it is worth looking at. Still, even with a large HTTP or ftp download the problems aren't there.
As a start, try doing some Wireshark I/O graphs on the various streams with and without a torrent running. Do the bandwidth of the non torrent flows change? Is there a change in the TCP setup times? Are ACK packets being delayed? Are you seeing loss?
I'll have to get back to you on that. That's not something I've done yet.
Sean
Later Mike
Just for reference; I use mtr for testing this. Here is the command line. As you can see, I've set a very aggressive packet rate (20/second). # mtr -r -w -c 500 -n -i 0.05 www.google.ca I actually stick it in a loop so I can keep it running and see periodic results: # while true ; do date ; mtr -r -w -c 500 -n -i 0.05 www.google.ca ; done When I see loss, it's always at the first hop yet it doesn't seem to matter which gateway it is. These are all Shaw business customers so may not be affecting residential. John On Tue, Oct 19, 2010 at 10:57 AM, Mike Pfaiffer <high.res.mike@gmail.com> wrote:
On 10-10-19 10:39 AM, Sean Walberg wrote:
On Tue, Oct 19, 2010 at 10:36 AM, Mike Pfaiffer<high.res.mike@gmail.com>wrote:
Then there is their policy of slowing down the entire connection if they determine someone is using bittorrent on a LAN (even if the user caps the up and down speeds)
Do you have a source for this? Are you sure it's not because you're starving out your upstream and therefore not able to get ACKs out?
Sean
Give it a try. Grab a movie or something. Use a bittorrent client capable of capping the up and down speed. Ktorrent can do this. See what you can get for both up and down uncapped. Then try running say Firefox and look at its performance. Stop the bittorrent transfer and look at Firefox again in a few minutes. Set up a cap in bittorrent say 10K on both the up and down (bear in mind this is supposed to be a multi-megabit connection). Restart your bittorrent and see what happens with Firefox. You'll notice the bittorrent will transfer to what ever maximum you set while other programs will barely function on the internet. Local transfers on the LAN are fine though.
Later Mike
_______________________________________________ Roundtable mailing list Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
-- John Lange www.johnlange.ca
If MTR shows loss at hop 1 but *not* at hop 2, that's just their router ignoring your ICMP packets and doesn't actually indicate packet loss. *sigh* I can't believe I'm defending Shaw... -Adam -----Original Message----- From: John Lange <john@johnlange.ca> Sender: roundtable-bounces@muug.mb.ca Date: Tue, 19 Oct 2010 11:14:16 To: Continuation of Round Table discussion<roundtable@muug.mb.ca> Reply-To: Continuation of Round Table discussion <roundtable@muug.mb.ca> Subject: Re: [RndTbl] Shaw packet loss Just for reference; I use mtr for testing this. Here is the command line. As you can see, I've set a very aggressive packet rate (20/second). # mtr -r -w -c 500 -n -i 0.05 www.google.ca I actually stick it in a loop so I can keep it running and see periodic results: # while true ; do date ; mtr -r -w -c 500 -n -i 0.05 www.google.ca ; done When I see loss, it's always at the first hop yet it doesn't seem to matter which gateway it is. These are all Shaw business customers so may not be affecting residential. John On Tue, Oct 19, 2010 at 10:57 AM, Mike Pfaiffer <high.res.mike@gmail.com> wrote:
On 10-10-19 10:39 AM, Sean Walberg wrote:
On Tue, Oct 19, 2010 at 10:36 AM, Mike Pfaiffer<high.res.mike@gmail.com>wrote:
Then there is their policy of slowing down the entire connection if they determine someone is using bittorrent on a LAN (even if the user caps the up and down speeds)
Do you have a source for this? Are you sure it's not because you're starving out your upstream and therefore not able to get ACKs out?
Sean
Give it a try. Grab a movie or something. Use a bittorrent client capable of capping the up and down speed. Ktorrent can do this. See what you can get for both up and down uncapped. Then try running say Firefox and look at its performance. Stop the bittorrent transfer and look at Firefox again in a few minutes. Set up a cap in bittorrent say 10K on both the up and down (bear in mind this is supposed to be a multi-megabit connection). Restart your bittorrent and see what happens with Firefox. You'll notice the bittorrent will transfer to what ever maximum you set while other programs will barely function on the internet. Local transfers on the LAN are fine though.
Later Mike
_______________________________________________ Roundtable mailing list Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
-- John Lange www.johnlange.ca _______________________________________________ Roundtable mailing list Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
With all the frapping ARP requests that are broadcast (and therefore being sent out by the head end) I'm not surprised the control plane is swamped :P Sean On Tue, Oct 19, 2010 at 11:17 AM, Adam Thompson <athompso@athompso.net>wrote:
If MTR shows loss at hop 1 but *not* at hop 2, that's just their router ignoring your ICMP packets and doesn't actually indicate packet loss.
*sigh* I can't believe I'm defending Shaw...
-Adam
-----Original Message----- From: John Lange <john@johnlange.ca> Sender: roundtable-bounces@muug.mb.ca Date: Tue, 19 Oct 2010 11:14:16 To: Continuation of Round Table discussion<roundtable@muug.mb.ca> Reply-To: Continuation of Round Table discussion <roundtable@muug.mb.ca> Subject: Re: [RndTbl] Shaw packet loss
Just for reference; I use mtr for testing this.
Here is the command line. As you can see, I've set a very aggressive packet rate (20/second).
# mtr -r -w -c 500 -n -i 0.05 www.google.ca
I actually stick it in a loop so I can keep it running and see periodic results:
# while true ; do date ; mtr -r -w -c 500 -n -i 0.05 www.google.ca ; done
When I see loss, it's always at the first hop yet it doesn't seem to matter which gateway it is. These are all Shaw business customers so may not be affecting residential.
John
On Tue, Oct 19, 2010 at 10:57 AM, Mike Pfaiffer <high.res.mike@gmail.com> wrote:
On 10-10-19 10:39 AM, Sean Walberg wrote:
On Tue, Oct 19, 2010 at 10:36 AM, Mike Pfaiffer<high.res.mike@gmail.com wrote:
Then there is their policy of slowing down the entire
connection if
they determine someone is using bittorrent on a LAN (even if the user caps the up and down speeds)
Do you have a source for this? Are you sure it's not because you're starving out your upstream and therefore not able to get ACKs out?
Sean
Give it a try. Grab a movie or something. Use a bittorrent client capable of capping the up and down speed. Ktorrent can do this. See what you can get for both up and down uncapped. Then try running say Firefox and look at its performance. Stop the bittorrent transfer and look at Firefox again in a few minutes. Set up a cap in bittorrent say 10K on both the up and down (bear in mind this is supposed to be a multi-megabit connection). Restart your bittorrent and see what happens with Firefox. You'll notice the bittorrent will transfer to what ever maximum you set while other programs will barely function on the internet. Local transfers on the LAN are fine though.
Later Mike
_______________________________________________ Roundtable mailing list Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
-- John Lange www.johnlange.ca
_______________________________________________ Roundtable mailing list Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
_______________________________________________ Roundtable mailing list Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
-- Sean Walberg <sean@ertw.com> http://ertw.com/
When the loss occurs it's all the way from hop 1 to the far end. They've used the "ICMP is at a lower priority" excuse before. It doesn't hold much water with me because that is essentially just an admission that the router is overload and has to start dropping stuff which would be fine if only ICMP got dropped but the packet loss is also happening on voice traffic. John On Tue, Oct 19, 2010 at 11:17 AM, Adam Thompson <athompso@athompso.net> wrote:
If MTR shows loss at hop 1 but *not* at hop 2, that's just their router ignoring your ICMP packets and doesn't actually indicate packet loss.
*sigh* I can't believe I'm defending Shaw...
-Adam
-----Original Message----- From: John Lange <john@johnlange.ca> Sender: roundtable-bounces@muug.mb.ca Date: Tue, 19 Oct 2010 11:14:16 To: Continuation of Round Table discussion<roundtable@muug.mb.ca> Reply-To: Continuation of Round Table discussion <roundtable@muug.mb.ca> Subject: Re: [RndTbl] Shaw packet loss
Just for reference; I use mtr for testing this.
Here is the command line. As you can see, I've set a very aggressive packet rate (20/second).
# mtr -r -w -c 500 -n -i 0.05 www.google.ca
I actually stick it in a loop so I can keep it running and see periodic results:
# while true ; do date ; mtr -r -w -c 500 -n -i 0.05 www.google.ca ; done
When I see loss, it's always at the first hop yet it doesn't seem to matter which gateway it is. These are all Shaw business customers so may not be affecting residential.
John
On Tue, Oct 19, 2010 at 10:57 AM, Mike Pfaiffer <high.res.mike@gmail.com> wrote:
On 10-10-19 10:39 AM, Sean Walberg wrote:
On Tue, Oct 19, 2010 at 10:36 AM, Mike Pfaiffer<high.res.mike@gmail.com>wrote:
Then there is their policy of slowing down the entire connection if they determine someone is using bittorrent on a LAN (even if the user caps the up and down speeds)
Do you have a source for this? Are you sure it's not because you're starving out your upstream and therefore not able to get ACKs out?
Sean
Give it a try. Grab a movie or something. Use a bittorrent client capable of capping the up and down speed. Ktorrent can do this. See what you can get for both up and down uncapped. Then try running say Firefox and look at its performance. Stop the bittorrent transfer and look at Firefox again in a few minutes. Set up a cap in bittorrent say 10K on both the up and down (bear in mind this is supposed to be a multi-megabit connection). Restart your bittorrent and see what happens with Firefox. You'll notice the bittorrent will transfer to what ever maximum you set while other programs will barely function on the internet. Local transfers on the LAN are fine though.
Later Mike
_______________________________________________ Roundtable mailing list Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
-- John Lange www.johnlange.ca
_______________________________________________ Roundtable mailing list Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
_______________________________________________ Roundtable mailing list Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
-- John Lange www.johnlange.ca
It's not unreasonable to put rate limits on inbound ICMP traffic going to the control plane of the router. But the VoIP loss is unacceptable, I agree. Sean On Tue, Oct 19, 2010 at 12:00 PM, John Lange <john@johnlange.ca> wrote:
When the loss occurs it's all the way from hop 1 to the far end.
They've used the "ICMP is at a lower priority" excuse before. It doesn't hold much water with me because that is essentially just an admission that the router is overload and has to start dropping stuff which would be fine if only ICMP got dropped but the packet loss is also happening on voice traffic.
John
On Tue, Oct 19, 2010 at 11:17 AM, Adam Thompson <athompso@athompso.net> wrote:
If MTR shows loss at hop 1 but *not* at hop 2, that's just their router ignoring your ICMP packets and doesn't actually indicate packet loss.
*sigh* I can't believe I'm defending Shaw...
-Adam
-----Original Message----- From: John Lange <john@johnlange.ca> Sender: roundtable-bounces@muug.mb.ca Date: Tue, 19 Oct 2010 11:14:16 To: Continuation of Round Table discussion<roundtable@muug.mb.ca> Reply-To: Continuation of Round Table discussion <roundtable@muug.mb.ca> Subject: Re: [RndTbl] Shaw packet loss
Just for reference; I use mtr for testing this.
Here is the command line. As you can see, I've set a very aggressive packet rate (20/second).
# mtr -r -w -c 500 -n -i 0.05 www.google.ca
I actually stick it in a loop so I can keep it running and see periodic results:
# while true ; do date ; mtr -r -w -c 500 -n -i 0.05 www.google.ca ; done
When I see loss, it's always at the first hop yet it doesn't seem to matter which gateway it is. These are all Shaw business customers so may not be affecting residential.
John
On Tue, Oct 19, 2010 at 10:57 AM, Mike Pfaiffer <high.res.mike@gmail.com> wrote:
On 10-10-19 10:39 AM, Sean Walberg wrote:
On Tue, Oct 19, 2010 at 10:36 AM, Mike Pfaiffer< high.res.mike@gmail.com>wrote:
Then there is their policy of slowing down the entire
connection if
they determine someone is using bittorrent on a LAN (even if the user caps the up and down speeds)
Do you have a source for this? Are you sure it's not because you're starving out your upstream and therefore not able to get ACKs out?
Sean
Give it a try. Grab a movie or something. Use a bittorrent client capable of capping the up and down speed. Ktorrent can do this. See what you can get for both up and down uncapped. Then try running say Firefox and look at its performance. Stop the bittorrent transfer and look at Firefox again in a few minutes. Set up a cap in bittorrent say 10K on both the up and down (bear in mind this is supposed to be a multi-megabit connection). Restart your bittorrent and see what happens with Firefox. You'll notice the bittorrent will transfer to what ever maximum you set while other programs will barely function on the internet. Local transfers on the LAN are fine though.
Later Mike
_______________________________________________ Roundtable mailing list Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
-- John Lange www.johnlange.ca
_______________________________________________ Roundtable mailing list Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
_______________________________________________ Roundtable mailing list Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
-- John Lange www.johnlange.ca
_______________________________________________ Roundtable mailing list Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
-- Sean Walberg <sean@ertw.com> http://ertw.com/
I agree. Packet loss happens on all traffic, not just ICMP. Gerald ----- Original Message ----- From: "John Lange" <john@johnlange.ca> To: athompso@athompso.net, "Continuation of Round Table discussion" <roundtable@muug.mb.ca> Sent: Tuesday, October 19, 2010 12:00:07 PM Subject: Re: [RndTbl] Shaw packet loss When the loss occurs it's all the way from hop 1 to the far end. They've used the "ICMP is at a lower priority" excuse before. It doesn't hold much water with me because that is essentially just an admission that the router is overload and has to start dropping stuff which would be fine if only ICMP got dropped but the packet loss is also happening on voice traffic. John On Tue, Oct 19, 2010 at 11:17 AM, Adam Thompson <athompso@athompso.net> wrote:
If MTR shows loss at hop 1 but *not* at hop 2, that's just their router ignoring your ICMP packets and doesn't actually indicate packet loss.
*sigh* I can't believe I'm defending Shaw...
-Adam
-----Original Message----- From: John Lange <john@johnlange.ca> Sender: roundtable-bounces@muug.mb.ca Date: Tue, 19 Oct 2010 11:14:16 To: Continuation of Round Table discussion<roundtable@muug.mb.ca> Reply-To: Continuation of Round Table discussion <roundtable@muug.mb.ca> Subject: Re: [RndTbl] Shaw packet loss
Just for reference; I use mtr for testing this.
Here is the command line. As you can see, I've set a very aggressive packet rate (20/second).
# mtr -r -w -c 500 -n -i 0.05 www.google.ca
I actually stick it in a loop so I can keep it running and see periodic results:
# while true ; do date ; mtr -r -w -c 500 -n -i 0.05 www.google.ca ; done
When I see loss, it's always at the first hop yet it doesn't seem to matter which gateway it is. These are all Shaw business customers so may not be affecting residential.
John
On Tue, Oct 19, 2010 at 10:57 AM, Mike Pfaiffer <high.res.mike@gmail.com> wrote:
On 10-10-19 10:39 AM, Sean Walberg wrote:
On Tue, Oct 19, 2010 at 10:36 AM, Mike Pfaiffer<high.res.mike@gmail.com>wrote:
Then there is their policy of slowing down the entire connection if they determine someone is using bittorrent on a LAN (even if the user caps the up and down speeds)
Do you have a source for this? Are you sure it's not because you're starving out your upstream and therefore not able to get ACKs out?
Sean
Give it a try. Grab a movie or something. Use a bittorrent client capable of capping the up and down speed. Ktorrent can do this. See what you can get for both up and down uncapped. Then try running say Firefox and look at its performance. Stop the bittorrent transfer and look at Firefox again in a few minutes. Set up a cap in bittorrent say 10K on both the up and down (bear in mind this is supposed to be a multi-megabit connection). Restart your bittorrent and see what happens with Firefox. You'll notice the bittorrent will transfer to what ever maximum you set while other programs will barely function on the internet. Local transfers on the LAN are fine though.
Later Mike
_______________________________________________ Roundtable mailing list Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
-- John Lange www.johnlange.ca
_______________________________________________ Roundtable mailing list Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
_______________________________________________ Roundtable mailing list Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
-- John Lange www.johnlange.ca _______________________________________________ Roundtable mailing list Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
Just a side note on the shaping; the CRTC now requires that ISPs disclose their traffic shaping policy. You could request that Shaw give you that information and when they don't, take the complaint to the CRTC. Of course it will be a wast of time but I'd actually like someone to go through the process just to see if the CRTC ruling has had any effect. I just have not had any time to do this myself. John On Tue, Oct 19, 2010 at 10:57 AM, Mike Pfaiffer <high.res.mike@gmail.com> wrote:
On 10-10-19 10:39 AM, Sean Walberg wrote:
On Tue, Oct 19, 2010 at 10:36 AM, Mike Pfaiffer<high.res.mike@gmail.com>wrote:
Then there is their policy of slowing down the entire connection if they determine someone is using bittorrent on a LAN (even if the user caps the up and down speeds)
Do you have a source for this? Are you sure it's not because you're starving out your upstream and therefore not able to get ACKs out?
Sean
Give it a try. Grab a movie or something. Use a bittorrent client capable of capping the up and down speed. Ktorrent can do this. See what you can get for both up and down uncapped. Then try running say Firefox and look at its performance. Stop the bittorrent transfer and look at Firefox again in a few minutes. Set up a cap in bittorrent say 10K on both the up and down (bear in mind this is supposed to be a multi-megabit connection). Restart your bittorrent and see what happens with Firefox. You'll notice the bittorrent will transfer to what ever maximum you set while other programs will barely function on the internet. Local transfers on the LAN are fine though.
Later Mike
_______________________________________________ Roundtable mailing list Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
-- John Lange www.johnlange.ca
You mean http://www.shaw.ca/en-ca/AboutShaw/TermsofUse/AcceptableUsePolicyInternet.ht... <http://www.shaw.ca/en-ca/AboutShaw/TermsofUse/AcceptableUsePolicyInternet.htm#traffic>? :P Sean On Tue, Oct 19, 2010 at 11:18 AM, John Lange <john@johnlange.ca> wrote:
Just a side note on the shaping; the CRTC now requires that ISPs disclose their traffic shaping policy. You could request that Shaw give you that information and when they don't, take the complaint to the CRTC. Of course it will be a wast of time but I'd actually like someone to go through the process just to see if the CRTC ruling has had any effect.
I just have not had any time to do this myself.
John
On Tue, Oct 19, 2010 at 10:57 AM, Mike Pfaiffer <high.res.mike@gmail.com> wrote:
On 10-10-19 10:39 AM, Sean Walberg wrote:
On Tue, Oct 19, 2010 at 10:36 AM, Mike Pfaiffer<high.res.mike@gmail.com wrote:
Then there is their policy of slowing down the entire
connection if
they determine someone is using bittorrent on a LAN (even if the user caps the up and down speeds)
Do you have a source for this? Are you sure it's not because you're starving out your upstream and therefore not able to get ACKs out?
Sean
Give it a try. Grab a movie or something. Use a bittorrent client capable of capping the up and down speed. Ktorrent can do this. See what you can get for both up and down uncapped. Then try running say Firefox and look at its performance. Stop the bittorrent transfer and look at Firefox again in a few minutes. Set up a cap in bittorrent say 10K on both the up and down (bear in mind this is supposed to be a multi-megabit connection). Restart your bittorrent and see what happens with Firefox. You'll notice the bittorrent will transfer to what ever maximum you set while other programs will barely function on the internet. Local transfers on the LAN are fine though.
Later Mike
_______________________________________________ Roundtable mailing list Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
-- John Lange www.johnlange.ca
_______________________________________________ Roundtable mailing list Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
-- Sean Walberg <sean@ertw.com> http://ertw.com/
participants (5)
-
Adam Thompson -
Gerald Brandt -
John Lange -
Mike Pfaiffer -
Sean Walberg