Hey Ron,<br><br>If you like, I can lend my 20x3M comcast line to you for testing. I can throw up an quick knoppix box and you can test away with your own shell. Its not really being used (except for me checking emails). Its a Walking Dead marathon today, so I doubt I will get any real work done.<br>
<br>Hit me off list for IP and login details.<br><br>-Erik-<br><br><br>
<div class="gmail_quote">On Sat, Jul 7, 2012 at 2:56 PM, Ron Frazier (ALE) <span dir="ltr"><<a href="mailto:atllinuxenthinfo@techstarship.com" target="_blank">atllinuxenthinfo@techstarship.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>
Hi Erik,<br>
<br>
I haven't had a chance to do any testing. I'm not sure if I even can. Here machine runs Windows and is a locked down corporate computer that I have little access to. I can't install anything without their permission. I know some of her coworkers have been complaining, so I know that the problem is often on their side of the fence. I just wanted to eliminate any possible hitches on my end. My routers are basic off the shelf Netgear boxes. They have very little in the way of configuration settings. My machines are sometimes running Windows and sometimes Linux, but they don't have any visibility into her data traffic.<br>
<br>
She runs a citrix remote desktop system. So, she is viewing the video output of a remote system at all times. Presumably, this generates a fair amount of continuous time sensitive data traffic. Every mouse click she makes, every move she makes in the program she's running is sent to the remote system and the results are sent back. If the connection is disrupted for more than a second or so, her system complains about it. At this point, I cannot tell if my changes have made any substantial difference. They were more of a preemptive change, to sort of head off any local problems before they happen. If I come up with any notable results, or any viable way to test things, I'll certainly be glad to share.<br>
<br>
Here's something you can do to test the latencies on your own network.<br>
<br>
There's a tool called Netalyzr that's put out by the International Computer Science Institute at Berkeley. You will have to trust Berkeley and turn on javascript for this to work. This performs VERY extensive testing on your network and reports some findings to their study.<br>
<br>
<a href="http://netalyzr.icsi.berkeley.edu/index.html" target="_blank">http://netalyzr.icsi.berkeley.edu/index.html</a><br>
<br>
Here's something else which you could try. Turn off all QOS or traffic shaping systems on your router closest to the internet, and on any other routers or switches between your PC and the internet. Try to upload a really big file, like multiple GB to dropbox or something. While that's uploading, try to download another large file at the same time, say an ISO or something. The upload can disrupt the download because the ACK packets going back upstream may have a hard time getting through. You could also try a VOIP call or some gaming, etc. while the upload is in progress. If the testing with large downloads, VOIP, or gaming fails, it's probably because you have some large buffers somewhere and because they're getting full. If those tests don't fail, you may not have large buffers, or there may be traffic shaping going on that you don't know about, maybe in the cable modem. Again, I don't know about all the nitty gritty details of TCP/IP throttling, so I'm not an expert on the topic.<br>
<br>
Good luck. Let us know if you find out anything new for your network.<br>
<br>
Sincerely,<br>
<br>
Ron<div><br>
<br>
<br>
--<br>
<br>
Sent from my Android Acer A500 tablet with bluetooth keyboard and K-9 Mail.<br>
Please excuse my potential brevity.<br>
<br>
(To whom it may concern. My email address has changed. Replying to former<br>
messages prior to 03/31/12 with my personal address will go to the wrong<br>
address. Please send all personal correspondence to the new address.)<br>
<br>
(PS - If you email me and don't get a quick response, you might want to<br>
call on the phone. I get about 300 emails per day from alternate energy<br>
mailing lists and such. I don't always see new email messages very quickly.)<br>
<br>
Ron Frazier<br>
<a href="tel:770-205-9422" value="+17702059422" target="_blank">770-205-9422</a> (O) Leave a message.<br>
linuxdude AT <a href="http://techstarship.com" target="_blank">techstarship.com</a><br>
<br><br></div><div><div><div class="gmail_quote">Erik Mathis <<a href="mailto:erik@mathists.com" target="_blank">erik@mathists.com</a>> wrote:<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I was wondering if you had done any pre/post iperf (or something smiler) testing? If so, can you share the results?<br><br>-Erik- <br><br><div class="gmail_quote">On Fri, Jul 6, 2012 at 5:13 PM, Ron Frazier (ALE) <span dir="ltr"><<a href="mailto:atllinuxenthinfo@techstarship.com" target="_blank">atllinuxenthinfo@techstarship.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
I want to share some information about a phenomenon which can dramatically slow down your internet connection, or connections within a LAN some times. It's called buffer bloat. I first heard about it over on the NTP questions list. I don't remember why that came up, probably related to network latencies for NTP servers. Then, later, Steve Gibson discussed it on the Security Now podcast. I've provided several links below for those who wish to research it.<br>
<br>
For those not familiar, buffer refers to a memory queue in a router or other networking gear. The problem occurs when you go from a large bandwidth pipe to a smaller bandwidth pipe, such as the transition from your LAN to the internet WAN. At this point, you might go from 100 Mbps or 1 Gbps bandwidth to something like 3 Mbps or 20 Mbps or 50 Mbps or whatever. The point is, that it is a dramatic reduction in bandwidth.<br>
<br>
So, if you're trying to transmit to the internet at 100 Mbps and it can only take 20 Mbps, the link will become saturated. Without buffers or queues, about 4/5 of the packets will be dropped. The system will rapidly recognize that it cannot go that fast and it will scale down to something which the link can support.<br>
<br>
However, with large buffers, which many routers have, the problem becomes much worse. Let's say the router has a 4 M Byte or approximately 40 M bit ram buffer on it's outbound transmission channel. Your computer fills that buffer in about 4/10 sec, but, that buffer is going to take 2 sec to empty out sending the data to the internet. While I don't understand all the technical magic that happens, I do understand that the normal automatic throttling systems no longer work. So, your computer might be seeing a 2 sec delay to get packets out on the internet while they meander through the buffer on a first in first out basis.<br>
<br>
There is a new intelligent packet dropping algorithm called CODEL that may be the solution. The bufferbloat site mentions it, and Steve did a podcast talking about it. It shows great promise, however, most routers don't implement the algorithm, and many probably never will get upgraded, including many home routers.<br>
<br>
So, here, as I understand it, is a way you can work around the problem.<br>
<br>
My wife works from home sometimes and uses a VPN back to work. Sometimes, here system locks up and says the connection is lost. I have as many as 7 devices sharing the same internet connection, so her system may be experiencing congestion. I suspect that many times, the problem is on the other end at her office, but just in case, I decided to tweak the router. I turned on a QOS (quality of service) setting and told it to prioritize her data traffic over mine. I also made some changes to avoid any possible buffer bloat problem.<br>
<br>
The buffer bloat problem only shows up when the buffer fills. By the way, a clogged upstream buffer can shut down downloads too, since, during downloads, all tcp packets have to be acknowledged, and those acknowledgements must go upstream. A clogged buffer can essentially make your Internet connection almost unusable. I think this is what happens at many coffee shops. If you can't run CODEL or something like it, one way to prevent the problem is to make sure the buffer never fills up. One way to do that is to limit your upstream bandwidth to something less than what it's possible to do. In my case, the QOS menu of the router allows me to limit upstream bandwidth. I used <a href="http://speedtest.net" target="_blank">speedtest.net</a> to test the system. I was able to get a peak upstream bandwidth of 5.6 Mbps. So, I set the QOS controls on the router to limit the upstream bandwidth to 5 Mbps. Theoretically, this should mean that the outbound buffer on my router never will fill up because it's always emptying out faster than I'm putting data in. Theoretically, that should prevent the buffer bloat problem on my LAN. This, combined with prioritization of my wife's data, will hopefully solve her data problems.<br>
<br>
If you've had experience with this problem, please share what you learned and what you did about it.<br>
<br>
If you need info on the down and dirty operation of TCP/IP, ask some of the other wizards on the list.<br>
<br>
Hope this is helpful.<br>
<br>
Sincerely,<br>
<br>
Ron<br>
<br>
links below<br>
<br>
----------------------<br>
<br>
<br>
<a href="http://en.wikipedia.org/wiki/Buffer_bloat" target="_blank">http://en.wikipedia.org/wiki/Buffer_bloat</a><br>
<br>
<a href="http://www.bufferbloat.net" target="_blank">http://www.bufferbloat.net</a>/<br>
<br>
Steve Gibson discusses buffer bloat on the Security Now podcast episode 345.<br>
He introduces a potential solution, CODEL, developed by industry researchers, in episode 359.<br>
<br>
<a href="http://www.grc.com/securitynow.htm" target="_blank">http://www.grc.com/securitynow.htm</a> - Reference episodes 345 and 359.<br>
<br>
<a href="http://twit.tv/show/security-now/345" target="_blank">http://twit.tv/show/security-now/345</a><br>
<a href="http://media.grc.com/sn/sn-345.mp3" target="_blank">http://media.grc.com/sn/sn-345.mp3</a><br>
<br>
<a href="http://twit.tv/show/security-now/359" target="_blank">http://twit.tv/show/security-now/359</a><br>
<a href="http://media.grc.com/sn/sn-359.mp3" target="_blank">http://media.grc.com/sn/sn-359.mp3</a><br>
<br>
<br>
<br>
--<br>
<br>
Sent from my Android Acer A500 tablet with bluetooth keyboard and K-9 Mail.<br>
Please excuse my potential brevity.<br>
<br>
(To whom it may concern. My email address has changed. Replying to former<br>
messages prior to 03/31/12 with my personal address will go to the wrong<br>
address. Please send all personal correspondence to the new address.)<br>
<br>
(PS - If you email me and don't get a quick response, you might want to<br>
call on the phone. I get about 300 emails per day from alternate energy<br>
mailing lists and such. I don't always see new email messages very quickly.)<br>
<br>
Ron Frazier<br>
<a href="tel:770-205-9422" value="+17702059422" target="_blank">770-205-9422</a> (O) Leave a message.<br>
linuxdude AT <a href="http://techstarship.com" target="_blank">techstarship.com</a><br>
<br>_______________________________________________<br>
Ale mailing list<br>
<a href="mailto:Ale@ale.org" target="_blank">Ale@ale.org</a><br>
<a href="http://mail.ale.org/mailman/listinfo/ale" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a href="http://mail.ale.org/mailman/listinfo" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
<br></blockquote></div><br>
</blockquote></div></div></div><br>_______________________________________________<br>
Ale mailing list<br>
<a href="mailto:Ale@ale.org" target="_blank">Ale@ale.org</a><br>
<a href="http://mail.ale.org/mailman/listinfo/ale" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a href="http://mail.ale.org/mailman/listinfo" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
<br></blockquote></div><br>