A little preface. Recently I switched my isp to the fastest one available here (advertised speed is "up to 300 Mb/s" both ways). While at the speedtest.net I can easily get impressive numbers like 800 Mb/s down & 900 Mb/s up it's not that great when it comes to the real world usage. I noticed a strange/peculiar pattern: when downloading from p2p networks throughput may be floating around 50 MB/s (over 400 Mbit/s) provided there's enough fast sources (regardless of their geographical location). "Enough" means roughly the following: while every single connection seems to be capped at ~1 MB/s if there are 50 sources I get ~50 MB/s. However fast this may sound there's one big downside: single connection can never be as fast. I was able to squeeze 10-13 MB/s while downloading from my 1 Gb/s VPS (most of the time it's 4-5 MB/s). So I was trying to figure it out, and after a lot of googling and tinkering with TCP, registry settings (Windows 8.1 here) with little to no effect I decided it would be more insightful and efficient to monitor my connection with some sniffing tool. So I captured my ftp downloading session. Originally I thought my situation must have something to do with RWIN, but TCP StreamGraph > Window Scaling Graph showed me straight horizontal line at 1048576 (all ACK packets from my side have this size listed). As the side note: when I go to Statistics > IO graph and plot tcp.window_size filter I get different result: with tick interval being 0.01s line becomes very jagged, drops to 0 constantly, teeth go up to 100000~250000 bytes/s (at the start and at the end they are higher than in the middle); with tick interval being 1s it's still not straight, rising and falling edges go up to 6000000 bytes/s with the middle being sank up to ~3000000 bytes/s. So why the difference and which one is correct? Another bad thing I noticed was many DUP ACK (some dupes go up to ridiculous numbers like ~#200), Out-Of-Order and Previous Segment not Captured messages, like every 100-200 packets. So I presume it testifies to some serious packet loss during transfer. So could it be that this is my isp is trying to throttle my fast single connections? And may be there are additional things Wireshark could help me to spot before I give them a call and call out this nonsense? asked 11 May '15, 15:46  Joo |
One Answer:
You can't (reliably) detect ISP throttling with a capture file taken at the client only, because you will never know who/what is causing packet loss (retransmissions in the capture file). The only reliable option is to run a test with a server you own (like on rented in the cloud). See here for some ideas: Regards answered 12 May '15, 06:21  Kurt Knochner ♦ edited 12 May '15, 06:23 Thanks for the link. Unfortunately I was unable to make Switzerland work on my home PC. I did some tests listed at http://www.measurementlab.net/ (half of them do not work either), didn't really provide any additional info. As far as I understand, specific protocol traffic shaping should affect overall throughput with this protocol, not just a single connection. Oh, well, I should probably call their support. (12 May '15, 17:12) Joo
good idea. I had cases, where they simply forgot/overlooked a setting on their router, that was not intended to be there for that customer. (13 May '15, 05:39) Kurt Knochner ♦ |
Have you tried Glasnost?
Thanks for the suggestion. I did, however it haven't detected any traffic shaping. though I was unable to complete SSH and Flash Video tests, also it complained about some measurements were affected by noise during several runs.