EQL Driver: Serial IP Load Balancing HOWTO

문서 서문

Simon "Guru Aleph-Null" Janes가 작성한 EQL 장치 드라이버 설명서 v1.1이며 날짜는 1995년 2월 27일입니다.

EQL은 SLIP 또는 압축하지 않은 PPP 직렬 IP 링크 여러 개에 트래픽을 분산해 전체 대역폭을 늘리는 소프트웨어 장치입니다. 기본 지연 시간, 즉 ping 시간 자체를 줄이지는 않지만 링크가 이미 혼잡한 경우에는 부하를 나눠 지연을 완화할 수 있습니다. 이 버전은 Linux 1.1.75에서 시험했고 1.1.86에 깨끗하게 patch되며, 최신 source tree용 v1.1 patch로 1.1.92에서도 시험했습니다.

.. 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. 소개

고가의 56K 전용선 대신 전화선 여러 개를 쓸 수 있고 ISP가 허용한다면, 양쪽에 전용 하드웨어를 두지 않고 modem 여러 대를 하나의 point-to-point 링크처럼 묶어 대역폭을 늘릴 수 있습니다.

작성 당시 eql 드라이버는 Livingston PortMaster-2e terminal server하고만 시험했습니다. 다른 terminal server의 load balancing 지원 여부는 알 수 없지만 PortMaster는 동작했습니다. 다만 28.8Kbps와 14.4Kbps 링크를 묶은 시험에서 Linux 시험 장비보다 약 1~2KB/s 느렸으며 원인이 PortMaster인지 Linux TCP인지 확정하지 못했습니다.

작성자는 ISP가 load-balancing 고객에게 두 번째 회선 비용의 75%, 세 번째 회선 비용의 50%처럼 점차 낮은 추가 요금을 받는 방안을 제안하면서, 이는 희망 사항이라고 덧붙입니다.

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. 커널 구성 개요

이 절은 eql 드라이버를 사용하도록 kernel patch를 적용하고 build한 뒤 설치하는 일반 절차를 설명합니다. 내용은 1995년 당시 커널 개발 방식에 맞춰져 있습니다.

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 커널 패치

eql 드라이버가 이미 포함된 커널을 구할 수 없다면 `ftp://slaughter.ncm.com/pub/Linux/LOAD_BALANCING/eql-1.1.tar.gz`에서 드라이버를 받아 `/usr/local/src/` 같은 위치에 풉니다. archive에는 보증 고지, `eql-1.1.patch`, 실행 파일 `eql_enslave`, source `eql_enslave.c`가 들어 있습니다.

1.1.92 이후의 당시 최신 커널을 `/usr/src/linux-1.1.92.eql` 같은 개발 디렉터리에 풀고 `/usr/src/linux` symbolic link를 그곳으로 연결합니다. 이후 `/usr/src`에서 다음 명령으로 patch를 적용합니다.

cd /usr/src
patch </usr/local/src/eql-1.1/eql-1.1.patch

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

2.2 커널 빌드

patch를 적용한 뒤 `make config`를 실행해 하드웨어에 맞게 커널을 구성하고, 평소 사용하던 방식으로 build하고 설치합니다.

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

  After patching the kernel, run make config and configure the kernel
  for your hardware.


  After configuration, make and install according to your habit.

3. 네트워크 구성 개요

작성자는 Matt Dillon의 DSLIP SLIP 연결 관리자로만 eql을 사용했습니다. 다른 연결 관리자를 eql과 함께 구성하는 방법은 각 도구에 맞춰야 하며, 당시 대부분의 관리자는 둘 이상의 연결을 안정적으로 처리하지 못했다고 평가합니다.

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

3.1 /etc/rc.d/rc.inet1

`rc.inet1`에서 eql 장치에 시스템이 평소 쓰는 IP 주소와 SLIP 회선용 MTU를 설정합니다. 두 modem이면 평소 MTU의 약 절반, 세 대면 3분의 1, 네 대면 4분의 1을 고려할 수 있지만 296보다 지나치게 낮추는 것은 실익이 적습니다.

ifconfig eql 198.67.33.239 mtu 1006
route add default eql

eql 장치를 올린 뒤 정적 default route가 eql을 가리키게 추가합니다.

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

  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?--)

3.2 장치를 수동으로 결합

장치를 수동으로 묶으려면 `eql_enslave`와 `eql_emancipate`를 사용합니다. 당시 `eql_emancipate`는 slave 장치가 내려가면 eql이 자동으로 queue에서 제거했기 때문에 아직 작성되지 않았다고 설명합니다.

결합 문법은 `eql_enslave <master-name> <slave-name> <estimated-bps>`입니다. 아래 예는 `sl0`, `ppp0`, `sl1`을 각각 추정 속도 28,800, 14,400, 57,600bps로 eql에 추가합니다.

eql_enslave eql sl0 28800
eql_enslave eql ppp0 14400
eql_enslave eql sl1 57600

