From owner-freebsd-questions@FreeBSD.ORG Mon Feb 4 21:49:16 2008 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1CA616A419 for ; Mon, 4 Feb 2008 21:49:16 +0000 (UTC) (envelope-from tundra@tundraware.com) Received: from ozzie.tundraware.com (ozzie.tundraware.com [75.145.138.73]) by mx1.freebsd.org (Postfix) with ESMTP id 9ED6113C46E for ; Mon, 4 Feb 2008 21:49:16 +0000 (UTC) (envelope-from tundra@tundraware.com) Received: from [127.0.0.1] (ozzie.tundraware.com [75.145.138.73]) (authenticated bits=0) by ozzie.tundraware.com (8.14.2/8.14.2) with ESMTP id m14Ln86u057565 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Mon, 4 Feb 2008 15:49:12 -0600 (CST) (envelope-from tundra@tundraware.com) Message-ID: <47A78854.701@tundraware.com> Date: Mon, 04 Feb 2008 15:49:08 -0600 From: Tim Daneliuk Organization: TundraWare Inc. User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: David Banning , FreeBSD Mailing List References: <20080204200151.GA16540@skytracker.ca> In-Reply-To: <20080204200151.GA16540@skytracker.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-tundraware.com-MailScanner-Information: Please contact the ISP for more information X-tundraware.com-MailScanner: Found to be clean X-tundraware.com-MailScanner-From: tundra@tundraware.com X-Spam-Status: No Cc: Subject: Re: question on DSL signal X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tundra@tundraware.com List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2008 21:49:17 -0000 David Banning wrote: e drop-in drop-out problem. > > To any average computer user, these lines might appear normal - > when a page stops loading for a minute they just live with it, and > forget about it. > > So here's my question: > > 1. is there anyone who has a lot of experience monitoring DSL lines > that can tell me how common this is? I cannot speak to the frequency of connection loss, but I have seen huge variability (over months) in *speed* if the premise is far away/at the limit of the DSL connection distance. DSL is quite fussy about the distance between the CPE and the phone company CO locations. But "distance" here is logical or electrical distance - almost always greater than straightline between the CO and the premsise. Why? Because phone company lines run in raceways (usually underground) that do not take the shortest path. Moreover, as construction and other changes in the neighborhood mandate, trunks are changed, lines spliced, pairs moved and so on. So... the "electrical" distance from CO to premise is typically further than the straight distance. This constant fiddling with the phone company infrastructure causes all manner of sins including intermittent electrical noise, disconnection, modem retraining, and just plain poor signal-to-noise ratio. And - in my experience - it can vary all over the place, from as low as 30% to 100% of claimed channel capacity. Welcome to DSL - where you are once again at the mercy of the phone company. > 2. Is there any way to avoid it? Yes - switch to different fabric. I live near a large metro area, and the local cable company finally figured out that there was money to be made offering their very fast/reliable cable service to businesses. For $10/mo *less* than I was paying for 1.5/384 DSL with 8 static IPs, I now get 6.0/1.5 w/5 static IPs from Comcast. My only regret is that I could not continue to do business with Speakeasy, which is hands down the best ISP I've ever seen. The Comcast package has thus far (about 4 months) been flawless. They have a separate support group for business customers, they handled my reverse DNS perfectly and promptly, and - if I remain on the local backbone for testing - the system actually peaks to over 20Mb/sec. If you're not too far away from the CO you can try adsl2, but if your copper is lousy for dsl, it will be lousy for that as well. The real answer is to get your ISP to light the fires under their phone company provider and make them fix their copper properly. Good luck with that. The phone company - at least in the US - isn't particularly obligated to make DSL work. They only have to hit some signal-to-noise standard. After that, it's up to your DSL provider to make it happen. > > 3. I have used three different DSL modems, but the are all home > quality: an Alcatel Speed Touch, a Speedstream 5260, > and a Westell Wirespeed. Would spending more money on > another type of modem help? If so, what is recommended? Maybe not more money, but trying different devices can help. The Broadext modems I used were twice the speed of the old Speedstreams on the same circuit. Newer chipsets should be more noise immune, but they cannot fix lousy copper in the phone system. > > Any comments would be helpful. One other thing to check. There should be a grounding wire coming off the NID (the box on the side of the building where the phone co terminates their copper). The wire is typically clamped to a stake in the ground. Make sure that the wire/stake surfaces are clean, and the clamp is tight to ensure the best possible earth ground connection. Once you cleaned/tightened this, it's not a bad idea to cover it with grease to keep moisture out. A small bit of electrical resistance on an earth ground can translate into very nasty noise spikes when there is an inductive noise source (like an electrical motor starting) somewhere near you. Good luck. The phone company was built around a voice model with a 300-3000 Hz bandwidth design criteria. That's been vastly improved as the phone backbones went all digital in the past 40 years, BUT, the "last mile" copper is/was the last thing to change. Oddly, even when they build new buildings (as was the case in my premise), they often don't do a great job with the copper. P.S. If all else fails, there's satellite and/or cellular internet. However, these are both rather expensive, not that fast, and have significant latency problems. Latency isn't that big a deal for data downloads, but it rears its ugly head when you want to stream audio/video or any other kind of quasi "real time" data. I feel your pain ;)