<div class="gmail_quote">On Tue, Oct 19, 2010 at 10:57 AM, Mike Pfaiffer <span dir="ltr"><<a href="mailto:high.res.mike@gmail.com">high.res.mike@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"> Give it a try. Grab a movie or something. Use a bittorrent client</div>
capable of capping the up and down speed. Ktorrent can do this. See what<br>
you can get for both up and down uncapped. Then try running say Firefox<br>
and look at its performance. Stop the bittorrent transfer and look at<br>
Firefox again in a few minutes. Set up a cap in bittorrent say 10K on<br>
both the up and down (bear in mind this is supposed to be a<br>
multi-megabit connection). Restart your bittorrent and see what happens<br>
with Firefox. You'll notice the bittorrent will transfer to what ever<br>
maximum you set while other programs will barely function on the<br>
internet. Local transfers on the LAN are fine though.</blockquote><div> </div><div>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.</div>
<div><br></div><div>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.</div><div><br></div><div>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?</div>
<div><br></div><div>Sean</div><div> </div></div><br>-- <br>Sean Walberg <<a href="mailto:sean@ertw.com">sean@ertw.com</a>> <a href="http://ertw.com/">http://ertw.com/</a><br>