2.1. Patching The Kernel¶

If you do not have or cannot get a copy of the kernel with the eqldriver folded into it, get your copy of the driver fromftp://slaughter.ncm.com/pub/Linux/LOAD_BALANCING/eql-1.1.tar.gz.Unpack this archive someplace obvious like /usr/local/src/. It willcreate 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 convenientlike 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/srcpatch </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 kernelfor your hardware.

After configuration, make and install according to your habit.

3.1. /etc/rc.d/rc.inet1¶

In rc.inet1, ifconfig the eql device to the IP address you usually usefor your machine, and the MTU you prefer for your SLIP lines. Onecould argue that MTU should be roughly half the usual size for twomodems, one-third for three, one-fourth for four, etc... But goingtoo far below 296 is probably overkill. Here is an example ifconfigcommand 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 toit in the routing table using the cool new route syntax that makeslife so much easier:

route add default eql

3.2. Enslaving Devices By Hand¶

Enslaving devices by hand requires two utility programs: eql_enslaveand eql_emancipate (-- eql_emancipate hasn’t been written because whenan enslaved device “dies”, it is automatically taken out of the queue.I haven’t found a good reason to write it yet... other than forcompleteness, 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 28800eql_enslave eql ppp0 14400eql_enslave eql sl1 57600

When you want to free a device from its life of slavery, you caneither down the device with ifconfig (eql will automatically bury thedead slave and remove it from its queue) or use eql_emancipate to freeit. (-- Or just ifconfig it down, and the eql driver will take it outfor you.--):

eql_emancipate eql sl0eql_emancipate eql ppp0eql_emancipate eql sl1

3.3. DSLIP Configuration for the eql Device¶

The general idea is to bring up and keep up as many SLIP connectionsas you need, automatically.

3.4. Using PPP and the eql Device¶

I have not yet done any load-balancing testing for PPP devices, mainlybecause I don’t have a PPP-connection manager like SLIP has withDSLIP. I did find a good tip from LinuxNET:Billy for PPP performance:make sure you have asyncmap set to something so that controlcharacters are not escaped.

I tried to fix up a PPP script/system for redialing lost PPPconnections for use with the eql driver the weekend of Feb 25-26 ‘95(Hereafter known as the 8-hour PPP Hate Festival). Perhaps later thisyear.

5.1. Randolph Bentson’s Test Report¶

From bentson@grieg.seaslug.org Wed Feb  8 19:08:09 1995Date: Tue, 7 Feb 95 22:57 PSTFrom: Randolph Bentson <bentson@grieg.seaslug.org>To: guru@ncm.comSubject: EQL driver testsI have been checking out your eql driver.  (Nice work, that!)Although you may already done this performance testing, hereare some data I've discovered.Randolph Bentsonbentson@grieg.seaslug.org

A pseudo-device driver, EQL, written by Simon Janes, can be usedto bundle multiple SLIP connections into what appears to be asingle connection. This allows one to improve dial-up networkconnectivity gradually, without having to buy expensive DSU/CSUhardware and services.

I have done some testing of this software, with two goals inmind: first, to ensure it actually works as described andsecond, as a method of exercising my device driver.

The following performance measurements were derived from a setof SLIP connections run between two Linux systems (1.1.84) usinga 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 distributeport selection across the different Cirrus chips on the boards.)Once a link was established, I timed a binary ftp transfer of289284 bytes of data. If there were no overhead (packet headers,inter-character and inter-packet delays, etc.) the transferswould take the following times:

bits/sec  seconds345600    8.3234600    12.3172800    16.7153600    18.876800     37.657600     50.238400     75.328800     100.419200     150.69600      301.3

A single line running at the lower speeds and with large packetscomes to within 2% of this. Performance is limited for the higherspeeds (as predicted by the Cirrus databook) to an aggregate ofabout 160 kbits/sec. The next round of testing will distributethe load across two or more Cirrus chips.

The good news is that one gets nearly the full advantage of thesecond, third, and fourth line’s bandwidth. (The bad news isthat the connection establishment seemed fragile for the higherspeeds. Once established, the connection seemed robust enough.)

#lines	speedkbit/sec	mtu	secondsduration	theoryspeed	actualspeed	%ofmax
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 BalancingHi 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.  :)