0001 .. SPDX-License-Identifier: GPL-2.0
0002
0003 ==========================================
0004 EQL Driver: Serial IP Load Balancing HOWTO
0005 ==========================================
0006
0007 Simon "Guru Aleph-Null" Janes, simon@ncm.com
0008
0009 v1.1, February 27, 1995
0010
0011 This is the manual for the EQL device driver. EQL is a software device
0012 that lets you load-balance IP serial links (SLIP or uncompressed PPP)
0013 to increase your bandwidth. It will not reduce your latency (i.e. ping
0014 times) except in the case where you already have lots of traffic on
0015 your link, in which it will help them out. This driver has been tested
0016 with the 1.1.75 kernel, and is known to have patched cleanly with
0017 1.1.86. Some testing with 1.1.92 has been done with the v1.1 patch
0018 which was only created to patch cleanly in the very latest kernel
0019 source trees. (Yes, it worked fine.)
0020
0021 1. Introduction
0022 ===============
0023
0024 Which is worse? A huge fee for a 56K leased line or two phone lines?
0025 It's probably the former. If you find yourself craving more bandwidth,
0026 and have a ISP that is flexible, it is now possible to bind modems
0027 together to work as one point-to-point link to increase your
0028 bandwidth. All without having to have a special black box on either
0029 side.
0030
0031
0032 The eql driver has only been tested with the Livingston PortMaster-2e
0033 terminal server. I do not know if other terminal servers support load-
0034 balancing, but I do know that the PortMaster does it, and does it
0035 almost as well as the eql driver seems to do it (-- Unfortunately, in
0036 my testing so far, the Livingston PortMaster 2e's load-balancing is a
0037 good 1 to 2 KB/s slower than the test machine working with a 28.8 Kbps
0038 and 14.4 Kbps connection. However, I am not sure that it really is
0039 the PortMaster, or if it's Linux's TCP drivers. I'm told that Linux's
0040 TCP implementation is pretty fast though.--)
0041
0042
0043 I suggest to ISPs out there that it would probably be fair to charge
0044 a load-balancing client 75% of the cost of the second line and 50% of
0045 the cost of the third line etc...
0046
0047
0048 Hey, we can all dream you know...
0049
0050
0051 2. Kernel Configuration
0052 =======================
0053
0054 Here I describe the general steps of getting a kernel up and working
0055 with the eql driver. From patching, building, to installing.
0056
0057
0058 2.1. Patching The Kernel
0059 ------------------------
0060
0061 If you do not have or cannot get a copy of the kernel with the eql
0062 driver folded into it, get your copy of the driver from
0063 ftp://slaughter.ncm.com/pub/Linux/LOAD_BALANCING/eql-1.1.tar.gz.
0064 Unpack this archive someplace obvious like /usr/local/src/. It will
0065 create the following files::
0066
0067 -rw-r--r-- guru/ncm 198 Jan 19 18:53 1995 eql-1.1/NO-WARRANTY
0068 -rw-r--r-- guru/ncm 30620 Feb 27 21:40 1995 eql-1.1/eql-1.1.patch
0069 -rwxr-xr-x guru/ncm 16111 Jan 12 22:29 1995 eql-1.1/eql_enslave
0070 -rw-r--r-- guru/ncm 2195 Jan 10 21:48 1995 eql-1.1/eql_enslave.c
0071
0072 Unpack a recent kernel (something after 1.1.92) someplace convenient
0073 like say /usr/src/linux-1.1.92.eql. Use symbolic links to point
0074 /usr/src/linux to this development directory.
0075
0076
0077 Apply the patch by running the commands::
0078
0079 cd /usr/src
0080 patch </usr/local/src/eql-1.1/eql-1.1.patch
0081
0082
0083 2.2. Building The Kernel
0084 ------------------------
0085
0086 After patching the kernel, run make config and configure the kernel
0087 for your hardware.
0088
0089
0090 After configuration, make and install according to your habit.
0091
0092
0093 3. Network Configuration
0094 ========================
0095
0096 So far, I have only used the eql device with the DSLIP SLIP connection
0097 manager by Matt Dillon (-- "The man who sold his soul to code so much
0098 so quickly."--) . How you configure it for other "connection"
0099 managers is up to you. Most other connection managers that I've seen
0100 don't do a very good job when it comes to handling more than one
0101 connection.
0102
0103
0104 3.1. /etc/rc.d/rc.inet1
0105 -----------------------
0106
0107 In rc.inet1, ifconfig the eql device to the IP address you usually use
0108 for your machine, and the MTU you prefer for your SLIP lines. One
0109 could argue that MTU should be roughly half the usual size for two
0110 modems, one-third for three, one-fourth for four, etc... But going
0111 too far below 296 is probably overkill. Here is an example ifconfig
0112 command that sets up the eql device::
0113
0114 ifconfig eql 198.67.33.239 mtu 1006
0115
0116 Once the eql device is up and running, add a static default route to
0117 it in the routing table using the cool new route syntax that makes
0118 life so much easier::
0119
0120 route add default eql
0121
0122
0123 3.2. Enslaving Devices By Hand
0124 ------------------------------
0125
0126 Enslaving devices by hand requires two utility programs: eql_enslave
0127 and eql_emancipate (-- eql_emancipate hasn't been written because when
0128 an enslaved device "dies", it is automatically taken out of the queue.
0129 I haven't found a good reason to write it yet... other than for
0130 completeness, but that isn't a good motivator is it?--)
0131
0132
0133 The syntax for enslaving a device is "eql_enslave <master-name>
0134 <slave-name> <estimated-bps>". Here are some example enslavings::
0135
0136 eql_enslave eql sl0 28800
0137 eql_enslave eql ppp0 14400
0138 eql_enslave eql sl1 57600
0139
0140 When you want to free a device from its life of slavery, you can
0141 either down the device with ifconfig (eql will automatically bury the
0142 dead slave and remove it from its queue) or use eql_emancipate to free
0143 it. (-- Or just ifconfig it down, and the eql driver will take it out
0144 for you.--)::
0145
0146 eql_emancipate eql sl0
0147 eql_emancipate eql ppp0
0148 eql_emancipate eql sl1
0149
0150
0151 3.3. DSLIP Configuration for the eql Device
0152 -------------------------------------------
0153
0154 The general idea is to bring up and keep up as many SLIP connections
0155 as you need, automatically.
0156
0157
0158 3.3.1. /etc/slip/runslip.conf
0159 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
0160
0161 Here is an example runslip.conf::
0162
0163 name sl-line-1
0164 enabled
0165 baud 38400
0166 mtu 576
0167 ducmd -e /etc/slip/dialout/cua2-288.xp -t 9
0168 command eql_enslave eql $interface 28800
0169 address 198.67.33.239
0170 line /dev/cua2
0171
0172 name sl-line-2
0173 enabled
0174 baud 38400
0175 mtu 576
0176 ducmd -e /etc/slip/dialout/cua3-288.xp -t 9
0177 command eql_enslave eql $interface 28800
0178 address 198.67.33.239
0179 line /dev/cua3
0180
0181
0182 3.4. Using PPP and the eql Device
0183 ---------------------------------
0184
0185 I have not yet done any load-balancing testing for PPP devices, mainly
0186 because I don't have a PPP-connection manager like SLIP has with
0187 DSLIP. I did find a good tip from LinuxNET:Billy for PPP performance:
0188 make sure you have asyncmap set to something so that control
0189 characters are not escaped.
0190
0191
0192 I tried to fix up a PPP script/system for redialing lost PPP
0193 connections for use with the eql driver the weekend of Feb 25-26 '95
0194 (Hereafter known as the 8-hour PPP Hate Festival). Perhaps later this
0195 year.
0196
0197
0198 4. About the Slave Scheduler Algorithm
0199 ======================================
0200
0201 The slave scheduler probably could be replaced with a dozen other
0202 things and push traffic much faster. The formula in the current set
0203 up of the driver was tuned to handle slaves with wildly different
0204 bits-per-second "priorities".
0205
0206
0207 All testing I have done was with two 28.8 V.FC modems, one connecting
0208 at 28800 bps or slower, and the other connecting at 14400 bps all the
0209 time.
0210
0211
0212 One version of the scheduler was able to push 5.3 K/s through the
0213 28800 and 14400 connections, but when the priorities on the links were
0214 very wide apart (57600 vs. 14400) the "faster" modem received all
0215 traffic and the "slower" modem starved.
0216
0217
0218 5. Testers' Reports
0219 ===================
0220
0221 Some people have experimented with the eql device with newer
0222 kernels (than 1.1.75). I have since updated the driver to patch
0223 cleanly in newer kernels because of the removal of the old "slave-
0224 balancing" driver config option.
0225
0226
0227 - icee from LinuxNET patched 1.1.86 without any rejects and was able
0228 to boot the kernel and enslave a couple of ISDN PPP links.
0229
0230 5.1. Randolph Bentson's Test Report
0231 -----------------------------------
0232
0233 ::
0234
0235 From bentson@grieg.seaslug.org Wed Feb 8 19:08:09 1995
0236 Date: Tue, 7 Feb 95 22:57 PST
0237 From: Randolph Bentson <bentson@grieg.seaslug.org>
0238 To: guru@ncm.com
0239 Subject: EQL driver tests
0240
0241
0242 I have been checking out your eql driver. (Nice work, that!)
0243 Although you may already done this performance testing, here
0244 are some data I've discovered.
0245
0246 Randolph Bentson
0247 bentson@grieg.seaslug.org
0248
0249 ------------------------------------------------------------------
0250
0251
0252 A pseudo-device driver, EQL, written by Simon Janes, can be used
0253 to bundle multiple SLIP connections into what appears to be a
0254 single connection. This allows one to improve dial-up network
0255 connectivity gradually, without having to buy expensive DSU/CSU
0256 hardware and services.
0257
0258 I have done some testing of this software, with two goals in
0259 mind: first, to ensure it actually works as described and
0260 second, as a method of exercising my device driver.
0261
0262 The following performance measurements were derived from a set
0263 of SLIP connections run between two Linux systems (1.1.84) using
0264 a 486DX2/66 with a Cyclom-8Ys and a 486SLC/40 with a Cyclom-16Y.
0265 (Ports 0,1,2,3 were used. A later configuration will distribute
0266 port selection across the different Cirrus chips on the boards.)
0267 Once a link was established, I timed a binary ftp transfer of
0268 289284 bytes of data. If there were no overhead (packet headers,
0269 inter-character and inter-packet delays, etc.) the transfers
0270 would take the following times::
0271
0272 bits/sec seconds
0273 345600 8.3
0274 234600 12.3
0275 172800 16.7
0276 153600 18.8
0277 76800 37.6
0278 57600 50.2
0279 38400 75.3
0280 28800 100.4
0281 19200 150.6
0282 9600 301.3
0283
0284 A single line running at the lower speeds and with large packets
0285 comes to within 2% of this. Performance is limited for the higher
0286 speeds (as predicted by the Cirrus databook) to an aggregate of
0287 about 160 kbits/sec. The next round of testing will distribute
0288 the load across two or more Cirrus chips.
0289
0290 The good news is that one gets nearly the full advantage of the
0291 second, third, and fourth line's bandwidth. (The bad news is
0292 that the connection establishment seemed fragile for the higher
0293 speeds. Once established, the connection seemed robust enough.)
0294
0295 ====== ======== === ======== ======= ======= ===
0296 #lines speed mtu seconds theory actual %of
0297 kbit/sec duration speed speed max
0298 ====== ======== === ======== ======= ======= ===
0299 3 115200 900 _ 345600
0300 3 115200 400 18.1 345600 159825 46
0301 2 115200 900 _ 230400
0302 2 115200 600 18.1 230400 159825 69
0303 2 115200 400 19.3 230400 149888 65
0304 4 57600 900 _ 234600
0305 4 57600 600 _ 234600
0306 4 57600 400 _ 234600
0307 3 57600 600 20.9 172800 138413 80
0308 3 57600 900 21.2 172800 136455 78
0309 3 115200 600 21.7 345600 133311 38
0310 3 57600 400 22.5 172800 128571 74
0311 4 38400 900 25.2 153600 114795 74
0312 4 38400 600 26.4 153600 109577 71
0313 4 38400 400 27.3 153600 105965 68
0314 2 57600 900 29.1 115200 99410.3 86
0315 1 115200 900 30.7 115200 94229.3 81
0316 2 57600 600 30.2 115200 95789.4 83
0317 3 38400 900 30.3 115200 95473.3 82
0318 3 38400 600 31.2 115200 92719.2 80
0319 1 115200 600 31.3 115200 92423 80
0320 2 57600 400 32.3 115200 89561.6 77
0321 1 115200 400 32.8 115200 88196.3 76
0322 3 38400 400 33.5 115200 86353.4 74
0323 2 38400 900 43.7 76800 66197.7 86
0324 2 38400 600 44 76800 65746.4 85
0325 2 38400 400 47.2 76800 61289 79
0326 4 19200 900 50.8 76800 56945.7 74
0327 4 19200 400 53.2 76800 54376.7 70
0328 4 19200 600 53.7 76800 53870.4 70
0329 1 57600 900 54.6 57600 52982.4 91
0330 1 57600 600 56.2 57600 51474 89
0331 3 19200 900 60.5 57600 47815.5 83
0332 1 57600 400 60.2 57600 48053.8 83
0333 3 19200 600 62 57600 46658.7 81
0334 3 19200 400 64.7 57600 44711.6 77
0335 1 38400 900 79.4 38400 36433.8 94
0336 1 38400 600 82.4 38400 35107.3 91
0337 2 19200 900 84.4 38400 34275.4 89
0338 1 38400 400 86.8 38400 33327.6 86
0339 2 19200 600 87.6 38400 33023.3 85
0340 2 19200 400 91.2 38400 31719.7 82
0341 4 9600 900 94.7 38400 30547.4 79
0342 4 9600 400 106 38400 27290.9 71
0343 4 9600 600 110 38400 26298.5 68
0344 3 9600 900 118 28800 24515.6 85
0345 3 9600 600 120 28800 24107 83
0346 3 9600 400 131 28800 22082.7 76
0347 1 19200 900 155 19200 18663.5 97
0348 1 19200 600 161 19200 17968 93
0349 1 19200 400 170 19200 17016.7 88
0350 2 9600 600 176 19200 16436.6 85
0351 2 9600 900 180 19200 16071.3 83
0352 2 9600 400 181 19200 15982.5 83
0353 1 9600 900 305 9600 9484.72 98
0354 1 9600 600 314 9600 9212.87 95
0355 1 9600 400 332 9600 8713.37 90
0356 ====== ======== === ======== ======= ======= ===
0357
0358 5.2. Anthony Healy's Report
0359 ---------------------------
0360
0361 ::
0362
0363 Date: Mon, 13 Feb 1995 16:17:29 +1100 (EST)
0364 From: Antony Healey <ahealey@st.nepean.uws.edu.au>
0365 To: Simon Janes <guru@ncm.com>
0366 Subject: Re: Load Balancing
0367
0368 Hi Simon,
0369 I've installed your patch and it works great. I have trialed
0370 it over twin SL/IP lines, just over null modems, but I was
0371 able to data at over 48Kb/s [ISDN link -Simon]. I managed a
0372 transfer of up to 7.5 Kbyte/s on one go, but averaged around
0373 6.4 Kbyte/s, which I think is pretty cool. :)
