brintos

brintos / linux-shallow public Read only

0
0
Text · 13.0 KiB · a628c4c Raw
374 lines · plain
1.. SPDX-License-Identifier: GPL-2.02 3==========================================4EQL Driver: Serial IP Load Balancing HOWTO5==========================================6 7  Simon "Guru Aleph-Null" Janes, simon@ncm.com8 9  v1.1, February 27, 199510 11  This is the manual for the EQL device driver. EQL is a software device12  that lets you load-balance IP serial links (SLIP or uncompressed PPP)13  to increase your bandwidth. It will not reduce your latency (i.e. ping14  times) except in the case where you already have lots of traffic on15  your link, in which it will help them out. This driver has been tested16  with the 1.1.75 kernel, and is known to have patched cleanly with17  1.1.86.  Some testing with 1.1.92 has been done with the v1.1 patch18  which was only created to patch cleanly in the very latest kernel19  source trees. (Yes, it worked fine.)20 211. Introduction22===============23 24  Which is worse? A huge fee for a 56K leased line or two phone lines?25  It's probably the former.  If you find yourself craving more bandwidth,26  and have a ISP that is flexible, it is now possible to bind modems27  together to work as one point-to-point link to increase your28  bandwidth.  All without having to have a special black box on either29  side.30 31 32  The eql driver has only been tested with the Livingston PortMaster-2e33  terminal server. I do not know if other terminal servers support load-34  balancing, but I do know that the PortMaster does it, and does it35  almost as well as the eql driver seems to do it (-- Unfortunately, in36  my testing so far, the Livingston PortMaster 2e's load-balancing is a37  good 1 to 2 KB/s slower than the test machine working with a 28.8 Kbps38  and 14.4 Kbps connection.  However, I am not sure that it really is39  the PortMaster, or if it's Linux's TCP drivers. I'm told that Linux's40  TCP implementation is pretty fast though.--)41 42 43  I suggest to ISPs out there that it would probably be fair to charge44  a load-balancing client 75% of the cost of the second line and 50% of45  the cost of the third line etc...46 47 48  Hey, we can all dream you know...49 50 512. Kernel Configuration52=======================53 54  Here I describe the general steps of getting a kernel up and working55  with the eql driver.	From patching, building, to installing.56 57 582.1. Patching The Kernel59------------------------60 61  If you do not have or cannot get a copy of the kernel with the eql62  driver folded into it, get your copy of the driver from63  ftp://slaughter.ncm.com/pub/Linux/LOAD_BALANCING/eql-1.1.tar.gz.64  Unpack this archive someplace obvious like /usr/local/src/.  It will65  create the following files::66 67       -rw-r--r-- guru/ncm	198 Jan 19 18:53 1995 eql-1.1/NO-WARRANTY68       -rw-r--r-- guru/ncm	30620 Feb 27 21:40 1995 eql-1.1/eql-1.1.patch69       -rwxr-xr-x guru/ncm	16111 Jan 12 22:29 1995 eql-1.1/eql_enslave70       -rw-r--r-- guru/ncm	2195 Jan 10 21:48 1995 eql-1.1/eql_enslave.c71 72  Unpack a recent kernel (something after 1.1.92) someplace convenient73  like say /usr/src/linux-1.1.92.eql. Use symbolic links to point74  /usr/src/linux to this development directory.75 76 77  Apply the patch by running the commands::78 79       cd /usr/src80       patch </usr/local/src/eql-1.1/eql-1.1.patch81 82 832.2. Building The Kernel84------------------------85 86  After patching the kernel, run make config and configure the kernel87  for your hardware.88 89 90  After configuration, make and install according to your habit.91 92 933. Network Configuration94========================95 96  So far, I have only used the eql device with the DSLIP SLIP connection97  manager by Matt Dillon (-- "The man who sold his soul to code so much98  so quickly."--) .  How you configure it for other "connection"99  managers is up to you.  Most other connection managers that I've seen100  don't do a very good job when it comes to handling more than one101  connection.102 103 1043.1. /etc/rc.d/rc.inet1105-----------------------106 107  In rc.inet1, ifconfig the eql device to the IP address you usually use108  for your machine, and the MTU you prefer for your SLIP lines.	One109  could argue that MTU should be roughly half the usual size for two110  modems, one-third for three, one-fourth for four, etc...  But going111  too far below 296 is probably overkill. Here is an example ifconfig112  command that sets up the eql device::113 114       ifconfig eql 198.67.33.239 mtu 1006115 116  Once the eql device is up and running, add a static default route to117  it in the routing table using the cool new route syntax that makes118  life so much easier::119 120       route add default eql121 122 1233.2. Enslaving Devices By Hand124------------------------------125 126  Enslaving devices by hand requires two utility programs: eql_enslave127  and eql_emancipate (-- eql_emancipate hasn't been written because when128  an enslaved device "dies", it is automatically taken out of the queue.129  I haven't found a good reason to write it yet... other than for130  completeness, but that isn't a good motivator is it?--)131 132 133  The syntax for enslaving a device is "eql_enslave <master-name>134  <slave-name> <estimated-bps>".  Here are some example enslavings::135 136       eql_enslave eql sl0 28800137       eql_enslave eql ppp0 14400138       eql_enslave eql sl1 57600139 140  When you want to free a device from its life of slavery, you can141  either down the device with ifconfig (eql will automatically bury the142  dead slave and remove it from its queue) or use eql_emancipate to free143  it. (-- Or just ifconfig it down, and the eql driver will take it out144  for you.--)::145 146       eql_emancipate eql sl0147       eql_emancipate eql ppp0148       eql_emancipate eql sl1149 150 1513.3. DSLIP Configuration for the eql Device152-------------------------------------------153 154  The general idea is to bring up and keep up as many SLIP connections155  as you need, automatically.156 157 1583.3.1.  /etc/slip/runslip.conf159^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^160 161  Here is an example runslip.conf::162 163	  name		sl-line-1164	  enabled165	  baud		38400166	  mtu		576167	  ducmd		-e /etc/slip/dialout/cua2-288.xp -t 9168	  command	 eql_enslave eql $interface 28800169	  address	 198.67.33.239170	  line		/dev/cua2171 172	  name		sl-line-2173	  enabled174	  baud		38400175	  mtu		576176	  ducmd		-e /etc/slip/dialout/cua3-288.xp -t 9177	  command	 eql_enslave eql $interface 28800178	  address	 198.67.33.239179	  line		/dev/cua3180 181 1823.4. Using PPP and the eql Device183---------------------------------184 185  I have not yet done any load-balancing testing for PPP devices, mainly186  because I don't have a PPP-connection manager like SLIP has with187  DSLIP. I did find a good tip from LinuxNET:Billy for PPP performance:188  make sure you have asyncmap set to something so that control189  characters are not escaped.190 191 192  I tried to fix up a PPP script/system for redialing lost PPP193  connections for use with the eql driver the weekend of Feb 25-26 '95194  (Hereafter known as the 8-hour PPP Hate Festival).  Perhaps later this195  year.196 197 1984. About the Slave Scheduler Algorithm199======================================200 201  The slave scheduler probably could be replaced with a dozen other202  things and push traffic much faster.	The formula in the current set203  up of the driver was tuned to handle slaves with wildly different204  bits-per-second "priorities".205 206 207  All testing I have done was with two 28.8 V.FC modems, one connecting208  at 28800 bps or slower, and the other connecting at 14400 bps all the209  time.210 211 212  One version of the scheduler was able to push 5.3 K/s through the213  28800 and 14400 connections, but when the priorities on the links were214  very wide apart (57600 vs. 14400) the "faster" modem received all215  traffic and the "slower" modem starved.216 217 2185. Testers' Reports219===================220 221  Some people have experimented with the eql device with newer222  kernels (than 1.1.75).  I have since updated the driver to patch223  cleanly in newer kernels because of the removal of the old "slave-224  balancing" driver config option.225 226 227  -  icee from LinuxNET patched 1.1.86 without any rejects and was able228     to boot the kernel and enslave a couple of ISDN PPP links.229 2305.1. Randolph Bentson's Test Report231-----------------------------------232 233  ::234 235    From bentson@grieg.seaslug.org Wed Feb  8 19:08:09 1995236    Date: Tue, 7 Feb 95 22:57 PST237    From: Randolph Bentson <bentson@grieg.seaslug.org>238    To: guru@ncm.com239    Subject: EQL driver tests240 241 242    I have been checking out your eql driver.  (Nice work, that!)243    Although you may already done this performance testing, here244    are some data I've discovered.245 246    Randolph Bentson247    bentson@grieg.seaslug.org248 249------------------------------------------------------------------250 251 252  A pseudo-device driver, EQL, written by Simon Janes, can be used253  to bundle multiple SLIP connections into what appears to be a254  single connection.  This allows one to improve dial-up network255  connectivity gradually, without having to buy expensive DSU/CSU256  hardware and services.257 258  I have done some testing of this software, with two goals in259  mind: first, to ensure it actually works as described and260  second, as a method of exercising my device driver.261 262  The following performance measurements were derived from a set263  of SLIP connections run between two Linux systems (1.1.84) using264  a 486DX2/66 with a Cyclom-8Ys and a 486SLC/40 with a Cyclom-16Y.265  (Ports 0,1,2,3 were used.  A later configuration will distribute266  port selection across the different Cirrus chips on the boards.)267  Once a link was established, I timed a binary ftp transfer of268  289284 bytes of data.	If there were no overhead (packet headers,269  inter-character and inter-packet delays, etc.) the transfers270  would take the following times::271 272      bits/sec	seconds273      345600	8.3274      234600	12.3275      172800	16.7276      153600	18.8277      76800	37.6278      57600	50.2279      38400	75.3280      28800	100.4281      19200	150.6282      9600	301.3283 284  A single line running at the lower speeds and with large packets285  comes to within 2% of this.  Performance is limited for the higher286  speeds (as predicted by the Cirrus databook) to an aggregate of287  about 160 kbits/sec.	The next round of testing will distribute288  the load across two or more Cirrus chips.289 290  The good news is that one gets nearly the full advantage of the291  second, third, and fourth line's bandwidth.  (The bad news is292  that the connection establishment seemed fragile for the higher293  speeds.  Once established, the connection seemed robust enough.)294 295  ======  ========	===  ========   ======= ======= ===296  #lines  speed		mtu  seconds	theory  actual  %of297	  kbit/sec	     duration	speed	speed	max298  ======  ========	===  ========   ======= ======= ===299  3	  115200	900	_	345600300  3	  115200	400	18.1	345600  159825  46301  2	  115200	900	_	230400302  2	  115200	600	18.1	230400  159825  69303  2	  115200	400	19.3	230400  149888  65304  4	  57600		900	_	234600305  4	  57600		600	_	234600306  4	  57600		400	_	234600307  3	  57600		600	20.9	172800  138413  80308  3	  57600		900	21.2	172800  136455  78309  3	  115200	600	21.7	345600  133311  38310  3	  57600		400	22.5	172800  128571  74311  4	  38400		900	25.2	153600  114795  74312  4	  38400		600	26.4	153600  109577  71313  4	  38400		400	27.3	153600  105965  68314  2	  57600		900	29.1	115200  99410.3 86315  1	  115200	900	30.7	115200  94229.3 81316  2	  57600		600	30.2	115200  95789.4 83317  3	  38400		900	30.3	115200  95473.3 82318  3	  38400		600	31.2	115200  92719.2 80319  1	  115200	600	31.3	115200  92423	80320  2	  57600		400	32.3	115200  89561.6 77321  1	  115200	400	32.8	115200  88196.3 76322  3	  38400		400	33.5	115200  86353.4 74323  2	  38400		900	43.7	76800	66197.7 86324  2	  38400		600	44	76800	65746.4 85325  2	  38400		400	47.2	76800	61289	79326  4	  19200		900	50.8	76800	56945.7 74327  4	  19200		400	53.2	76800	54376.7 70328  4	  19200		600	53.7	76800	53870.4 70329  1	  57600		900	54.6	57600	52982.4 91330  1	  57600		600	56.2	57600	51474	89331  3	  19200		900	60.5	57600	47815.5 83332  1	  57600		400	60.2	57600	48053.8 83333  3	  19200		600	62	57600	46658.7 81334  3	  19200		400	64.7	57600	44711.6 77335  1	  38400		900	79.4	38400	36433.8 94336  1	  38400		600	82.4	38400	35107.3 91337  2	  19200		900	84.4	38400	34275.4 89338  1	  38400		400	86.8	38400	33327.6 86339  2	  19200		600	87.6	38400	33023.3 85340  2	  19200		400	91.2	38400	31719.7 82341  4	  9600		900	94.7	38400	30547.4 79342  4	  9600		400	106	38400	27290.9 71343  4	  9600		600	110	38400	26298.5 68344  3	  9600		900	118	28800	24515.6 85345  3	  9600		600	120	28800	24107	83346  3	  9600		400	131	28800	22082.7 76347  1	  19200		900	155	19200	18663.5 97348  1	  19200		600	161	19200	17968	93349  1	  19200		400	170	19200	17016.7 88350  2	  9600		600	176	19200	16436.6 85351  2	  9600		900	180	19200	16071.3 83352  2	  9600		400	181	19200	15982.5 83353  1	  9600		900	305	9600	9484.72 98354  1	  9600		600	314	9600	9212.87 95355  1	  9600		400	332	9600	8713.37 90356  ======  ========	===  ========   ======= ======= ===357 3585.2. Anthony Healy's Report359---------------------------360 361  ::362 363    Date: Mon, 13 Feb 1995 16:17:29 +1100 (EST)364    From: Antony Healey <ahealey@st.nepean.uws.edu.au>365    To: Simon Janes <guru@ncm.com>366    Subject: Re: Load Balancing367 368    Hi Simon,369	  I've installed your patch and it works great. I have trialed370	  it over twin SL/IP lines, just over null modems, but I was371	  able to data at over 48Kb/s [ISDN link -Simon]. I managed a372	  transfer of up to 7.5 Kbyte/s on one go, but averaged around373	  6.4 Kbyte/s, which I think is pretty cool.  :)374