dsl

This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.



From: "Jose M. Sanchez" <opjose@ex-pressnet.com>
Date: Fri, 26 Mar 1999 09:34:04 -0500
Subject: Re: [A/S]SDL services

On Friday, March 26, 1999 7:21 AM hUnTeR <hunter@userfriendly.net> wrote: 

> I have a few general questions for anyone who has experience with DSL
> services. I have been looking into getting DSL (actually SDSL -
> synchronis) which will be in my area in a couple of months. Nice
> packages ranging from 256Kbps to 1Mbps for a nice and modest price, and
> over standard copper yet. My question is more regarding the use of the
> Netopia router used for connection to these services. It has the line
> port in it, and a small 8-port hub built in. How would i best go about
> making the switch from ISDN modem to such a service? I understand that i
> would no longer be "dialing" so that would kill off the need for ppp, or
> so i believe. So what's the deal? How would i get my server to recognize
> and implement the new service? This would be my first dedicated line so
> i am a novice to this area. I currently use an external ISDN modem to
> make the ppp connection which is connected to my server and also a
> 16-port hub for my internal lan. OS is RedHat 5.2, linux 2.0.36-1 with
> all the latest errata and patches applied.
>
> Any ideas, questions, suggestions would be greatly appreciated.

Out of my own curiosity...

How much are they charging you for the service?

===

Subject: Re: recognizing 2 eth cards
From: markus@infoscape.com
Date: Wed, 12 May 1999 18:54:33 -0700

Mark Stone writes:
 > Some time this summer (depending on the whims of PacBell), I'll be setting
 > up DSL.

