931 lines
28 KiB
HTML
931 lines
28 KiB
HTML
|
<HTML
|
||
|
><HEAD
|
||
|
><TITLE
|
||
|
>Appendix: FAQ</TITLE
|
||
|
><META
|
||
|
NAME="GENERATOR"
|
||
|
CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
|
||
|
"><LINK
|
||
|
REL="HOME"
|
||
|
TITLE="DSL HOWTO for Linux"
|
||
|
HREF="index.html"><LINK
|
||
|
REL="PREVIOUS"
|
||
|
TITLE="Appendix: DSL Overview"
|
||
|
HREF="overview.html"><LINK
|
||
|
REL="NEXT"
|
||
|
TITLE="Appendix: Miscellaneous"
|
||
|
HREF="appendix.html"></HEAD
|
||
|
><BODY
|
||
|
CLASS="SECT1"
|
||
|
BGCOLOR="#FFFFFF"
|
||
|
TEXT="#000000"
|
||
|
LINK="#0000FF"
|
||
|
VLINK="#840084"
|
||
|
ALINK="#0000FF"
|
||
|
><DIV
|
||
|
CLASS="NAVHEADER"
|
||
|
><TABLE
|
||
|
SUMMARY="Header navigation table"
|
||
|
WIDTH="100%"
|
||
|
BORDER="0"
|
||
|
CELLPADDING="0"
|
||
|
CELLSPACING="0"
|
||
|
><TR
|
||
|
><TH
|
||
|
COLSPAN="3"
|
||
|
ALIGN="center"
|
||
|
>DSL HOWTO for Linux</TH
|
||
|
></TR
|
||
|
><TR
|
||
|
><TD
|
||
|
WIDTH="10%"
|
||
|
ALIGN="left"
|
||
|
VALIGN="bottom"
|
||
|
><A
|
||
|
HREF="overview.html"
|
||
|
ACCESSKEY="P"
|
||
|
>Prev</A
|
||
|
></TD
|
||
|
><TD
|
||
|
WIDTH="80%"
|
||
|
ALIGN="center"
|
||
|
VALIGN="bottom"
|
||
|
></TD
|
||
|
><TD
|
||
|
WIDTH="10%"
|
||
|
ALIGN="right"
|
||
|
VALIGN="bottom"
|
||
|
><A
|
||
|
HREF="appendix.html"
|
||
|
ACCESSKEY="N"
|
||
|
>Next</A
|
||
|
></TD
|
||
|
></TR
|
||
|
></TABLE
|
||
|
><HR
|
||
|
ALIGN="LEFT"
|
||
|
WIDTH="100%"></DIV
|
||
|
><DIV
|
||
|
CLASS="SECT1"
|
||
|
><H1
|
||
|
CLASS="SECT1"
|
||
|
><A
|
||
|
NAME="FAQ">7. Appendix: FAQ</H1
|
||
|
><P
|
||
|
> Some Frequently Asked Questions about DSL and Linux.</P
|
||
|
><P
|
||
|
><P
|
||
|
></P
|
||
|
><OL
|
||
|
TYPE="1"
|
||
|
><LI
|
||
|
><P
|
||
|
> Q. Does DSL work with Linux?
|
||
|
</P
|
||
|
><P
|
||
|
> DSL is a technology, or more correctly, a group of related technologies.
|
||
|
This is akin to asking if Linux works with telephones. The technology
|
||
|
itself does not care. So, the short answer is <SPAN
|
||
|
CLASS="QUOTE"
|
||
|
>"Yes, of
|
||
|
course!"</SPAN
|
||
|
>. The long answer is that if there are any impediments, they
|
||
|
are being imposed by the provider. There are things they may do, that can
|
||
|
make getting Linux up and running, more of a challenge than it needs to be.
|
||
|
Not having a compatible modem option available is one common gotcha. Also,
|
||
|
if the telco or ISP is doing the installation, they may require a Windows
|
||
|
or Mac system to be available. This saves them the costs of training their
|
||
|
techs on various alternative OSes. Buyer beware!
|
||
|
|
||
|
</P
|
||
|
><P
|
||
|
> Basically all DSL does, is facilitate a high speed Internet connection. At
|
||
|
some point, it is all TCP/IP, and Linux, of course, handles TCP/IP quite
|
||
|
well.
|
||
|
|
||
|
</P
|
||
|
></LI
|
||
|
><LI
|
||
|
><P
|
||
|
> Q. Where can I find drivers for my PCI (or USB) modem?
|
||
|
</P
|
||
|
><P
|
||
|
> With a few exceptions, you probably can't, because they are just not
|
||
|
available. Your best bet is an external, ethernet interfaced modem for all
|
||
|
intents and purposes. If your provider does not offer one, you will have
|
||
|
to find another provider, or buy your own modem outright. Just make sure
|
||
|
it is compatible with your provider's flavor of DSL.
|
||
|
</P
|
||
|
><P
|
||
|
> The are exceptions to every rule. See the <A
|
||
|
HREF="appendix.html#MODEMS"
|
||
|
>Modems
|
||
|
Section</A
|
||
|
> for a list of compatible modems as of this writing.
|
||
|
|
||
|
</P
|
||
|
><P
|
||
|
> If an incompatible modem puts you in a bind, hopefully you will take the
|
||
|
time to politely harass the manufacturer ;-).
|
||
|
|
||
|
</P
|
||
|
><P
|
||
|
> This situation is changing for the better. <A
|
||
|
HREF="http://www.xpeed.com"
|
||
|
TARGET="_top"
|
||
|
>Xpeed</A
|
||
|
> now has drivers included in the
|
||
|
kernel for source for their PCI IDSL and SDSL modems. This is good news!
|
||
|
<A
|
||
|
HREF="http://www.alcateldsl.com"
|
||
|
TARGET="_top"
|
||
|
>Alcatel</A
|
||
|
> has
|
||
|
released drivers for the Alcatel SpeedTouch USB ADSL modem. IteX has
|
||
|
also released drivers for their PCI ADSL modem. Hopefully
|
||
|
more will follow suit. (Make sure you are reading the latest version of
|
||
|
this document, as I have intentions of keeping this situation updated as
|
||
|
needed.)
|
||
|
|
||
|
</P
|
||
|
></LI
|
||
|
><LI
|
||
|
><P
|
||
|
> Q. How fast or good of a network card do I need?
|
||
|
</P
|
||
|
><P
|
||
|
> Any card that is compatible with Linux should work fine. Remember even
|
||
|
low-end cards are 10 Mbps, and no consumer class DSL is near that at this
|
||
|
time. I would suggest a reasonably good quality card, just to help
|
||
|
eliminate the possibility of errors and premature failure.
|
||
|
|
||
|
</P
|
||
|
></LI
|
||
|
><LI
|
||
|
><P
|
||
|
> Q. How can I find out when DSL will be available in my area?
|
||
|
</P
|
||
|
><P
|
||
|
> Just where and when DSL gets deployed is totally in the hands of
|
||
|
your friendly local telco. They obviously can't do everyone at
|
||
|
once, so they probably are selecting areas based on competitive
|
||
|
factors. Getting a straight answer from a telco on this question
|
||
|
can also be a challenge. Probably so as not to tip their hand to
|
||
|
competitors. Unfortunately, it is a question only they can answer.
|
||
|
</P
|
||
|
></LI
|
||
|
><LI
|
||
|
><P
|
||
|
> Q. I was disqualified because I am too far away. What can I do?
|
||
|
</P
|
||
|
><P
|
||
|
> Move? Seriously, there isn't much you can do. If there are other providers,
|
||
|
get another opinion. You never know. Determining the loop length is an
|
||
|
inexact science, and there is room for errors. Many use databases for
|
||
|
this, and these databases routinely have some inaccuracies. Some providers
|
||
|
too, may be more aggressive in taking steps to help you out and clean up
|
||
|
the line. Also, some providers offer low-end speed services that have
|
||
|
greater reach. Maybe this will become available in your area. Or, the telco
|
||
|
may install, at some point, remote devices for customers who are now too
|
||
|
far away.
|
||
|
|
||
|
</P
|
||
|
></LI
|
||
|
><LI
|
||
|
><P
|
||
|
> Q. I am told I am 20,000 ft from the CO. Isn't that too far? Will my
|
||
|
speeds be really bad?
|
||
|
|
||
|
</P
|
||
|
><P
|
||
|
> Not necessarily. This distance limitation is not where the CO is, but
|
||
|
where the DSLAM is. These are often installed in CO's, but more and more
|
||
|
are being installed in remote locations in order to expand the reach
|
||
|
of DSL service.
|
||
|
|
||
|
</P
|
||
|
></LI
|
||
|
><LI
|
||
|
><P
|
||
|
> Q. What are the speed tweaks for Linux?
|
||
|
</P
|
||
|
><P
|
||
|
> This may not be necessary. Linux is pre-tweaked for the most part,
|
||
|
unlike some versions of Windows that really need some registry hacks to get
|
||
|
optimum performance. If you have a high latency connection, you may
|
||
|
benefit from increasing the TCP Receive Window. See the <A
|
||
|
HREF="tuning.html"
|
||
|
>Tuning</A
|
||
|
> section.
|
||
|
</P
|
||
|
><P
|
||
|
> Now if you are convinced you are not getting the performance you should
|
||
|
based on your distance and line conditions, then there might be a problem
|
||
|
somewhere. See the <A
|
||
|
HREF="tuning.html"
|
||
|
>Troubleshooting</A
|
||
|
> section for
|
||
|
more. What you may need is a fix, more than a tweak.
|
||
|
|
||
|
</P
|
||
|
></LI
|
||
|
><LI
|
||
|
><P
|
||
|
> Q. My service is limited to 640K (for example). Can I get better speed by
|
||
|
getting a faster modem? Any way around this?
|
||
|
</P
|
||
|
><P
|
||
|
> No, and no. The modem has little bearing on how fast your connection is for
|
||
|
all intents and purposes. The provider has a mechanism in place for
|
||
|
limiting your speed somewhere in the pipe before you hit the Internet.
|
||
|
There is no way to defeat this.
|
||
|
|
||
|
</P
|
||
|
></LI
|
||
|
><LI
|
||
|
><P
|
||
|
> Q. Can I download and upload at the same time? Is one effected by the
|
||
|
other?
|
||
|
</P
|
||
|
><P
|
||
|
> The upstream and downstream channels use separate frequency ranges within
|
||
|
the DSL signal, so simultaneous upload/download is not a problem and
|
||
|
available bandwidth is not normally impacted.
|
||
|
</P
|
||
|
><P
|
||
|
> Where there may be somewhat of an adverse impact, is with asymmetric DSLs
|
||
|
like ADSL, <EM
|
||
|
>and</EM
|
||
|
> both the upstream and downstream are
|
||
|
simultaneously saturated. This is a TCP 'feature' and not DSL related
|
||
|
though. This can adversely effect the faster stream (i.e. the downstream).
|
||
|
How much of an impact depends on a slew of factors and is beyond the scope
|
||
|
of this document, but is more pronounced with higher ratios of downstream
|
||
|
to upstream (e.g. 640/90). See the <A
|
||
|
HREF="tuning.html#BOTTLENECKS"
|
||
|
>Tuning</A
|
||
|
>
|
||
|
on how to mitigate this effect.
|
||
|
|
||
|
</P
|
||
|
></LI
|
||
|
><LI
|
||
|
><P
|
||
|
> Q. I am paying for 768 Kbps service, and the best I ever get is 640 Kbps or
|
||
|
so. Why? Is the service oversold? I am not getting what I pay for.
|
||
|
</P
|
||
|
><P
|
||
|
> You will lose 10-20% of the rated capacity due to the overhead inherent
|
||
|
in the various protocols utilized. Most of us will probably fall closer to
|
||
|
20%. This is just a fact of life for everybody. Just how much is lost here
|
||
|
depends on various factors. You seem to be close to your maximum when this
|
||
|
is taken into consideration. Also, if you read the fine print, many ISPs
|
||
|
are advertising speeds <SPAN
|
||
|
CLASS="QUOTE"
|
||
|
>"up to"</SPAN
|
||
|
> such and such. Check your
|
||
|
service agreement and see if there are any guarantees. If there are, they
|
||
|
may be well below the advertised maximum speed, and may be based on sync
|
||
|
rate instead of actual throughput. Though this may vary from provider to
|
||
|
provider as well.
|
||
|
|
||
|
</P
|
||
|
><P
|
||
|
> Also, be careful how you test this. Some of the so-called test sites can be
|
||
|
pretty unreliable. There can be many factors between you and that site that
|
||
|
can impact your throughput and skew results -- not the least of which is
|
||
|
how many people might be trying that same test at the same time. The best
|
||
|
test is via FTP download from a known good, close, not too busy site.
|
||
|
|
||
|
</P
|
||
|
></LI
|
||
|
><LI
|
||
|
><P
|
||
|
> Q. Can DSL work with ISDN, and how is this different?
|
||
|
</P
|
||
|
><P
|
||
|
> Yes, there have been DSL capable modems and service providers for some
|
||
|
time. In fact, this is common in parts of Europe. So this is not an issue.
|
||
|
</P
|
||
|
><P
|
||
|
> What makes ISDN different is the underlying signal on the line is
|
||
|
fundamentally different than a POTS line. This means that any physical
|
||
|
layer hardware has to be compatible with ISDN (and conversely it is
|
||
|
incompatible with POTS lines). So this means the NT (modem), filters, etc,
|
||
|
all have to be designed for ISDN. Other than these low level issues, the
|
||
|
other aspects of DSL implementation are the same (e.g. network protocols).
|
||
|
</P
|
||
|
></LI
|
||
|
><LI
|
||
|
><P
|
||
|
> Q. Why does PPPoX have such a bad rap?
|
||
|
</P
|
||
|
><P
|
||
|
> The occasional disconnects is one of the biggest gripes. PPP seems to be
|
||
|
sensitive to any interruptions in the connection. Generally a disconnect
|
||
|
means a new IP. And there are those that say PPP, by its very nature, was
|
||
|
never meant to be an <SPAN
|
||
|
CLASS="QUOTE"
|
||
|
>"always on"</SPAN
|
||
|
> protocol. PPP is a session
|
||
|
management protocol at heart, that requires a user to initiate a
|
||
|
connection and authenticate him or herself. PPPoE/A are not yet
|
||
|
particularly mature protocols either. They do not have much of a history
|
||
|
or track record. Some would say the telcos and hardware manufacturers have
|
||
|
rushed this out the door. PPPoE also requires an additional layer of
|
||
|
software just to maintain the connection. This is one more layer of code
|
||
|
and one more potential point of failure. Also, more system overhead is
|
||
|
utilized to manage the connection.
|
||
|
|
||
|
</P
|
||
|
><P
|
||
|
> The impact of the disconnect problem can potentially be eased by adjusting
|
||
|
the PPP LCP-echo settings to extend the period before the local end of
|
||
|
the connection decides to terminate the session. Each end of the
|
||
|
connection uses LCP echoes to make sure the other end is still
|
||
|
<SPAN
|
||
|
CLASS="QUOTE"
|
||
|
>"there"</SPAN
|
||
|
>. Nothing much can be done if the remote end decides
|
||
|
to tear down a session (other than to do what you can to make sure you are
|
||
|
responding to it's LCP echoes).
|
||
|
|
||
|
</P
|
||
|
></LI
|
||
|
><LI
|
||
|
><P
|
||
|
> Q. Why PPPoX? This seems like a bad idea!
|
||
|
</P
|
||
|
><P
|
||
|
> PPP gives several advantages to the provider: they can use their existing
|
||
|
infrastructure and hardware that they now use for their (larger) dialup
|
||
|
customer base. It is easier to control user authentication and potential
|
||
|
abuse situations, and easier to manage their network and related issues. In
|
||
|
fact, it most boils down to its just easier for them. Easier, means saves
|
||
|
man hours, and therefore saves costs (at least from their perspective).
|
||
|
|
||
|
</P
|
||
|
><P
|
||
|
> It is not a conspiracy to conserve IP addresses, or thwart heavy users. IP
|
||
|
address costs are insignificant in the overall scheme of things.
|
||
|
|
||
|
</P
|
||
|
></LI
|
||
|
><LI
|
||
|
><P
|
||
|
> Q. The only provider in my area does not support Linux. What can I do?
|
||
|
Will I have to use Windows?
|
||
|
</P
|
||
|
><P
|
||
|
> NO! <SPAN
|
||
|
CLASS="QUOTE"
|
||
|
>"Support"</SPAN
|
||
|
> here is support as in <SPAN
|
||
|
CLASS="QUOTE"
|
||
|
>"tech
|
||
|
support"</SPAN
|
||
|
>. They are just saying that they will not give you tech
|
||
|
support when and if you have problems. This does not mean you cannot use
|
||
|
Linux on their network. Just that you may have to fend for yourself when
|
||
|
and if a problem does arise. Anything that is forbidden will be in their
|
||
|
Acceptable Use Policy (AUP), or Terms of Service (TOS) agreement.
|
||
|
|
||
|
</P
|
||
|
><P
|
||
|
> I have heard stories where a new tech or installer has misinterpreted their
|
||
|
own company's policy on this and told someone <SPAN
|
||
|
CLASS="QUOTE"
|
||
|
>"you can't use Linux
|
||
|
here"</SPAN
|
||
|
>. Same with NT server. But this is almost always a misinformed
|
||
|
individual.
|
||
|
|
||
|
</P
|
||
|
><P
|
||
|
> But -- if a provider does not support Linux, they may balk at installing
|
||
|
onto a Linux box. Hopefully, they will have a self-install option to get
|
||
|
around this annoyance. YMMV.
|
||
|
|
||
|
</P
|
||
|
></LI
|
||
|
><LI
|
||
|
><P
|
||
|
> Q. My fax software does not work with my DSL modem. Why is that?
|
||
|
|
||
|
</P
|
||
|
><P
|
||
|
> Faxes are normally transmitted over typical analog phone lines by dialing
|
||
|
the fax machine on the other end. Analog modems can handle this, but
|
||
|
DSL <SPAN
|
||
|
CLASS="QUOTE"
|
||
|
>"modems"</SPAN
|
||
|
> have no dialing capability. Don't throw out that
|
||
|
56K yet!
|
||
|
|
||
|
</P
|
||
|
></LI
|
||
|
><LI
|
||
|
><P
|
||
|
> Q. What does <SPAN
|
||
|
CLASS="QUOTE"
|
||
|
>"FastPath"</SPAN
|
||
|
> mean? Is it better? Faster? What is
|
||
|
interleaving? How can I get better ping times?
|
||
|
|
||
|
</P
|
||
|
><P
|
||
|
> Interleaving is a feature of DMT line encoding. Essentially it is a form
|
||
|
of error correction that is configurable at the DSLAM. The side effects are
|
||
|
a slower connection, especially higher latency. With FastPath (or sometimes
|
||
|
called non-interleaved) DMT, gateway pings can be in the 10-25 ms range. With
|
||
|
interleaving, this is more likely to be in the 40-75 ms range depending on
|
||
|
the degree of interleaving that has been enabled.
|
||
|
|
||
|
</P
|
||
|
><P
|
||
|
> On the positive side, a marginal line is more stable and less prone to
|
||
|
errors with interleaving. Many telcos have interleaving on by default since
|
||
|
increased stability would seem to be a good thing. But this is only
|
||
|
beneficial for marginal lines, and everyone else is paying a latency tax
|
||
|
for this. Some telcos may be amenable to turning this feature on/off. YMMV.
|
||
|
|
||
|
</P
|
||
|
></LI
|
||
|
><LI
|
||
|
><P
|
||
|
> Q. How fast and powerful of a computer do I need for DSL? My ISP says I
|
||
|
need at least a Pentium 200. Why?
|
||
|
</P
|
||
|
><P
|
||
|
> At the most basic level, a 386 will work fine. In most situations, you are
|
||
|
connected to what is essentially an ethernet based network. So
|
||
|
theoretically anything that can handle a very slow ethernet connection
|
||
|
would work. No comment on how well Netscape will run on a 386 though ;-)
|
||
|
But as far as just managing a raw connection, a 386 is indeed workable.
|
||
|
What else you can do with it, is another matter.
|
||
|
|
||
|
</P
|
||
|
><P
|
||
|
> Where this gets a little more complicated is the modem, and the client
|
||
|
that the ISP may require. Any PCI or USB modem is going to require
|
||
|
drivers, which means more CPU and system resources. Also, PPPoE does even
|
||
|
more processing, so again the potential CPU load is increased. Windows
|
||
|
tends to be not so efficient with all this going on, hence the requirement
|
||
|
for mid range Pentiums by some ISPs.
|
||
|
|
||
|
</P
|
||
|
><P
|
||
|
> With Linux it will depend on what you are going to do. A low end Pentium
|
||
|
should be fine for most uses. A 386/486 should do nicely for just a
|
||
|
firewall/gateway box in most situations. Just remember if you are running
|
||
|
PPPoE, you may take a performance hit on low end hardware.
|
||
|
|
||
|
</P
|
||
|
></LI
|
||
|
><LI
|
||
|
><P
|
||
|
> Q. I just got my DSL installed, and my speed sucks, and/or my connection
|
||
|
constantly drops. What is the problem?
|
||
|
|
||
|
</P
|
||
|
><P
|
||
|
> Not enough information to say, really. There are many, many things that
|
||
|
can cause a poor connection. The list is too long to mention them all.
|
||
|
|
||
|
</P
|
||
|
><P
|
||
|
> One of DSL's weaknesses is that the signal can be fairly fragile. Many
|
||
|
things can degrade the signal, making for poor connections, and thus
|
||
|
speed. This can be caused by poor or substandard inside wiring, a wiring
|
||
|
problem outside (like bad splice), RFI from any number of sources, AM
|
||
|
radio signal interference from a nearby station, bridge taps on your
|
||
|
line, excessive distance from the DSLAM and so on. Not to mention possible
|
||
|
hardware problems with your modem, NIC, or the telco's DSLAM, etc. Not
|
||
|
always easy to sort out.
|
||
|
|
||
|
</P
|
||
|
><P
|
||
|
> Your provider should be able to assist you. First, make sure the problem
|
||
|
isn't with your setup as they likely won't help solve a Linux problem. Then
|
||
|
be persistent, and don't hesitate to go over someone's head if the help is
|
||
|
not forthcoming. Most problems are solvable. The trick is isolating it. A
|
||
|
good telco tech, trained for DSL, can find all kinds of obscure wiring
|
||
|
problems.
|
||
|
|
||
|
</P
|
||
|
></LI
|
||
|
><LI
|
||
|
><P
|
||
|
> Q. My provider's tech support staff is clueless. What can I do?
|
||
|
|
||
|
</P
|
||
|
><P
|
||
|
> Common complaint. Seems to be the nature of the beast. First line tech
|
||
|
support is an entry level position, and mostly filled by young people
|
||
|
with little technical or networking knowledge. Grin and bear it, or try
|
||
|
calling back.
|
||
|
</P
|
||
|
></LI
|
||
|
><LI
|
||
|
><P
|
||
|
> Q. Now that I have a dedicated line, do I really need an ISP?
|
||
|
Can't I be my own ISP?
|
||
|
</P
|
||
|
><P
|
||
|
> Yes, and no. Linux has everything needed to run a small ISP. But even
|
||
|
though the <SPAN
|
||
|
CLASS="QUOTE"
|
||
|
>"line"</SPAN
|
||
|
> is a dedicated connection, it is only
|
||
|
dedicated to the telco end-point equipment. You still need someone to sell
|
||
|
you bandwidth, and gateway access to the Internet. So, traditional ISPs
|
||
|
still have their role. You might see if there is a local provider of some
|
||
|
kind that will just sell you the bandwidth without all the frills (e.g.
|
||
|
email and news). But this probably will not save any costs.
|
||
|
</P
|
||
|
><P
|
||
|
> It is also technically possible to connect two DSL modems via
|
||
|
a <SPAN
|
||
|
CLASS="QUOTE"
|
||
|
>"dry"</SPAN
|
||
|
> copper line. In some areas, a dry line (with
|
||
|
no dial tone), is fairly inexpensive (but in others areas it's not).
|
||
|
And then you need someone on the other end who is willing to provide
|
||
|
the bandwidth and whatever services may be needed. Not all DSL modems
|
||
|
support this (some common SDSL modems apparently do). This is also going to
|
||
|
require dealing with the local phone company for something that is not a
|
||
|
consumer type service (read: might be a real PITA). There is also a
|
||
|
significant start up investment, that may not come with any telco
|
||
|
guarantees for the intended use.
|
||
|
|
||
|
</P
|
||
|
></LI
|
||
|
><LI
|
||
|
><P
|
||
|
> Q: Are there ADSL Standards?
|
||
|
</P
|
||
|
><P
|
||
|
> Sort of. The U.S. Bell Operating Companies have standardized on Discrete
|
||
|
Multi-Tone (DMT) (ANSI T1.413) in their current roll-out. Most others
|
||
|
should follow their lead in the states. There are other types of modems, most
|
||
|
notably Carrier-less Amplitude Phase Modulation (CAP), which of course, is
|
||
|
incompatible with DMT.
|
||
|
</P
|
||
|
><P
|
||
|
> A biased comparison from an DMT-based vendor on this subject can be found at
|
||
|
the <A
|
||
|
HREF="http://www.aware.com"
|
||
|
TARGET="_top"
|
||
|
>http://www.aware.com</A
|
||
|
>. Still,
|
||
|
it provides the best detail on this issue I have seen so far.
|
||
|
</P
|
||
|
><P
|
||
|
> A rather expensive copy of the ANSI standard can be ordered at: American
|
||
|
National Standards Institute <A
|
||
|
HREF="http://www.ansi.org"
|
||
|
TARGET="_top"
|
||
|
>ANSI Home
|
||
|
Page</A
|
||
|
>
|
||
|
</P
|
||
|
><P
|
||
|
>
|
||
|
Asymmetric Digital Subscriber Loop (ADSL) Metallic Interface
|
||
|
</P
|
||
|
><P
|
||
|
>
|
||
|
ANSI TI.413-1995
|
||
|
</P
|
||
|
><P
|
||
|
>
|
||
|
Note: ANSI TI.413 Issue 2 was released September 26, 1997
|
||
|
</P
|
||
|
></LI
|
||
|
><LI
|
||
|
><P
|
||
|
> Q: Can I use ATM to connect to DSL?
|
||
|
</P
|
||
|
><P
|
||
|
> Technically speaking, you can. Some DSL modems (at least the Alcatel
|
||
|
version) has a ATM Forum 25Mbps interface, which connects to a PCI ATM
|
||
|
card. But this is rarely done in practice since many Operating Systems
|
||
|
can't speak ATM natively, and the cost of ATM cards is more than ethernet.
|
||
|
See <A
|
||
|
HREF="http://linux-atm.sourceforge.net/"
|
||
|
TARGET="_top"
|
||
|
>http://linux-atm.sourceforge.net/</A
|
||
|
>
|
||
|
for more details.
|
||
|
</P
|
||
|
></LI
|
||
|
><LI
|
||
|
><P
|
||
|
> Q: Why does DSL have all these bit rates (384/1.5/7.1M/20M/etc) options?
|
||
|
</P
|
||
|
><P
|
||
|
> The basic problem is the 100 year old design of the copper loop. It works
|
||
|
great for analog phone, but it presents a real challenge for higher
|
||
|
performance signals like DSL. Remember that the distance of a loop is
|
||
|
inversely proportional to the data rate that it can carry. Rate adaptive
|
||
|
technologies are great for making a digital signal work in many situations,
|
||
|
but it can't provide a consistent bandwidth for all applications,
|
||
|
especially for very long (over ~15,000 ft) loops. The different bandwidths
|
||
|
that you see advertised reflect various marketing battles of vendors
|
||
|
equipment, and the telco struggle to finalize on a standard set of data
|
||
|
rates. The bottom line is for the telco to be able to reach as broad a
|
||
|
customer base as possible.
|
||
|
|
||
|
</P
|
||
|
><P
|
||
|
> Check out the next question on the loop impairments that cause this to
|
||
|
happen.
|
||
|
</P
|
||
|
></LI
|
||
|
><LI
|
||
|
><P
|
||
|
> Q: What are all these loop impairments (bridge taps, load coils, DLCs) that
|
||
|
could disqualify my line from DSL? (thanks to Bruce Ediger)
|
||
|
</P
|
||
|
><P
|
||
|
> Load coils: in-line inductances that improve voice-frequency transmission
|
||
|
characteristics of a telephone circuit. Essentially, a "load" steals energy
|
||
|
from high frequencies and gives it to lower frequencies. Typically only used
|
||
|
in very long (> 9,000 ft) phone lines.
|
||
|
</P
|
||
|
><P
|
||
|
> By "bridges" I assume you mean "bridged taps". In older neighborhoods, the
|
||
|
phone wiring will have been used by more than one customer. Perhaps these
|
||
|
customers lived at different (though near-by) addresses. The unconnected
|
||
|
"spur" of wiring is a "bridged tab" on the currently connected circuit.
|
||
|
</P
|
||
|
><P
|
||
|
> DLCs, Digital Loop Carriers: there's a bunch of systems for carrying more
|
||
|
than one voice transmission on a single pair of wires. You can shift the
|
||
|
frequencies up or down, or you can digitize the voice transmissions and
|
||
|
divide the telephone circuit by time or code or something. The more
|
||
|
general term is "pair gain".
|
||
|
</P
|
||
|
><P
|
||
|
> These things cause different problems for high-frequency communications.
|
||
|
</P
|
||
|
><P
|
||
|
> Load coils will completely mess up things by filtering high frequencies and
|
||
|
passing low frequencies. They probably also change the "delay envelope",
|
||
|
allowing some frequencies to arrive before others. One byte's tones will
|
||
|
interfere with the next byte's.
|
||
|
</P
|
||
|
><P
|
||
|
> Bridged taps act as shunt capacitances if they're long in relation to the
|
||
|
signals wavelength, and they'll actually act as band pass filters if they're
|
||
|
about 1/4 wavelength of the signal. That is, they'll pass particular
|
||
|
frequencies freely. Particular tones of a DMT modem might get shunted back,
|
||
|
rather than passed along to the receiving modem, reducing bandwidth for that
|
||
|
telephone line.
|
||
|
</P
|
||
|
><P
|
||
|
> Pair gain, digital or analog, limit the bandwidth available to one
|
||
|
transmission in order to multiplex several on one wire. High and low tones
|
||
|
of a DMT transmission get filtered out by the apparatus.
|
||
|
</P
|
||
|
><P
|
||
|
> The book "Subscriber Loop Signaling and Transmission Handbook", by Whitham D.
|
||
|
Reeve, , IEEE Press 1992, ISBN 0-87942-274-2 covers the math of how to
|
||
|
calculate the effect of line length, bridged tap, etc on the transmission
|
||
|
characteristics of a telephone line. It's pretty expensive, however.
|
||
|
</P
|
||
|
></LI
|
||
|
><LI
|
||
|
><P
|
||
|
> Q. Can I run a web server with my DSL connection?
|
||
|
|
||
|
</P
|
||
|
><P
|
||
|
> Sure. You are connected to a TCP/IP network, so theoretically you can run
|
||
|
any service that the protocols allow -- mail, ftp, ssh, irc, etc. Where
|
||
|
there may be problems, is with the ISP's TOS (Terms of Service). Some ISPs
|
||
|
are pretty open on this, while others forbid any type of server, and may
|
||
|
even block certain ports. You should research this, or ask the ISP before
|
||
|
making any plans. ISPs that are selling a consumer service are not
|
||
|
going to allow any high volume servers -- just personal, or low traffic
|
||
|
services at best. If this does not fit the bill, then you can check with
|
||
|
any local Business class DSL providers. This will cost more, but the
|
||
|
Terms of Service, and guarantees, are generally much more suited to
|
||
|
higher bandwidth usages.
|
||
|
|
||
|
</P
|
||
|
><P
|
||
|
> If you do not have a static IP, you can get around this with one of the
|
||
|
many Dynamic DNS services that are out there for just this purpose. See the
|
||
|
<A
|
||
|
HREF="appendix.html#LINKS"
|
||
|
>links</A
|
||
|
> section.
|
||
|
|
||
|
</P
|
||
|
></LI
|
||
|
><LI
|
||
|
><P
|
||
|
> Q: Do you have examples of DSL Modems?
|
||
|
</P
|
||
|
><P
|
||
|
> Short Answer: Yes. Real Answer: The evolution of this technology is
|
||
|
moving too rapidly for anyone to keep up to date in a HOWTO.
|
||
|
Check <A
|
||
|
HREF="http://dslreports.com/information/equiprated/all"
|
||
|
TARGET="_top"
|
||
|
>http://dslreports.com/information/equiprated/all</A
|
||
|
> for up to date information.
|
||
|
|
||
|
</P
|
||
|
><P
|
||
|
> However, below is a list of some of the current modem offerings as of
|
||
|
January 2002. All are ADSL modems with DMT encoding (a.k.a. Alcatel
|
||
|
compatible), unless specified otherwise. [Note: Some items retained from
|
||
|
original list dated June 1998.]
|
||
|
|
||
|
</P
|
||
|
><P
|
||
|
> <P
|
||
|
></P
|
||
|
><UL
|
||
|
><LI
|
||
|
><P
|
||
|
> Router/Modems with 10/100baseT Ethernet Interface:
|
||
|
</P
|
||
|
><P
|
||
|
> Examples: Flowpoint 2000 DSL(CAP), 3COM Viper-DSL (CAP), Westell
|
||
|
ATU-R-Flexcap (CAP), Aware x200, Zyxel P641, Efficient Networks
|
||
|
SpeedStream 5660 and 5861, Cayman 3220H, Cisco 673 (SDSL), Cisco 675
|
||
|
(ADSL/CAP), Cisco 677 (ADSL/DMT), Alcatel SpeedTouch Pro
|
||
|
</P
|
||
|
></LI
|
||
|
><LI
|
||
|
><P
|
||
|
> Bridge/Modems with 10/100baseT Ethernet Interface:
|
||
|
</P
|
||
|
><P
|
||
|
> Examples: Alcatel 1000, Alcatel SpeedTouch Home [note: Home == ethernet,
|
||
|
there are also USB and PCI SpeedTouch versions!], Westell ATU-R-Flexcap2
|
||
|
(CAP), Efficient Networks SpeedStream 5260, Efficient Networks SpeedStream
|
||
|
5251 (SDSL), Westell WireSpeed.
|
||
|
|
||
|
</P
|
||
|
></LI
|
||
|
><LI
|
||
|
><P
|
||
|
> Modems with ATMF Interface:
|
||
|
</P
|
||
|
><P
|
||
|
> Examples: Alcatel 1000, Alcatel SpeedTouch Home, Cisco 677 (DMT), Ariel
|
||
|
Horizon II
|
||
|
|
||
|
</P
|
||
|
></LI
|
||
|
><LI
|
||
|
><P
|
||
|
> Bridge/Modems with V.35 Serial Interface (T1, Serial Router)
|
||
|
</P
|
||
|
><P
|
||
|
> Examples: Westell ATU-R
|
||
|
</P
|
||
|
></LI
|
||
|
><LI
|
||
|
><P
|
||
|
> Modems with USB Interface:
|
||
|
</P
|
||
|
><P
|
||
|
> Efficient Networks SpeedStream 4060, Intel 3100, Alcatel SpeedTouch USB
|
||
|
</P
|
||
|
></LI
|
||
|
><LI
|
||
|
><P
|
||
|
> PCI Modems:
|
||
|
</P
|
||
|
><P
|
||
|
> Examples: Cisco 605, Efficient Networks SpeedStream 3060/3061, Intel 2100,
|
||
|
Xpeed X200 (IDSL), Xpeed X300 (SDSL), Alcatel SpeedTouch PCI
|
||
|
</P
|
||
|
></LI
|
||
|
><LI
|
||
|
><P
|
||
|
> Wireless Modems (IEEE 802.11b):
|
||
|
</P
|
||
|
><P
|
||
|
> Examples: Alcatel SpeedTouch Wireless
|
||
|
|
||
|
</P
|
||
|
></LI
|
||
|
><LI
|
||
|
><P
|
||
|
> Dedicated Router (no built in modem) with 10/100baseT Ethernet Interface:
|
||
|
</P
|
||
|
><P
|
||
|
> Examples: Netgear RT311, SMC 7004BR, Linksys BEFSR11
|
||
|
|
||
|
</P
|
||
|
></LI
|
||
|
></UL
|
||
|
>
|
||
|
</P
|
||
|
></LI
|
||
|
></OL
|
||
|
></P
|
||
|
><P
|
||
|
> This is but a very small sampling and should not be construed as
|
||
|
endorsements of the products listed. It is just a simple illustration
|
||
|
of a few of the available products.
|
||
|
</P
|
||
|
><DIV
|
||
|
CLASS="WARNING"
|
||
|
><P
|
||
|
></P
|
||
|
><TABLE
|
||
|
CLASS="WARNING"
|
||
|
WIDTH="100%"
|
||
|
BORDER="0"
|
||
|
><TR
|
||
|
><TD
|
||
|
WIDTH="25"
|
||
|
ALIGN="CENTER"
|
||
|
VALIGN="TOP"
|
||
|
><IMG
|
||
|
SRC="../images/warning.gif"
|
||
|
HSPACE="5"
|
||
|
ALT="Warning"></TD
|
||
|
><TD
|
||
|
ALIGN="LEFT"
|
||
|
VALIGN="TOP"
|
||
|
><P
|
||
|
> Modem manufacturers often ship modems to meet an ISP's specifications.
|
||
|
Features are sometimes enabled or disabled as requested by the ISP. There are
|
||
|
conceivably numerous, possible variations on each model. Something to
|
||
|
consider if buying one second-hand.
|
||
|
|
||
|
</P
|
||
|
></TD
|
||
|
></TR
|
||
|
></TABLE
|
||
|
></DIV
|
||
|
></DIV
|
||
|
><DIV
|
||
|
CLASS="NAVFOOTER"
|
||
|
><HR
|
||
|
ALIGN="LEFT"
|
||
|
WIDTH="100%"><TABLE
|
||
|
SUMMARY="Footer navigation table"
|
||
|
WIDTH="100%"
|
||
|
BORDER="0"
|
||
|
CELLPADDING="0"
|
||
|
CELLSPACING="0"
|
||
|
><TR
|
||
|
><TD
|
||
|
WIDTH="33%"
|
||
|
ALIGN="left"
|
||
|
VALIGN="top"
|
||
|
><A
|
||
|
HREF="overview.html"
|
||
|
ACCESSKEY="P"
|
||
|
>Prev</A
|
||
|
></TD
|
||
|
><TD
|
||
|
WIDTH="34%"
|
||
|
ALIGN="center"
|
||
|
VALIGN="top"
|
||
|
><A
|
||
|
HREF="index.html"
|
||
|
ACCESSKEY="H"
|
||
|
>Home</A
|
||
|
></TD
|
||
|
><TD
|
||
|
WIDTH="33%"
|
||
|
ALIGN="right"
|
||
|
VALIGN="top"
|
||
|
><A
|
||
|
HREF="appendix.html"
|
||
|
ACCESSKEY="N"
|
||
|
>Next</A
|
||
|
></TD
|
||
|
></TR
|
||
|
><TR
|
||
|
><TD
|
||
|
WIDTH="33%"
|
||
|
ALIGN="left"
|
||
|
VALIGN="top"
|
||
|
>Appendix: DSL Overview</TD
|
||
|
><TD
|
||
|
WIDTH="34%"
|
||
|
ALIGN="center"
|
||
|
VALIGN="top"
|
||
|
> </TD
|
||
|
><TD
|
||
|
WIDTH="33%"
|
||
|
ALIGN="right"
|
||
|
VALIGN="top"
|
||
|
>Appendix: Miscellaneous</TD
|
||
|
></TR
|
||
|
></TABLE
|
||
|
></DIV
|
||
|
></BODY
|
||
|
></HTML
|
||
|
>
|