374 lines
13 KiB
ReStructuredText
374 lines
13 KiB
ReStructuredText
.. SPDX-License-Identifier: GPL-2.0
|
|
|
|
==========================================
|
|
EQL Driver: Serial IP Load Balancing HOWTO
|
|
==========================================
|
|
|
|
Simon "Guru Aleph-Null" Janes, simon@ncm.com
|
|
|
|
v1.1, February 27, 1995
|
|
|
|
This is the manual for the EQL device driver. EQL is a software device
|
|
that lets you load-balance IP serial links (SLIP or uncompressed PPP)
|
|
to increase your bandwidth. It will not reduce your latency (i.e. ping
|
|
times) except in the case where you already have lots of traffic on
|
|
your link, in which it will help them out. This driver has been tested
|
|
with the 1.1.75 kernel, and is known to have patched cleanly with
|
|
1.1.86. Some testing with 1.1.92 has been done with the v1.1 patch
|
|
which was only created to patch cleanly in the very latest kernel
|
|
source trees. (Yes, it worked fine.)
|
|
|
|
1. Introduction
|
|
===============
|
|
|
|
Which is worse? A huge fee for a 56K leased line or two phone lines?
|
|
It's probably the former. If you find yourself craving more bandwidth,
|
|
and have a ISP that is flexible, it is now possible to bind modems
|
|
together to work as one point-to-point link to increase your
|
|
bandwidth. All without having to have a special black box on either
|
|
side.
|
|
|
|
|
|
The eql driver has only been tested with the Livingston PortMaster-2e
|
|
terminal server. I do not know if other terminal servers support load-
|
|
balancing, but I do know that the PortMaster does it, and does it
|
|
almost as well as the eql driver seems to do it (-- Unfortunately, in
|
|
my testing so far, the Livingston PortMaster 2e's load-balancing is a
|
|
good 1 to 2 KB/s slower than the test machine working with a 28.8 Kbps
|
|
and 14.4 Kbps connection. However, I am not sure that it really is
|
|
the PortMaster, or if it's Linux's TCP drivers. I'm told that Linux's
|
|
TCP implementation is pretty fast though.--)
|
|
|
|
|
|
I suggest to ISPs out there that it would probably be fair to charge
|
|
a load-balancing client 75% of the cost of the second line and 50% of
|
|
the cost of the third line etc...
|
|
|
|
|
|
Hey, we can all dream you know...
|
|
|
|
|
|
2. Kernel Configuration
|
|
=======================
|
|
|
|
Here I describe the general steps of getting a kernel up and working
|
|
with the eql driver. From patching, building, to installing.
|
|
|
|
|
|
2.1. Patching The Kernel
|
|
------------------------
|
|
|
|
If you do not have or cannot get a copy of the kernel with the eql
|
|
driver folded into it, get your copy of the driver from
|
|
ftp://slaughter.ncm.com/pub/Linux/LOAD_BALANCING/eql-1.1.tar.gz.
|
|
Unpack this archive someplace obvious like /usr/local/src/. It will
|
|
create the following files::
|
|
|
|
-rw-r--r-- guru/ncm 198 Jan 19 18:53 1995 eql-1.1/NO-WARRANTY
|
|
-rw-r--r-- guru/ncm 30620 Feb 27 21:40 1995 eql-1.1/eql-1.1.patch
|
|
-rwxr-xr-x guru/ncm 16111 Jan 12 22:29 1995 eql-1.1/eql_enslave
|
|
-rw-r--r-- guru/ncm 2195 Jan 10 21:48 1995 eql-1.1/eql_enslave.c
|
|
|
|
Unpack a recent kernel (something after 1.1.92) someplace convenient
|
|
like say /usr/src/linux-1.1.92.eql. Use symbolic links to point
|
|
/usr/src/linux to this development directory.
|
|
|
|
|
|
Apply the patch by running the commands::
|
|
|
|
cd /usr/src
|
|
patch </usr/local/src/eql-1.1/eql-1.1.patch
|
|
|
|
|
|
2.2. Building The Kernel
|
|
------------------------
|
|
|
|
After patching the kernel, run make config and configure the kernel
|
|
for your hardware.
|
|
|
|
|
|
After configuration, make and install according to your habit.
|
|
|
|
|
|
3. Network Configuration
|
|
========================
|
|
|
|
So far, I have only used the eql device with the DSLIP SLIP connection
|
|
manager by Matt Dillon (-- "The man who sold his soul to code so much
|
|
so quickly."--) . How you configure it for other "connection"
|
|
managers is up to you. Most other connection managers that I've seen
|
|
don't do a very good job when it comes to handling more than one
|
|
connection.
|
|
|
|
|
|
3.1. /etc/rc.d/rc.inet1
|
|
-----------------------
|
|
|
|
In rc.inet1, ifconfig the eql device to the IP address you usually use
|
|
for your machine, and the MTU you prefer for your SLIP lines. One
|
|
could argue that MTU should be roughly half the usual size for two
|
|
modems, one-third for three, one-fourth for four, etc... But going
|
|
too far below 296 is probably overkill. Here is an example ifconfig
|
|
command that sets up the eql device::
|
|
|
|
ifconfig eql 198.67.33.239 mtu 1006
|
|
|
|
Once the eql device is up and running, add a static default route to
|
|
it in the routing table using the cool new route syntax that makes
|
|
life so much easier::
|
|
|
|
route add default eql
|
|
|
|
|
|
3.2. Enslaving Devices By Hand
|
|
------------------------------
|
|
|
|
Enslaving devices by hand requires two utility programs: eql_enslave
|
|
and eql_emancipate (-- eql_emancipate hasn't been written because when
|
|
an enslaved device "dies", it is automatically taken out of the queue.
|
|
I haven't found a good reason to write it yet... other than for
|
|
completeness, but that isn't a good motivator is it?--)
|
|
|
|
|
|
The syntax for enslaving a device is "eql_enslave <master-name>
|
|
<slave-name> <estimated-bps>". Here are some example enslavings::
|
|
|
|
eql_enslave eql sl0 28800
|
|
eql_enslave eql ppp0 14400
|
|
eql_enslave eql sl1 57600
|
|
|
|
When you want to free a device from its life of slavery, you can
|
|
either down the device with ifconfig (eql will automatically bury the
|
|
dead slave and remove it from its queue) or use eql_emancipate to free
|
|
it. (-- Or just ifconfig it down, and the eql driver will take it out
|
|
for you.--)::
|
|
|
|
eql_emancipate eql sl0
|
|
eql_emancipate eql ppp0
|
|
eql_emancipate eql sl1
|
|
|
|
|
|
3.3. DSLIP Configuration for the eql Device
|
|
-------------------------------------------
|
|
|
|
The general idea is to bring up and keep up as many SLIP connections
|
|
as you need, automatically.
|
|
|
|
|
|
3.3.1. /etc/slip/runslip.conf
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
Here is an example runslip.conf::
|
|
|
|
name sl-line-1
|
|
enabled
|
|
baud 38400
|
|
mtu 576
|
|
ducmd -e /etc/slip/dialout/cua2-288.xp -t 9
|
|
command eql_enslave eql $interface 28800
|
|
address 198.67.33.239
|
|
line /dev/cua2
|
|
|
|
name sl-line-2
|
|
enabled
|
|
baud 38400
|
|
mtu 576
|
|
ducmd -e /etc/slip/dialout/cua3-288.xp -t 9
|
|
command eql_enslave eql $interface 28800
|
|
address 198.67.33.239
|
|
line /dev/cua3
|
|
|
|
|
|
3.4. Using PPP and the eql Device
|
|
---------------------------------
|
|
|
|
I have not yet done any load-balancing testing for PPP devices, mainly
|
|
because I don't have a PPP-connection manager like SLIP has with
|
|
DSLIP. I did find a good tip from LinuxNET:Billy for PPP performance:
|
|
make sure you have asyncmap set to something so that control
|
|
characters are not escaped.
|
|
|
|
|
|
I tried to fix up a PPP script/system for redialing lost PPP
|
|
connections for use with the eql driver the weekend of Feb 25-26 '95
|
|
(Hereafter known as the 8-hour PPP Hate Festival). Perhaps later this
|
|
year.
|
|
|
|
|
|
4. About the Slave Scheduler Algorithm
|
|
======================================
|
|
|
|
The slave scheduler probably could be replaced with a dozen other
|
|
things and push traffic much faster. The formula in the current set
|
|
up of the driver was tuned to handle slaves with wildly different
|
|
bits-per-second "priorities".
|
|
|
|
|
|
All testing I have done was with two 28.8 V.FC modems, one connecting
|
|
at 28800 bps or slower, and the other connecting at 14400 bps all the
|
|
time.
|
|
|
|
|
|
One version of the scheduler was able to push 5.3 K/s through the
|
|
28800 and 14400 connections, but when the priorities on the links were
|
|
very wide apart (57600 vs. 14400) the "faster" modem received all
|
|
traffic and the "slower" modem starved.
|
|
|
|
|
|
5. Testers' Reports
|
|
===================
|
|
|
|
Some people have experimented with the eql device with newer
|
|
kernels (than 1.1.75). I have since updated the driver to patch
|
|
cleanly in newer kernels because of the removal of the old "slave-
|
|
balancing" driver config option.
|
|
|
|
|
|
- icee from LinuxNET patched 1.1.86 without any rejects and was able
|
|
to boot the kernel and enslave a couple of ISDN PPP links.
|
|
|
|
5.1. Randolph Bentson's Test Report
|
|
-----------------------------------
|
|
|
|
::
|
|
|
|
From bentson@grieg.seaslug.org Wed Feb 8 19:08:09 1995
|
|
Date: Tue, 7 Feb 95 22:57 PST
|
|
From: Randolph Bentson <bentson@grieg.seaslug.org>
|
|
To: guru@ncm.com
|
|
Subject: EQL driver tests
|
|
|
|
|
|
I have been checking out your eql driver. (Nice work, that!)
|
|
Although you may already done this performance testing, here
|
|
are some data I've discovered.
|
|
|
|
Randolph Bentson
|
|
bentson@grieg.seaslug.org
|
|
|
|
------------------------------------------------------------------
|
|
|
|
|
|
A pseudo-device driver, EQL, written by Simon Janes, can be used
|
|
to bundle multiple SLIP connections into what appears to be a
|
|
single connection. This allows one to improve dial-up network
|
|
connectivity gradually, without having to buy expensive DSU/CSU
|
|
hardware and services.
|
|
|
|
I have done some testing of this software, with two goals in
|
|
mind: first, to ensure it actually works as described and
|
|
second, as a method of exercising my device driver.
|
|
|
|
The following performance measurements were derived from a set
|
|
of SLIP connections run between two Linux systems (1.1.84) using
|
|
a 486DX2/66 with a Cyclom-8Ys and a 486SLC/40 with a Cyclom-16Y.
|
|
(Ports 0,1,2,3 were used. A later configuration will distribute
|
|
port selection across the different Cirrus chips on the boards.)
|
|
Once a link was established, I timed a binary ftp transfer of
|
|
289284 bytes of data. If there were no overhead (packet headers,
|
|
inter-character and inter-packet delays, etc.) the transfers
|
|
would take the following times::
|
|
|
|
bits/sec seconds
|
|
345600 8.3
|
|
234600 12.3
|
|
172800 16.7
|
|
153600 18.8
|
|
76800 37.6
|
|
57600 50.2
|
|
38400 75.3
|
|
28800 100.4
|
|
19200 150.6
|
|
9600 301.3
|
|
|
|
A single line running at the lower speeds and with large packets
|
|
comes to within 2% of this. Performance is limited for the higher
|
|
speeds (as predicted by the Cirrus databook) to an aggregate of
|
|
about 160 kbits/sec. The next round of testing will distribute
|
|
the load across two or more Cirrus chips.
|
|
|
|
The good news is that one gets nearly the full advantage of the
|
|
second, third, and fourth line's bandwidth. (The bad news is
|
|
that the connection establishment seemed fragile for the higher
|
|
speeds. Once established, the connection seemed robust enough.)
|
|
|
|
====== ======== === ======== ======= ======= ===
|
|
#lines speed mtu seconds theory actual %of
|
|
kbit/sec duration speed speed max
|
|
====== ======== === ======== ======= ======= ===
|
|
3 115200 900 _ 345600
|
|
3 115200 400 18.1 345600 159825 46
|
|
2 115200 900 _ 230400
|
|
2 115200 600 18.1 230400 159825 69
|
|
2 115200 400 19.3 230400 149888 65
|
|
4 57600 900 _ 234600
|
|
4 57600 600 _ 234600
|
|
4 57600 400 _ 234600
|
|
3 57600 600 20.9 172800 138413 80
|
|
3 57600 900 21.2 172800 136455 78
|
|
3 115200 600 21.7 345600 133311 38
|
|
3 57600 400 22.5 172800 128571 74
|
|
4 38400 900 25.2 153600 114795 74
|
|
4 38400 600 26.4 153600 109577 71
|
|
4 38400 400 27.3 153600 105965 68
|
|
2 57600 900 29.1 115200 99410.3 86
|
|
1 115200 900 30.7 115200 94229.3 81
|
|
2 57600 600 30.2 115200 95789.4 83
|
|
3 38400 900 30.3 115200 95473.3 82
|
|
3 38400 600 31.2 115200 92719.2 80
|
|
1 115200 600 31.3 115200 92423 80
|
|
2 57600 400 32.3 115200 89561.6 77
|
|
1 115200 400 32.8 115200 88196.3 76
|
|
3 38400 400 33.5 115200 86353.4 74
|
|
2 38400 900 43.7 76800 66197.7 86
|
|
2 38400 600 44 76800 65746.4 85
|
|
2 38400 400 47.2 76800 61289 79
|
|
4 19200 900 50.8 76800 56945.7 74
|
|
4 19200 400 53.2 76800 54376.7 70
|
|
4 19200 600 53.7 76800 53870.4 70
|
|
1 57600 900 54.6 57600 52982.4 91
|
|
1 57600 600 56.2 57600 51474 89
|
|
3 19200 900 60.5 57600 47815.5 83
|
|
1 57600 400 60.2 57600 48053.8 83
|
|
3 19200 600 62 57600 46658.7 81
|
|
3 19200 400 64.7 57600 44711.6 77
|
|
1 38400 900 79.4 38400 36433.8 94
|
|
1 38400 600 82.4 38400 35107.3 91
|
|
2 19200 900 84.4 38400 34275.4 89
|
|
1 38400 400 86.8 38400 33327.6 86
|
|
2 19200 600 87.6 38400 33023.3 85
|
|
2 19200 400 91.2 38400 31719.7 82
|
|
4 9600 900 94.7 38400 30547.4 79
|
|
4 9600 400 106 38400 27290.9 71
|
|
4 9600 600 110 38400 26298.5 68
|
|
3 9600 900 118 28800 24515.6 85
|
|
3 9600 600 120 28800 24107 83
|
|
3 9600 400 131 28800 22082.7 76
|
|
1 19200 900 155 19200 18663.5 97
|
|
1 19200 600 161 19200 17968 93
|
|
1 19200 400 170 19200 17016.7 88
|
|
2 9600 600 176 19200 16436.6 85
|
|
2 9600 900 180 19200 16071.3 83
|
|
2 9600 400 181 19200 15982.5 83
|
|
1 9600 900 305 9600 9484.72 98
|
|
1 9600 600 314 9600 9212.87 95
|
|
1 9600 400 332 9600 8713.37 90
|
|
====== ======== === ======== ======= ======= ===
|
|
|
|
5.2. Anthony Healy's Report
|
|
---------------------------
|
|
|
|
::
|
|
|
|
Date: Mon, 13 Feb 1995 16:17:29 +1100 (EST)
|
|
From: Antony Healey <ahealey@st.nepean.uws.edu.au>
|
|
To: Simon Janes <guru@ncm.com>
|
|
Subject: Re: Load Balancing
|
|
|
|
Hi Simon,
|
|
I've installed your patch and it works great. I have trialed
|
|
it over twin SL/IP lines, just over null modems, but I was
|
|
able to data at over 48Kb/s [ISDN link -Simon]. I managed a
|
|
transfer of up to 7.5 Kbyte/s on one go, but averaged around
|
|
6.4 Kbyte/s, which I think is pretty cool. :)
|