[wplug] DSL speed

Brian A. Seklecki lavalamp at spiritual-machines.org
Sat Mar 1 21:01:22 EST 2008


5%->10% is an acceptable loss due to packet encapsulation overhead.

Remember that "bandwidth testing" web sites are Bullshit(R).  They're
there to sell ads.

You want to test using TCP connections to a server on a subnet connected
to the router where your ISP terminates its ATM hand-off from Verzion.

E.g., find a virtualhost on an ASPStation/Nidhog server and wget(1) a
file from there.

If you use a bandwidth test, you've got no control variable in your
test.  At that point, you're testing both your ISPs uplink and your DSL
circuit health.

---

Remember, your HTTP data goes from your userland application into the
kernel.  The kernel makes a TCP packet (l4), hands it to the IP layer
(l3) which makes an IP packet, which hands it to the ethernet driver
transmit buffer (l2), which sends it onto the wire.

Your DSL bridge converts 1500-byte ethernet frames into DSL service ATM
frames (53 octets with 5 used for header, so 48 octet header), and
transmits them across the copper to the DSLAM at your local CO.

It becomes all fiber/copper from there as it cross countless back-haul
devices on the way to Penn Avenue where ASPStation is located, and/or
where they choose to co-lo their Layer3 gear to peer with an
Ethernet/DS3 handoff from Verizon.

Verizon has a massive layer-1/layer-2 Fiber/Copper ATM Framework that
spans the continental United States like a Jackson Pollock painting.

This is all black box here -- you only get to see one Layer3 hop between
your L3 CPE device and your ISPs, but countless ATM intermediary points
could exist.

The packet pops out of the other side at your ISP, who (hopefully) only
has 1 or 2 hops internally before handing you off to the public Internet
via BGP peers.

The better the peering, the better your overall performance.

However, there is no guarantee of synchronous/symmetric routing paths
once BGP comes into play.

Your bandwidth testing packets could egress your ISP network via one
peer and ingress via another.

Always test your circuit locally.

~BAS

On Wed, 2008-02-27 at 09:31 -0500, Patrick Wagstrom wrote:
> Zach wrote:
> > The speed test at dslreports.com is showing my download speed as 625
> > Kb/s. This seems a lot less than the 768 Kb/s I'm supposed to have. My
> > latency to their test server in NY was 50ms. Is there anything I can
> > do to to increase my download speed? I'm using Ubuntu 7.04 Live CD
> > until I can buy a new computer. Running 2.6.18 kernel and
> > Debian/Ubuntu.
> 
> That actually sounds pretty good.  You've got two layers of overhead going 
> on in your connection: encapsulation to PPPoE and then TCP/IP.  For most 
> packets, these numbers are both small (8 octets for PPPoE, 20 octets for 
> IP, 20 octets for TCP).  In that case you're losing about 4% right off the 
> bat to overhead.  However, depending on the way data is transmitted it 
> could be far worse.  Telnet usually transmits single octets, which means 
> that on a DSL you're sending 49 octets of which 1 octet is data.  Yay for 
> 98% overhead.
> 
> Another issue is that there is inherent noise in the DSL line.  This causes 
> some data to retransmit, lowering your throughput even more.  Noise is 
> present on most lines (cable too), but the nature of the phone network 
> means its slightly more susceptible.
> 
> This is normal.  Getting 625Kb/s on a 768Kb/s is great.  If you were around 
> 400Kb/s that would be an issue.
> 
> --Patrick
> _______________________________________________
> wplug mailing list
> wplug at wplug.org
> http://www.wplug.org/mailman/listinfo/wplug



More information about the wplug mailing list