PacBell was surprisingly fast at installing ADSL for me (about 2.5
weeks after I ordered it). Of course, it then took them about two
months to get everything configured properly ;-) It still suffers from
occasional hick ups, but other than that I really enjoy the fast
downloads -- uploads are a little slow, though.

 > I'm going to have a small home network sitting behind a firewall,
 > and so the firewall machine has two ethernet cards in it (one running to
 > the DSL equipment, one running to the home lan's hub). 

Are you getting one IP address and then masquerading on the Firewall
machine? That is probably the easiest way to install it. If you enable 
ipmasq, Debian will automagically configure all of this.

If you go for enhanced service, PacBell Internet will give you a /29
subnet, which leaves you with five or six usable IP addresses. In
this case, you don't need to run masquerading but you _must_ tell
PacBell that you are going to use a Firewall/Gateway machine. Their
default configuration assumes that all of your machines are directly
connected to the DSL modem using a hub (it took me until 5am to
discover that that was the reason it didn't work for me). They will
have to issue another /30 subnet for your multi-homed firewall
machine.

 > I've got the firewall machine to recognize one ethernet card, but not the
 > other. Is this, perhaps, one of those special boot parameters I need to
 > set when doing the installation. This is/will be a Debian 2.x box.

Debian handles this just fine, but you will have to edit the
/etc/init.d/network file to let it know about your two networking
cards. Just add additional ifconfig, and (possibly) route commands as
necessary.

===

Subject: ADSL setup problem.  Should be easy.
From: "M. Neidorff" <neidorff@bellatlantic.net>
Date: Sat, 26 Jun 1999 19:28:32 -0400

I feel like I'm one last small step from having the adsl that I have gotten
setup on linux (RedHat 5.2).  (It works with win95)  I have 2 network
cards--one for my local net ( 3Com 3c509b)and the other for the adsl (3com
3c900b).

What I have done is followed the Net3-HOWTO to get everything going. 
My ip is 151.198.19.166
 gateway is 151.198.19.1
 dns are 151.198.0.37
         151.198.0.38

 Here are the commands I run:

# set up local network
insmod 3c509
ifconfig eth0 192.168.1.1 netmask 255.255.255.0 up
route add -net 192.168.1.0 netmask 255.255.255.0 dev eth0

# setup adsl network
insmod 3c95x
ifconfig eth1 151.198.19.0 netmask 255.255.255.0 up
route add -net 151.198.19.0 netmask 255.255.255.0 dev eth1
route add default gw 151.198.19.1 dev eth1

I'm not certain about the last two route lines.  After i run the last
command, I get the message: "host name lookup failure".
I have the dns entries set up in resolv.conf and it looks like this:

nameserver 151.198.0.37
nameserver 151.198.0.38

(BTW, I got the nameserver and gateway values from norton utilities, not
from the sheet that Bell Atlantic provided me.  The Bell Atlantic sheet had
different values for nameserver and gateway, but they didn't work anyway.)

Can anyone please help me figure out what is going wrong?

===

Subject: Re: ADSL setup problem.  Should be easy.
From: Charles Galpin <cgalpin@lighthouse-software.com>
Date: Sun, 27 Jun 1999 20:37:24 -0400 (EDT)

On Sat, 26 Jun 1999, M. Neidorff wrote:

> I feel like I'm one last small step from having the adsl that I have gotten
> setup on linux (RedHat 5.2).  (It works with win95)  I have 2 network
> cards--one for my local net ( 3Com 3c509b)and the other for the adsl (3com
> 3c900b).
> 
> What I have done is followed the Net3-HOWTO to get everything going. 
> My ip is 151.198.19.166
>  gateway is 151.198.19.1
>  dns are 151.198.0.37
>          151.198.0.38

I am by no means an expert at routing but have a working DSL (not that
that matters) setup to compare to. I'm not saying this is proper, or the
best way to do it, but it works great for me.

I setup my interfaces though linuxconf, and just like you my eth0 is my
interface to my local LAN, and eth1 is the interface to the rest of the
world. I'll show you what I put in my rc.local to get it to work for me
(using your IP's in this example)

# local route
/sbin/ifconfig eth0 192.168.1.1   # don't think this is needed since 
				  # I don't do it for eth1
/sbin/route add -net 192.168.1.0  # you'd think I'd need to specify eth0
				  # here, but seems to work fine

# everything else
/sbin/route add 151.198.19.1 eth1
/sbin/route add default gw 151.198.19.1

so the only route specifically added is for the lan, and everything else
is sent to the gateway which is found through eth1

===

Subject: Re: ADSL setup problem.  Should be easy.
From: "Kris Jordan" <krisj@ibm.net>
Date: Sun, 27 Jun 1999 19:17:54 -0700


You can also setup the gateway, and the two network cars through linuxconf,
don't see why you would need any of these lines in rc.local if you have
linuxconf.

>
> # everything else
> /sbin/route add 151.198.19.1 eth1
> /sbin/route add default gw 151.198.19.1
>

===

Subject: Re: ADSL setup problem.  Should be easy.
From: "Kris Jordan" <krisj@ibm.net>
Date: Mon, 28 Jun 1999 16:24:33 -0700


You have to play around with linuxconf. What I think you would need to do
is:

1. Go to Config->Networking->Client tasks->Basic host information-> add the
two adapters and enable them.

2. Go back to Client tasks->Routing and gateways->Set defaults-> type in IP
address of the network card the ADSL is connected to or the ADSL box itself.

I haven't actually done this before, but I think that does the same as what
you had in rc.local. Try it out.

Kris Jordan

> I tried linuxconf.  Perhaps I missed something in the setup, but it didn't
> work for me.  linuxconf could sure use some documentation.

===

Subject: RE: Alcatel DSL Internal Modem
From: "Mr. M" <mistrM@gtemail.net>
Date: Mon, 21 Jun 1999 16:27:37 -0700


> Please be more specific; in what way are they crap?  Customer service?
> Hardware service (crapppy hardware, maybe),  What is it that turned you
> off about GTE?  I 'm particularly curious because I'm shopping for DSL
> isp's, and its good to know which ones are crappy and why.

Ok, here it is:

I made the mistake of getting ADSL through GTE last December here in
Southern California.  At the time there were no other decent ISPs to chose
from.

I found out the day I got the service that IPs were dynamically assigned by
a DHCP server which prevented me from using the expensive line I purchased
for anything useful (NO http, dns, ftp, etc.).  I was told by GTE that
static IPs would be available soon so I kept the service.

In the 29 days I had the service it was down for 11.  The DHCP severs they
use to assign the IPs went down more than Monica Lewinsky.  Once all of
SoCal went down on a Friday night. NOTHING was done to fix it till Monday
morning!!!!!

Trying to get any real support is futile.  The only people you can talk to
are their lame $6 an hour techs that don't know anything beyond helping
someone setup basic TCP/IP networking on a Windoze95 box.

If you haven't read the post from Tim Hockin on this list do so.  His
experiences were almost exactly like mine.  I think that GTE has a policy of
not hiring anyone with an IQ over 100.  They are the most incompetent
company I have ever dealt with.

If GTE is your local phone company and you want xDSL service do yourself a
favor and chose another provider.  Many companies now offer xDSL.  Shop
around.  The great thing about DSL is that you don't have to go through your
phone company to get it.

I am currently with Flashcom (www.flashcom.com).  In nearly 5 months of
service I have only had 1 day of down time which was a problem with routers
at Exodus and beyond their control.

===

Subject: RE: Alcatel DSL Internal Modem
From: Charles Galpin <cgalpin@lighthouse-software.com>
Date: Mon, 21 Jun 1999 21:10:22 -0400 (EDT)

GTE is my only choice for telephone service, as well as xDSL. Up until
recently I have had nothing nice to say about them.

A friend was able to get ADSL a few months ago. They had terrible
problems, lots of down time etc, but they got them all ironed out.

But things have definitely improved. I am ***very*** happy with their
service so far (especially their field techs) and even though I've only
had the service for a week, I haven't had any down time or hint of trouble.

I am using someone else (www.doubled.com) as my ISP because I wanted a
static IP - that's research you should have done up front - you can't be
upset at them for that.

Anyway, I think it's fair to say that people should not all expect to have
the same experience you did.

I don't work for GTE, or own any of their stock either :)

===

Subject: Tweak TCP-IP on RH6 for best DSL throughput? How?
From: Chris Beaumont <chris@ncafe.com>
Date: Thu, 24 Jun 1999 10:49:21 -0700

 I'm wondering if I can do the same thing for my Red Hat Linux box that I
did for my Win 98 PC and my Power Mac..tweak the TCP-IP parameters..

I have a DSL connection that consistently gives excellent throughput, way
above what it is supposed to be capable of. The problem is that right now,
it is only doing that with my Mac (which always runs Mac OS) and my PC
-when it is running  Windows 98.

The same machine, on the exact same network, all other things exactly the
same, when it is booted into Linux..(which is 90% of the time..) does the
same speed the PC did with Windows before that *simple* little registry
tweak..

Good, but not *quite* as good as before..  which was almost unbelievable..
(getting very close to T1 speeds..Note, this will only work on a DSL or
cable connection that is *capable* of delivering this..)

I'm wondering, how can I do the same thing with my PC when it is running Linux.
Basically, to get this boost, on Windows and under Open Transport on the
Mac, I tweaked the "receive window size"...from some dinky little number,
to around 64k..

When I did that on my PC, average transfer rate jumped about 30-40%

Some of you must have done this.. How can I?

Thanks in advance..

===

Subject: RE: Tweak TCP-IP on RH6 for best DSL throughput? How?
From: "Juha Saarinen" <juha_saarinen@email.msn.com>
Date: Fri, 25 Jun 1999 10:41:43 +1200


> Basically, to get this boost, on Windows and under Open Transport on the
> Mac, I tweaked the "receive window size"...from some dinky little number,
> to around 64k..
>
> When I did that on my PC, average transfer rate jumped about 30-40%

Upping the RWIN value on my Windows machine really boosted the DUN
connection, but... it looks like Linux is still limited to 32K RWINs by
default.

from /usr/src/linux/include/net/tcp.h:

/*
 * Never offer a window over 32767 without using window scaling. Some
 * poor stacks do signed 16bit maths!
 */
#define MAX_WINDOW      32767
#define MIN_WINDOW      2048
#define MAX_ACK_BACKLOG 2
#define MAX_DELAY_ACK   2
#define TCP_WINDOW_DIFF 2048


You could try hacking tcp.h and bump up MAX_WINDOW to 65536 and recompile
the kernel.

However, I can't guarantee that it will work -- if anyone on the list knows
better, please correct me.

===

Subject: RE: Tweak TCP-IP on RH6 for best DSL throughput? How?
From: trixer <trixer@mail.suntrix.com>
Date: Thu, 24 Jun 1999 19:38:43 -0400

65536 would probably result in a buffer overflow somewhere, I would suggest
65535.

===

Subject: Re: Bandwidth measuring tool
From: Ramon Gandia <rfg@nook.net>
Date: Thu, 17 Jun 1999 11:21:59 -0800


Charles Galpin wrote:
> 
> It worked for me without the -m 1500
> 
> I have a question about the output though. I now have a DSL connection,
> 768Kb/s both ways (is that called symmetric or symmetrical?). I assume that
> at least on my first hop, to my isp's gateway that I should get that much
> bandwidth correct? I have run two tests so far and the bandwidth for that
> first hop has been 363 and 366 Kb/s.
> 
> I'm feeling like I'm not getting the speed I'm paying for - the next lower
> service level is 384/384 - which this looks suspiciously like.

Most of this stuff is priced by adding the incoming bandwidth
and the outgoing bandwidth to give you a single number.  Thus,
768K can be a combination of 384K + 384K, or perhaps it is
64K + 704K, etc.  When you see TWO numbers in the advertising,
you know what you get.  When you see a SINGLE number, then
its usually the combined bandwidth number for the purposes of
advertising hype.

A perfect example of this is Lucent WaveLan wireless LAN (and
in fact, most Wireless LAN products).  They list the bandwidth
as (example) 2 MBPS.  But its really just 1 mbps in one direction.

The 384K/384K you have could be symmetrical, but most likely it
is asymmetrical ADSL, with the setting sets for same each way.
ADSL is much more common, however, the 784K can be set for any
combination.  Obviously a web server at the end of an ADSL
would prefer 64K incoming and 704K outgoing, whereas a normal
internet user would prefer the other way around.  ADSL can
accommodate this.  It has to be configured by the telco.

===

Subject: Re: Bandwidth measuring tool
From: Ramon Gandia <rfg@nook.net>
Date: Thu, 17 Jun 1999 15:23:34 -0800


Alan Mead wrote:
> 
> At 04:13 PM 6/17/99 -0400, you wrote:
> 
> >768 / 768 (gold  <--- that's me )
> >
> >My isp says their router is configured for 768 Kb/s *each* way. I
> >have put a call into GTE to see if they can test/verify that I have the
> >service level I requested, but they didn't know how to check and are
> >looking into it.
> 
> I know you're not talking cable modems but this is similarly bleeding edge
> technology to the telcos and if you check out their newsgroup you'll see a
> big percentage of angry or depressed posts about really terrible service.
> So I would guess that you are not getting what you are paying for and that
> there is a reasonable chance that you will have some trouble getting the
> problem resolved.  Best of luck.  I wish I had the option of getting *only*
> 364K speeds out here in the corn fields of Illinois :)

There is a misconception for most users of Cable Modems and ADSL
service.

For instance, if service is advertised as 384K aDSL, most people
assume they have 384K to the internet.  This is not so.  They
have 384K to the telco central office, and usually the bandwidth
there is allocated so that 384K or 768K or T1 is allocated
among all their aDSL customers.  In other words, while each
customer can peak at 384K, the aggregation of all customers
cannot exceed a certain amount....say a T1.

Cable modems work identically.  Thus there is a vast difference
between a 384K aDSL or a 500K cable modem and a dedicated
leased or frame relay line to the internet of 384K.  The latter
will be much cleaner and faster because there are no bandwidth-
sucking customers sharing it with you.

Most Cable modem users have been quite pleased with their initial
hookup....but as more customers sign on, the slowies start showing
up.  You get what you pay for, and there is no free lunch.  Read
the fine print.


===

Subject: Re: Bandwidth measuring tool
From: Ramon Gandia <rfg@nook.net>
Date: Fri, 18 Jun 1999 19:53:56 +0000


Charles Galpin wrote:

> As far as some of my previous statements, I realized something last night.
> These xDSL numbers are in kilobits/sec, whereas the pathchar output was in
> kilobytes/sec. So I think I was complaining that the available bandwidth
> was actually *much* larger than my allocated bandwidth. I'm an idiot.

You have learned something, so you are not an idiot.  Big difference.

For sync circuits, like leased lines or frame relay, it is 
8 bits per byte.  On async circuits, it generally is 10 bits
per byte because of the start and stop bits.  So with modem
circuits, divide by 10 not by 8 to get bytes per second.

===

Subject: USWest DSL strangeness
From: "Geocrawler.com" <archiver@db.geocrawler.com>
Date: Wed, 4 Aug 1999 10:12:35 -0500


This message was sent from Geocrawler.com by "Brad Hilton"
<bhilton@vpop.net> Be sure to reply to that address.

Hi all,

I have been using uswest dsl for about 9 months with no
trouble.  However, last night I helped a friend get setup
and it was a nightmare.

They have changed their dsl setup from using bridging to ppp
with nat.  Under win98 everything is working perfectly.
However, under redhat I was unable to get things configured
properly.

First, I tried dhcpcd.  This hung and finally timed out, so
I tried dhcpcd -r (which using a different protocol).  This
worked, and assigned my computer with an ip address.  It
also overwrote /etc/resolv.conf with USwest's nameserver
info.

After this I was able to ping out just fine to ip addresses,
but dns would *not* work.  Even trying to query other
nameservers wouldn't work.  It was almost like NAT was
partially broken on the cisco dsl modem, or that the dns
queries were being firewalled.

I finally had to install bind and configure a dns server
just to get dns working for my friend!

Has anyone else seen anything like this before?

Just to clarify:

ping <ip_address> works.

nslookup <hostname> does not work.  nslookup <hostname>
<nameserver> does not work.

They don't return an error, they just hang...

Contents of /etc/resolv.conf are: 
  -------------------------
  nameserver 204.147.80.1 
  -------------------------

===

From: Bryan Opfer [mailto:redhat@balor.tldinc.net]
Date: Tuesday, August 03, 1999 4:36 PM
Subject: ADSL and DHCP


I just had an ADSL line installed and I am having some trouble getting
DHCP to work.  When I activate the interface, I get the following message:

	Aug  3 14:07:37 localhost kernel: eth0: Tx Ring full,
	refusing to send buffer.

I have a stock Redhat 6.0 system with a 3Com 3C900 NIC and it connects
fine in Win98.  Anyone know how to get it to work?

===

Subject: RE: ADSL and DHCP
From: "Matt Shirel" <shirel@iso.net>
Date: Wed, 4 Aug 1999 08:09:14 -0500


>From the error message, this sounds more like a NIC driver problem than a DHCP
problem. Can you establish any other kind of network activity
(ping,telnet,etc...)? You might try looking around the web pages at:
http://cesdis.gsfc.nasa.gov/linux/drivers
They are full of good information..




===
Subject: Re: apache not answering under 6.0
From: "David Wall" <dwall@myEastside.com>
Date: Fri, 6 Aug 1999 19:35:25 -0700


Thanks for all the help I've gotten.  I think I've discovered some weirdness
with my DSL ISP (LightRealm).  I will work with them to resolve the problem,
if in fact it is their problem.

Using the tcpdump program to watch packets over my ethernet card, as well as
the DIGEX web page which lets me do easy ping/traceroute from the various
NAPs.

I have discovered that when the web pages timeout from AOL and MSN, there is
no activity on tcpdump. So, from DIGEX, I was able to determine that I could
not do a ping or traceroute either.

However, if I persisted and tried pinging repeatedly from DIGEX, eventually
it would go through. Once it did, I found that the AOL/MSN connections also
magically worked then.

So, my thought is that they have some unusual configuration for handling IP
addresses on their router so that it knows which DSL link to send the
traffic over.

When I had ISDN, I had a router on my end. When I went with DSL, the router
is on their end.  Do you think that's a security hole for me, since I'd
guess that all of my LAN traffic is somehow also routed over the DSL link,
since the DSL modem is connected to my hub as well?

Anyway, when asked about my netmask and such, Gordon made me think.  I was
told that my IP addresses (I have 16, which itself is odd since I'd expect
to only get 14, with the first and last addresses in the subnet not being
available for general use), and that they begin at 216.122.43.85. They also
mentioned my subnet mask was 255.255.255.0.  This did not add up.  Assuming
a more typical routing world, I'd expect to addresses from .80 to .96 (with
usable addresses from .81 through .95) and my mask would be 255.255.255.240.

So, I'm checking with them, but I'd guess that they have a different scheme
for routing than what I learned years ago.  It would seem that because they
cannot do simply ANDing to determine which subnet it goes on, they have
another lookup scheme.  I'd guess that as my activity goes down, my IP
address gets cached out, and when a new request comes in, sometimes it times
out before it can all get setup.  This causes the intermittent timeouts.
Then, once my address is in their cache, things work smoothly.

Does any of this sound plausible?  Very unusual to be sure.

Thanks for all the help I received.  I was truly stumped, but now I believe
it's not my misconfiguration, which is what RH support suggested in their 10
seconds of troubleshooting.

I've seen some snide remarks about AOL, and while they may be honked up
somewhat, you had better learn to live with them if you are on the Internet.
They have by far the largest customer base, are the largest ISP, and
therefore if you cannot be accessed by AOL, then you cannot be accessed by a
sizeable population of web surfers.  With that said, AOL is weak for those
who understand technology, but I guess it's good for those that know
nothing. And shouldn't web surfing require no knowledge of that stuff.  I
mean, what is the MHz/KHz of TV Channel 7?  Who cares?!<smile>  Web surfing
must get easier...

===

Subject: Re: apache not answering under 6.0
From: Uncle Meat <kcsmart@worldinter.net>
Date: Fri, 06 Aug 1999 21:52:39 -0500 (CDT)

On 07-Aug-99 David Wall opined:
<SNIP>

> I've seen some snide remarks about AOL, and while they may be honked
> up
> somewhat, you had better learn to live with them if you are on the
> Internet.
> They have by far the largest customer base, are the largest ISP, and
> therefore if you cannot be accessed by AOL, then you cannot be
> accessed by a
> sizeable population of web surfers.  With that said, AOL is weak for
> those
> who understand technology, but I guess it's good for those that know
> nothing. And shouldn't web surfing require no knowledge of that stuff.
> I
> mean, what is the MHz/KHz of TV Channel 7?  Who cares?!<smile>  Web
> surfing
> must get easier...

So, if AOL can't get it right _everybody_ else should conform?

The MHz/KHz of TV Channel 7 may not make a difference to the user. But,
if the receiver is tuned improperly, the user won't see it. The same
applies to AOL. If they're on a different channel, how can users expect
to receive the materials transmitted at the proper frequency? They
should then dump the defective receiver (AOL) and buy a new one that
operates properly.

===

Subject: Putting the DSL pedal to the metal
From: "Juha Saarinen" <juha_saarinen@email.msn.com>
Date: Thu, 23 Sep 1999 14:06:37 +1200


After a long wait I now have ADSL service... wheee!

However, it was a bit of an anti-climax at first. According to the monitor
on the Nokia M10 ADSL router, I'm running PPP over ATM at ~4.7Mbps. (It's
5.7Mbps downstairs, but I'm not allowed to drag my gear there... %-)).

So, I should be getting a theoretical max of ~500KBps. The installation took
place with the Linux box booted into Win98 and we did a few test downloads.
Ftp from my ISP zoomed along at 85KBps, and ~25KBps from Australian and US
ftp sites. Good, but not that impressive.

Booted the system into Linux, and got slightly improved throughput
immediately -- 35KBps from ftp sites outside NZ, just over a 100KBps from
the ISP's ftp server.

Seeing that the connection had big latencies -- the ISP puts all the ADSL
bandwidth across satellite links -- I figured it was necessary to crank up
the RWIN. With Windows, you edit the Registry; with Linux...? In the past, I
thought the way to do it was to hack the tcp.h in /usr/src/include etc. and
recompile the kernel. I asked Alan Cox just to be sure, and he told me the
way to do it properly.

Alan said the Linux kernel supports really large windows, up to 256KB, but
to be safe, it defaults to 32,767 bytes. The way to change this is to echo
double the desired RWIN into /proc/sys/net/core/rmem_default and rmem_max. I
put 524288 into both (rmem_default is the default RWIN that's offered to
application that don't request a specific size; rmem_max is the max RWIN any
application can request).

That really speeded things up for me. I now get ~225KBps on local http and
ftp downloads, and roughly half that on international ones. Using tcpdump, I
see that most of the time, I get a 65K window.

Thought this might be of interest to people with DSL connections.


===

Subject: Re: Putting the DSL pedal to the metal
From: Duncan Hill <dhill@sunbeach.net>
Date: Wed, 22 Sep 1999 22:24:50 -0400 (EDT)


On Thu, 23 Sep 1999, Juha Saarinen wrote:

> Alan said the Linux kernel supports really large windows, up to 256KB, but
> to be safe, it defaults to 32,767 bytes. The way to change this is to echo
> double the desired RWIN into /proc/sys/net/core/rmem_default and rmem_max. I
> put 524288 into both (rmem_default is the default RWIN that's offered to
> application that don't request a specific size; rmem_max is the max RWIN any
> application can request).

Really dumb question.  Does the RWIN affect ethernet connections?  Or
is there a bigger default for NICs?  A cat of
/proc/sys/net/core/rmem_default reveals 65535, as does _max.

===

Subject: Re: Putting the DSL pedal to the metal
From: Charles Galpin <cgalpin@lighthouse-software.com>
Date: Wed, 22 Sep 1999 22:31:30 -0400 (EDT)

I'm very interested in this. However, my /proc/sys/net/core/
directory is read only ( RH5.1/2.0.36 ). Does this not apply to 2.0.x
kernels? 

===

Subject: RE: Putting the DSL pedal to the metal
From: "Juha Saarinen" <juha_saarinen@email.msn.com>
Date: Thu, 23 Sep 1999 17:06:35 +1200


> Really dumb question.  Does the RWIN affect ethernet connections?  Or
> is there a bigger default for NICs?  A cat of
> /proc/sys/net/core/rmem_default reveals 65535, as does _max.

Not a dumb question at all, but my answer might be %-). I understand it
(admittedly not very well) that RWIN is negotiated between a server and a
client. It's up to the application to either negotiate it, or let the TCP/IP
stack do it. So... it depends on what you run over your Ethernet connection
I guess.

Anyone else have a better answer?

===

Subject: RE: Putting the DSL pedal to the metal
From: "Juha Saarinen" <juha_saarinen@email.msn.com>
Date: Thu, 23 Sep 1999 17:14:41 +1200


> Congrat's Juha... I know you've languished for some time with...
> ahem... less
> than desirable bandwidth!

:-) Thanks, I wrung every available bit/byte out of my poor 56K modem for a
very long time... glad that's over.

> Can you elaborate on this? I just checked to see if this might
> help with my
> situation (which isn't bad) but rmem_default and rmem_max do not
> exist in the
> proc file system I'm concerned with (kernel 2.0.38 on this box in
> particular).

I think, and will verify it in a moment, that this only applies for the
2.2.x kernels.

The general idea behind big RWINs is to receive a large dollop of data
before stopping the transmission and sending an ACK and waiting for the
transmission to start again. With modems, I found that upping the RWIN on
Windows boxes from a puny 2144 or 8192 bytes to 16 or even 32K really made a
difference. There is some risk in going beyond 32K -- apparently, it breaks
some TCP/IP stacks -- but I haven't found any problems yet.

You'd see the biggest improvement on connections like mine, with long
delays. Satellite users especially benefit from large TCP windows. There is
a good article about it on the MS TechNet site, which describes how a winery
with satellite connection set up NT Server with big RWINs etc. I like some
of the advice given, like not running Word from a server across a satellite
line... :-D

===

Subject: Re: Putting the DSL pedal to the metal
From: Greg Thomas <gregt@nadel.com>
Date: Thu, 23 Sep 1999 11:35:31 -0700 (PDT)




On Thu, 23 Sep 1999, Jack Byers wrote:

> Juha Saarinen said,
> 
> >After a long wait I now have ADSL service... wheee!
> 
> >However, it was a bit of an anti-climax at first.
> >According to the monitor
> >on the Nokia M10 ADSL router, I'm running PPP over ATM at ~4.7Mbps.
> 
> very interesting info re size of windows effect on speed of ADSL.
> 
> But I have dumb question re ADSL:
> 
> you state your ADSL is connected  by running PPP over ATM
> 
> my ADSL is via eth0, doesn't use PPP at all
> 
> Can someone explain the difference?

I'm sure someone will give a complete answer but it really depends on your
equipment.  If you've got an internal xDSL card then you're going to be
able to tell right away how you're connected.  But if eth0 is connected to
a bridge or router then you need to check the router/bridge for what it is
using for communication.


===

Subject: Re: Putting the DSL pedal to the metal
From: "Juha Saarinen" <juha_saarinen@email.msn.com>
Date: Fri, 24 Sep 1999 09:46:36 +1200


Hi Jack,

> very interesting info re size of windows effect on speed of ADSL.
>
> But I have dumb question re ADSL:
>
> you state your ADSL is connected  by running PPP over ATM
>
> my ADSL is via eth0, doesn't use PPP at all
>
> Can someone explain the difference?

Different telco implementation? It looks like the I've got ATM as the
lowest-layer protocol, over which PPP is used to shunt TCP/IP packets back
and forth. I don't know enough yet about how this works... could be talking
out of my hat. Considering the relatively short distance that Ethernet goes,
I don't understand how you could use it in a public network, but... like I
said, I've got lots to learn about this subject.


> Would your windowsize advice re Alan Cox apply to my eth0 adsl?

Give it a go and experiment. It looks like RWINs are negotiated at the
application level, unless the app isn't aware of it, and simply uses the OS
default value. At the moment, I'm testing with RWINs that are even integers
of MSS (Maximum Segment Size) = 1460 bytes, to see if it makes any
difference.


===

Subject: Re: Putting the DSL pedal to the metal
From: Hal Burgiss <hburgiss@bellsouth.net>
Date: Thu, 23 Sep 1999 18:29:47 -0400


On Fri, Sep 24, 1999 at 09:46:36AM +1200, Juha Saarinen wrote:
> Hi Jack,
> 
> > very interesting info re size of windows effect on speed of ADSL.
> >
> > But I have dumb question re ADSL:
> >
> > you state your ADSL is connected  by running PPP over ATM
> >
> > my ADSL is via eth0, doesn't use PPP at all
> >
> > Can someone explain the difference?
> 
> Different telco implementation? It looks like the I've got ATM as the
> lowest-layer protocol, over which PPP is used to shunt TCP/IP packets back
> and forth. I don't know enough yet about how this works... could be talking
> out of my hat. Considering the relatively short distance that Ethernet goes,
> I don't understand how you could use it in a public network, but... like I
> said, I've got lots to learn about this subject.
> 
 
Well, here in the states a common implementation is to have a DSL
'modem' which is actually more of a bridge, I think. This modem-bridge
is connected via a NIC, hence the eth0. 

FWIW, Jack, I tried upping mine and didn't seem to make much of a
difference with a few quick tests. But I think I was getting pretty
much close to the max already -- 1.2Mbs on a 1.5Mbs connection.

===

Subject: Re: Putting the DSL pedal to the metal
From: "Jack Byers" <byersj@hotmail.com>
Date: Thu, 23 Sep 1999 17:15:16 PDT


question from Jack Byers:
> > But I have dumb question re ADSL:
> >
> > you state your ADSL is connected  by running PPP over ATM
> >
> > my ADSL is via eth0, doesn't use PPP at all
> >
> > Can someone explain the difference?
>

reply from Juha Saarinen:
>Different telco implementation? It looks like the I've got ATM as the
>lowest-layer protocol, over which PPP is used to shunt TCP/IP packets back
>and forth. I don't know enough yet about how this works... could be talking
>out of my hat. Considering the relatively short distance that Ethernet 
>goes,
>I don't understand how you could use it in a public network, but... like I
>said, I've got lots to learn about this subject.
>

response from Hal Burgiss:
Well, here in the states a common implementation is to have a DSL
'modem' which is actually more of a bridge, I think. This modem-bridge
is connected via a NIC, hence the eth0.


   ------------

The latter from Hal Burgiss
is exactly what my Adsl configuration is:
an Alcatel 1000 (router/modem ?) and connected via a nic, hence eth0
No use of PPP required by the user.

It was/still am  unknowledgeable about other technologies
such as Juha's connection that somehow uses
"PPP to shunt tcp/ip packets"
I am not really knowledgeable about _any_ of
the underlying technologies, be it ppp, tcp/ip, atm, eth0 or whatever.
  I was
just struck by the fact that I dont use PPP at all,
and I interpreted Juha's remarks tomean that he does use PPP.
My interpretation may be all wet; Juha may be referring
to the underlying technologies, whereas I was referrring to
what connection hardware and configuration software
I use with my adsl,
which is a nic, an adsl modem, eth0.

Juha, do I understand you correctly to mean that with your adsl
you still configure
and use PPP in the same or similar way that you did for
connecting with a normal 56k dial up modem?
k
===

Subject: Re: Putting the DSL pedal to the metal
From: Greg Thomas <gregt@nadel.com>
Date: Thu, 23 Sep 1999 17:28:05 -0700 (PDT)




On Thu, 23 Sep 1999, Jack Byers wrote:

> question from Jack Byers:
> > > But I have dumb question re ADSL:
> > >
> > > you state your ADSL is connected  by running PPP over ATM
> > >
> > > my ADSL is via eth0, doesn't use PPP at all
> > >
> > > Can someone explain the difference?
> >
> 
> reply from Juha Saarinen:
> >Different telco implementation? It looks like the I've got ATM as the
> >lowest-layer protocol, over which PPP is used to shunt TCP/IP packets back
> >and forth. I don't know enough yet about how this works... could be talking
> >out of my hat. Considering the relatively short distance that Ethernet 
> >goes,
> >I don't understand how you could use it in a public network, but... like I
> >said, I've got lots to learn about this subject.
> >
> 
> response from Hal Burgiss:
> Well, here in the states a common implementation is to have a DSL
> 'modem' which is actually more of a bridge, I think. This modem-bridge
> is connected via a NIC, hence the eth0.
> 
> 
> ------------
> 
> The latter from Hal Burgiss
> is exactly what my Adsl configuration is:
> an Alcatel 1000 (router/modem ?) and connected via a nic, hence eth0
> No use of PPP required by the user.
> 
> It was/still am  unknowledgeable about other technologies
> such as Juha's connection that somehow uses
> "PPP to shunt tcp/ip packets"
> I am not really knowledgeable about _any_ of
> the underlying technologies, be it ppp, tcp/ip, atm, eth0 or whatever.
>   I was
> just struck by the fact that I dont use PPP at all,
> and I interpreted Juha's remarks tomean that he does use PPP.
> My interpretation may be all wet; Juha may be referring
> to the underlying technologies, whereas I was referrring to
> what connection hardware and configuration software
> I use with my adsl,
> which is a nic, an adsl modem, eth0.
> 
> Juha, do I understand you correctly to mean that with your adsl
> you still configure
> and use PPP in the same or similar way that you did for
> connecting with a normal 56k dial up modem?
> 

No, I believe his router (or ADSL modem for the general public, it's not a
modem but a bridge or router) is doing PPP over ATM and he is connecting
to his router with eth0.

===

Subject: RE: Putting the DSL pedal to the metal
From: "Juha Saarinen" <juha_saarinen@email.msn.com>
Date: Fri, 24 Sep 1999 16:46:45 +1200


> No, I believe his router (or ADSL modem for the general public, it's not a
> modem but a bridge or router) is doing PPP over ATM and he is connecting
> to his router with eth0.

That's correct. The router has an IP that my internal LAN sees, and an IP
that the ISP's router sees, and routes traffic between the two. It's a fair
bit more complicated than PPP over a modem connection, and I haven't got all
the details of it worked out yet.

===

Subject: RE: Putting the DSL pedal to the metal
From: "Juha Saarinen" <juha_saarinen@email.msn.com>
Date: Fri, 24 Sep 1999 16:44:52 +1200


> The latter from Hal Burgiss
> is exactly what my Adsl configuration is:
> an Alcatel 1000 (router/modem ?) and connected via a nic, hence eth0
> No use of PPP required by the user.
>
> It was/still am  unknowledgeable about other technologies
> such as Juha's connection that somehow uses
> "PPP to shunt tcp/ip packets"
> I am not really knowledgeable about _any_ of
> the underlying technologies, be it ppp, tcp/ip, atm, eth0 or whatever.
>   I was
> just struck by the fact that I dont use PPP at all,
> and I interpreted Juha's remarks tomean that he does use PPP.
> My interpretation may be all wet; Juha may be referring
> to the underlying technologies, whereas I was referrring to
> what connection hardware and configuration software
> I use with my adsl,
> which is a nic, an adsl modem, eth0.
>
> Juha, do I understand you correctly to mean that with your adsl
> you still configure
> and use PPP in the same or similar way that you did for
> connecting with a normal 56k dial up modem?

Yes, I've got PPP, and log onto my ISP with PAP (peer authentication
protocol). It runs over ATM, but I understand that you can run PPP over
Ethernet as well.

Not sure how your ADSL works, but it does sound like it's different from
mine.

===

Subject: PPP default route with DSL?
From: "Todd A. Jacobs" <tajacobs@nvbell.net>
Date: Wed, 29 Sep 1999 00:11:44 -0700 (PDT)


Anyone had any experience setting up PPP in conjunction with DSL? I'd like
to occasionally dial into another ISP than the one I've got for my DSL.
The problem is that (I think) I need a default route for the PPP
connection, but I already have an existing default route for eth1 via the
DSL modem.

Any idea how I can use both at the same time?

===

the rest of The Pile (a partial mailing list archive)

doom@kzsu.stanford.edu