Would you mind then explain me why when I try to push and download a file to my NJ server using the default utorrent port I get a max transfer rate of 5-10 kbps, when I switchh the port to the same port used by windows update or ssh then the transfer rate jumps to 4mbps down and stick there for as long as I let it...???
More so... I tested a torrent download using default ports and it would jump to 4mbps then within 1 minute it to drop to 5-10kbps I just switched the port and watched it jump back to 4mbps to fall again 60 seconds later to 5-10 kbps so I used one of my US servers running on a OC4 to act as a proxy and encrypted the data between my machines and the server and proxies through it running 2 instance of utorrent one through the proxy and the other straight to the net...
The "undetectable" tunneled connection downloaded at 4mbps steady while the other couldn't get pass 10kbps after 10 minutes. DONT tell me it was the hosts I was downloading from they were both downloading from the same sources at the same time only one was undetectable to traffic shapping software and the other was... both were fired from the same machine using the same firewall settings on linux. I have 4 monitors running from the same machine and one is dedicated as security console I run SNORT IDS and real time traffic monitoring I see packets by packets what come in and out of my house network and machines I have no virus or anything that could cause interference beside and exterior source such as traffic shapping...
So I went and used various fun tools I have to detect shaping and here's something fun... What do you know first test I run...
My 30mbps connection is throttle of 32mbps for P2P traffic... While other traffic when through perfectly fine... DO NOT tell us your not throttling...
I work for a major canadian ISP myself and I speak to about 20 rogers customers a night that use hour VOIP services and I WILL have them ALL run this test and gather the results to log a complaint to the CRTC within 5 business days if now rectified.
DiffProbe release. January 2012. Build 1008.
Shaper Detection Module.
Connected to server 18.104.22.168.
Upstream: 10153 Kbps.
Downstream: 198713 Kbps.
The measurement will take upto 3.0 minutes. Please wait.
Checking for traffic shapers:
Upstream: No shaper detected.
Median received rate: 9930 Kbps.
Downstream: Burst size: 18758-20638 KB;
Shaping rate: 32984 Kbps.
Hi jdunphy, we phased out traffic management on P2P filesharing in December 2012. If you want to provide more specifics on which ports you're using, I'll share this with our network team and ask them to take a look. I assume you're using our Rogers Hi Speed internet product, correct?
jdunphy, i did run the tool (before the link was removed.. not sure why...)
Ran it on my connection here.
I am on the 25/2 internet connection
Showed upstream at 2.1 (so correct), and downstream burstable 9-101.
It DID show shaping.. but shaping to 27.. so shaping it down, to what my regular internet level to be from its max burstable level.
This seems to be the common theme here - anytime someone has any problem where their internet connection isn't working exactly as they think it should they assume Rogers is traffic shaping.
In the end these threads always end up in the same place - user or transient error.
I mean, its not to say that rogers doesnt have issues.... people run into things like CONGESTION, etc.. where their connection can slow down to a CRAWL for even webpages, etc..
And while these are things that rogers definately should fix... there are people who have complained of traffic shaping, etc for it.
its VERY unlikely to be shaping.. and more usually ANOTHER rogers problem slowing it down.
(or as you said.. transiant error... a problem along the way. I help out on the WoW forums sometimes.. and the number of time you see someone complaining of LAG in the game.. they blame BLIZZARD. Analysing tracerts, pathping, etc.. usually leads to be either ISP.. or a NODE somewhere inbetween. There is nothing that the ISP or endpoint can really do in the end then, short of changing ALL the routing statements to avoid that node)
Agreed - I would say the first thing to do is to test that same file between someone with a local FTP server - If that works, it would be something way upstream that's causing things to drop.