From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.54) id 1FQS4S-0001fT-TA for garchives@archives.gentoo.org; Mon, 03 Apr 2006 16:38:29 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.6/8.13.5) with SMTP id k33GZGNm011580; Mon, 3 Apr 2006 16:35:16 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.6/8.13.5) with ESMTP id k33GHUld022424 for ; Mon, 3 Apr 2006 16:17:30 GMT Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by smtp.gentoo.org with esmtp (Exim 4.54) id 1FQRk9-0002DT-Gd for gentoo-user@lists.gentoo.org; Mon, 03 Apr 2006 16:17:29 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1FQRju-0004iA-BI for gentoo-user@gentoo.org; Mon, 03 Apr 2006 18:17:15 +0200 Received: from www.buffer.net ([24.73.161.102]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 03 Apr 2006 18:17:14 +0200 Received: from wireless by www.buffer.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 03 Apr 2006 18:17:14 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-user@lists.gentoo.org From: James Subject: [gentoo-user] Re: traffic shaping Date: Mon, 3 Apr 2006 16:17:05 +0000 (UTC) Message-ID: References: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@gentoo.org Reply-to: gentoo-user@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: main.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 24.73.161.102 (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060303) Sender: news Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by robin.gentoo.org id k33GZGO6011580 X-Archives-Salt: 827e5824-39a9-4485-9275-95826de675bc X-Archives-Hash: 0d2c63693575a671e9126e2a5915fb20 Sven K=C3=B6hler upb.de> writes: > i would like to shape the traffic of my DSL-connection, but somehow i > never really understood the machanisms that linux offers. All the > scripts i wrote were simply worthless somehow, because they didn't > really improve anything. > Is there any application or script that is easy to configure and does > all the necessary things to shape my DSL traffic? First you need really good network management and monitoring. Nagios, big brother, and Jffnms are just a few of the choices (jffnms is my choic= e) and an ebuild is available. Network monitoring will ensure you do not hav= e=20 any bottlenecks behind your ADSL connection. The first/best thing you=20 can do is to monitor your internal traffic, to figure out where you need=20 to concentrate (hardware and protocols). Then you optimize your firewall/bridge/router to what works best for you. Last you look external, to optimize what you are getting and see if what=20 you are doing can be 'outsourced' like DNS services. Having multiple=20 secondary dns servers, strategically located around the internet can=20 be a big help, particually if you are serving up lots of small datagrams=20 to a large variety of web-surfers.=20 You may also be able to pay the carrier/provider some more money and get more bandwidth. Inquire about CIR or Commited=20 Information Rate (guaranteed bandwidth) as some aDSL providers will=20 increase this setting, for a few extra dollars per month. Many=20 aDSL providers have greatly over subscribed their connection from their interexchange points (where they hand off=20 internet traffic to other networks). These problems are difficult to=20 diagnose, and may be transient. Other aDSL providers such as large=20 brain-dead carriers set the CIR to Zero, thus giving everyone great bandwidth(reletively) but then during peak demand their networks clog wil= l collisions. Unfortunately, particulary here in the US, the carriers=20 are quite stupid and have 'pink slipped' most of their computer scientist= s=20 and electrical engineers, and they have hired more sales, marketing and data-base weenies.... Lots of folks that do not know anything about communications. aDSL suffers form another unique hardware problem. The current=20 ( available power) is limited if you are in a wire bundle that is=20 carrying lots of aDSL or digital information. Often, when somebody orders= a service, such as aDSL or ISDN, the tech sorts thru the cable pairs at the terminal blocks down the street and finds the cleanest pairs for the=20 new circuit. They migrate the olders services to 'wiring pairs' of lesser quality. Often the problem is due to corrosion on the terminal blocks. Th= e bottom line is these carriers are full of idiots and persons not=20 qualified to run a network. Here in the US, we're down to 3 carriers, and they all SUCK. If these idiots can't maintain their wiring infrastructure, will you trust them to run swithes, routers and DACs? Many of these carriers are plagued by swams of critical service= s that run on the MicroSuck operating system..... I finally tracked down a problem with my cable modem bandwidth to the RG-= 59 cable from my home to the terminal block. The dB reading were horribly lo= w. I had to supply RG-6 (better grade of coax) cable to the technician=20 because the cable company is too cheap, stupid, and has no competition.=20 If you are nice to the technicians some of them will help you=20 'off the record'. If helps if you can develop a business/personal=20 relationship with the tech and the persons that run the equipment. (I digress much... but this hits a nerve with me....) There=20 is absolutely nothing wrong with aDSL, except the idiot managers that runs these global communications companies and their=20 consistent string of bad decisions. Monitoring the Internet, is not a bad idea, if you have the time. I can't remember the name of the software, but it is burried somewhere in the=20 NANOG archives.... If what you find is outmoded (based on something like traceroute) then just find a good security hacking site, as those guys=20 stay up on the latest in global network monitoring.... Outside bandwidth testing is possible via these sites: http://www.speakeasy.net/speedtest/ http://web.tampabay.rr.com/giis/ http://www.dslreports.com/stest Many others exist; take these results, with caution as to the accuracy and validity. This is a deep subject, that is affected by many things. If you build you= r own router on a 2.6 linux kernel, there are many things to consider and=20 test.=20 Beside how you implement your firewall/bride/router rules, there are=20 other things you can adjust, under the Networking:QoS and fair queuing,=20 when you build thekernel for your primary device connected to the aDSL connection. PPPoE can be problematic (i.e. not very efficient) if the=20 aDSL carrier has a poor implementation or overloaded the resources on=20 their side. The simple solution, is to 'pony up more cash per month' to your aDSL carrier, or find another bandwidth supplier (if that an option). You might also have a wireless internet operator in your area.=20 Depending on your network you may be able to migrate/split your traffic=20 across multiple connections....=20 One of the other respondants mentioned HTB, Hardware Token Buckets,=20 which is really a very cool, but a very young technology in Linux. I'm=20 still looking for accurate bandwidth mesuring/monitoring software,=20 based on HTBs: http://luxik.cdi.cz/~devik/qos/htb/manual/theory.htm I refer to them as Hardware Token Buckets, because that's where software, meets hardware, in the general area of firmware. The linux scheduler=20 choices,even RTlinux hacks are actually piss-poor, when you compare=20 their performance to that of state machines or an efficient RTOS. The decision of how a schedulers is implemented in a state machine/RTOS/Kernel effects the performance of what you really want to acheive. Intimate knowledge of the underlying hardware (processor) is the key to efficient implementation of schedulers and HTBs. Many of the developers working on providing HTBs in=20 Linux, really need help from real hardware engineers..... But=20 eventually, the implementation of HTBs will be mastered by the=20 linux kernel folks...... Obviously a stong, jaded opinion, apologies in advance to all I have offended, with these truths..... HTH, James --=20 gentoo-user@gentoo.org mailing list