장치를 분리하려면 `ifconfig`로 내리면 eql이 죽은 장치를 자동 제거하거나, 구현되어 있다면 `eql_emancipate eql <device>`를 사용할 수 있습니다.

eql_emancipate eql sl0
eql_emancipate eql ppp0
eql_emancipate eql sl1

  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

3.3 DSLIP 구성

목표는 필요한 수만큼 SLIP 연결을 자동으로 올리고 유지하는 것입니다. `/etc/slip/runslip.conf` 예제는 `sl-line-1`과 `sl-line-2`를 활성화하고 각각 baud 38400, MTU 576으로 설정합니다. `ducmd`는 `/dev/cua2`와 `/dev/cua3`용 28.8K dialout script를 호출하고 연결 뒤 `eql_enslave eql $interface 28800`을 실행합니다. 두 회선 모두 주소 `198.67.33.239`를 사용합니다.

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

          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.

3.4 PPP와 eql

작성자는 DSLIP처럼 PPP 연결을 관리할 도구가 없어 PPP 장치의 load balancing을 아직 시험하지 않았습니다. LinuxNET의 Billy가 전한 성능 조언은 control character가 escape되지 않도록 `asyncmap`을 적절한 값으로 설정하라는 것입니다.

1995년 2월 25~26일 주말에 끊어진 PPP 연결을 다시 거는 script/system을 만들려 했지만 8시간 동안 성과를 내지 못했고, 나중에 다시 시도하겠다고 기록했습니다.

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.

4. Slave 스케줄러 알고리즘

현재 slave scheduler는 다른 알고리즘으로 교체하면 더 빠를 여지가 있지만, 속도 우선순위가 크게 다른 여러 slave를 처리하도록 식을 조정했습니다. 시험은 28.8 V.FC modem 두 대를 사용했으며 하나는 최대 28,800bps, 다른 하나는 항상 14,400bps로 연결했습니다.

어떤 scheduler 버전은 28,800+14,400 연결에서 5.3KB/s를 냈지만, 우선순위 차이가 57,600 대 14,400처럼 크면 빠른 modem이 모든 트래픽을 받고 느린 modem이 굶는 문제가 있었습니다.

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

5. 시험자 보고 개요

일부 사용자는 1.1.75보다 새 커널에서 eql을 시험했습니다. 옛 `slave-balancing` driver 구성 선택지가 제거된 뒤 작성자는 새 커널에 깨끗하게 적용되도록 patch를 갱신했습니다. LinuxNET의 icee는 1.1.86에 reject 없이 patch하고 ISDN PPP 링크 두 개를 eql에 결합해 boot에 성공했습니다.

    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

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

5.1 Randolph Bentson 시험 보고

Randolph Bentson은 eql이 설명대로 동작하는지 확인하고 자신의 직렬 장치 드라이버를 부하 시험하기 위해 성능을 측정했습니다. EQL은 여러 SLIP 연결을 하나처럼 묶어 비싼 DSU/CSU 하드웨어와 서비스 없이 dial-up 연결 성능을 단계적으로 높일 수 있었습니다.

두 Linux 1.1.84 시스템 사이에서 486DX2/66 + Cyclom-8Ys와 486SLC/40 + Cyclom-16Y를 사용했고 포트 0~3에 SLIP 연결을 만들었습니다. 링크가 수립된 뒤 289,284바이트 binary FTP 전송 시간을 측정했습니다. overhead가 전혀 없다면 345,600bps에서 8.3초, 234,600bps에서 12.3초, 172,800bps에서 16.7초, 153,600bps에서 18.8초, 76,800bps에서 37.6초, 57,600bps에서 50.2초, 38,400bps에서 75.3초, 28,800bps에서 100.4초, 19,200bps에서 150.6초, 9,600bps에서 301.3초가 이론값입니다.

낮은 속도에서 큰 packet을 쓰는 단일 회선은 이론값의 2% 이내에 도달했습니다. 높은 속도에서는 Cirrus 칩 자료가 예측한 대로 합계 약 160Kbps가 상한이었으며, 다음 시험에서는 여러 Cirrus 칩에 포트를 나눌 계획이었습니다.

좋은 결과는 두 번째, 세 번째, 네 번째 회선의 대역폭을 거의 온전히 얻었다는 점입니다. 높은 속도에서는 연결 수립이 불안정했지만 일단 연결된 뒤에는 충분히 안정적이었습니다. 상세 표는 회선 수, 각 회선 속도, MTU, 전송 시간, 이론 속도, 실제 속도와 이론 대비 비율을 모두 보존합니다. 관측 범위는 빠른 조합의 약 38~86%부터 저속 단일 회선의 98%까지이며, 구성과 MTU에 따라 차이가 큽니다.

  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
---------------------------

  ::

5.2 Anthony Healy 보고

Antony Healey는 null modem으로 연결한 두 SL/IP 회선에서 patch가 잘 동작했다고 보고했습니다. ISDN 링크로 표시된 시험에서 한 번은 최대 7.5KB/s, 평균 약 6.4KB/s의 전송률을 얻었습니다.

    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.  :)