How do you tune SLIP parameters for minimum latency?

How do you tune SLIP parameters for minimum latency?

Post by Luke McCormic » Wed, 10 Aug 1994 17:13:14



Help!  I have a Linux box connected full time to the Internet, which I
run WWW, ftp, and gopher servers off of.  It works great, except that
it is excruciatingly slow!  The throughput is about what I would
expect, but I experience all sorts of lags - what I believe is called
"latency", though I'm not completely sure.  The problem is delayed
response when I (or my users) telnet in - I type a letter, and it
takes a while to echo back.  This is annoying when it's a half second;
it's unbearable when it's 10 seconds or more, which it seems to be
sometimes.  There are also LONG delays - 10, 20 secs, between the
"connect" message when I telnet in and the appearance of a login prompt.

So I officially appeal to the net for help achieving better serial IP
performance!  I have RTFMs I could find, I'm not much better off.  I have
some ideas, but I have low confidence that I'll be able to figure this out
alone.  I'll summarize any useful information I get, post it here, and
send it to the maintainers of the Net and Serial howtos.

My Setup:

486SX/25 ISA, "noname" motherboard
8 MB RAM / 1.08G Quatum SCSI harddisk / Adaptec 1542B
Slackware 1.1.1
Kernel: /proc/version says "Linux version 1.0.8"
USR Robotics Sportster 14.4
Serial card w/16550s
2 serial cables joined together to get right male/female thing :-(
MTU=256   <- for no really good reason.
SLIP connection to "The Little Garden"

I'm planning on getting a 28K modem soon, although the latency is a MUCH
bigger problem than the throughput for now.

I'm willing to change anything.  Here are some of the things I'm thinking
of changing, I appeal to the net for advice as to which ones matter!

- New modem (hayes?  Intel?)
- 28K connection
- "Lock" the serial port  (I don't yet know how to do this)
- change the MTU
- turn off v42, v42bis, etc (not sure how)
- other modem init strings
- switch to PPP or CSLIP
- change the kernel version
- faster processor
- more RAM

Ok, ready?  I'm going to toss out a BUNCH of questions that have had
me mystified for months.  Any of them that you can take a stab at
answering would be greatly appreciated.  If I get some good responses,
I'll summarize to the net, resulting in a "mini-FAQ" about SLIP
performance.

Questions:

Should I "lock" serial line?  How do I do this?  At what speed?

What speed should I communicate with my modem at?

Should I turn off modem-based compression, error-checking?  How?

What modem init string should I use for a USR Sportster?

Is there a way to ensure the line won't drop, and reestablish it when
it does?

What kind of speeds can I expect?

My main criteria is response.  How do I cut "latency"

Why does it take so long to get a login prompt?  Why does it take so
long to say "password"

Is there a difference in kernel versions?  What should I use?

What 14K modem would you recommend.  What would you NOT recommend?
What 28K modems?

What MTU should I use?  What's the difference?

How can I tell if/who someone is ftp/gopher/www'd into my system?  Is
there a way to tell what kind of performance *they're* getting?

Thank you all for any help you can supply!

luke

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

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

 
 
 

How do you tune SLIP parameters for minimum latency?

Post by Matthew Dill » Thu, 11 Aug 1994 01:18:58


:In article <Cu9DI4....@rahul.net> Luke McCormick <lu...@rahul.net> writes:
:>Help!  I have a Linux box connected full time to the Internet, which I
:>run WWW, ftp, and gopher servers off of.  It works great, except that
:>it is excruciatingly slow!  The throughput is about what I would
:>expect, but I experience all sorts of lags - what I believe is called
:>"latency", though I'm not completely sure.  The problem is delayed
:>...
:>
:>- New modem (hayes?  Intel?)

    The modem must be able to:

    * lock the host port baud rate
    * be able to talk to the host at atleast 38400

:>- 28K connection
:>- "Lock" the serial port  (I don't yet know how to do this)
:>- change the MTU

    The MTU should generally be 296 or 576, but note that the MTU alone
    will not fix latency problems.  You do not want too large an MTU.

:>- turn off v42, v42bis, etc (not sure how)

    No, leave it on.  You want both a reliable connection AND compression.
    Compression really makes a difference, especially with sendmail and
    uploading/downloading of uncompressed files or text.  And latency
    is more a function of the host<->modem rate, the modem connection rate,
    and using CSLIP instead of SLIP.  Look here, these are TCP
    character response times with compression on and off with my ZyXEL:

        (Zyxel<->Zyxel, 16.8 connect rate, 57600 host port rate)

             COMPRESSION
        with            without

        131 mS          118 mS
        131 mS          110 mS
        127 mS          120 mS
        125 mS          121 mS
        123 mS          118 mS
        120 mS          116 mS
        130 mS          120 mS
        121 mS          111 mS
        134 mS          113 mS
        121 mS          120 mS
        121 mS          119 mS
        ---             ---

        125 mS average  116 mS average <----

        10 mS difference, or 1/100 second.

    You want a reiable connection because of the way TCP packet retries
    work.  TCP backs off exponentially, so if it sends a packet and doesn't
    get an ack it will progressively wait longer and longer before sending
    the retries.  One packet error out of 25 is *very* noticable, and
    unreliable high speed connections almost universally get packet errors.

    Also, your computer is less likely to crash if there is no garbage in
    the packets.

:>- other modem init strings
:>- switch to PPP or CSLIP

    Use CSLIP.  SLIP has about 11% overhead per packet.  CSLIP as around
    1% overhead per packet (for TCP connections).  It makes a difference.

    Sorry, I don't have the numbers for SLIP verses CSLIP, but it DOES
    make a huge difference for interactive traffic.

:>- change the kernel version

    Maybe.

:>- faster processor

    This is not critical to SLIP latency but isn't a bad idea either.
    It depends on how many users you wish to support.

:>- more RAM

    RAM has nothing to do with latency unless you are swapping all the
    time.

:>
:Ok, ready?  I'm going to toss out a BUNCH of questions that have had
:me mystified for months.  Any of them that you can take a stab at
:answering would be greatly appreciated.  If I get some good responses,
:I'll summarize to the net, resulting in a "mini-FAQ" about SLIP
:performance.
:
:Questions:
:
:Should I "lock" serial line?  How do I do this?  At what speed?

    Yes.  Read the manual for the modem, there will be an option to
    lock the host port baud rate (make it independant of the connection
    rate).

:What speed should I communicate with my modem at?
:

    You should lock the rate at the highest speed the computer and modem
    supports.  If you have 16450 based serial ports this is relatively
    slow (19200 bps).  If you have 16550 serial ports this is usually
    38400, 57600, or 76800.

    The faster you can talk to your modem, the lower echo latency will
    be (regardless of what the modem is able to connect at).  The reason
    is that V.42 packetizes data, so modem-to-modem latency is compounded.
    If you can talk to your modem faster, then the modem is able to dump
    data from packets to you with lower latency, and vise-versa.

    NOTE: V.42's LAP/M is much better then MNP in terms of latency
    issues.

:Should I turn off modem-based compression, error-checking?  How?
:

    No, leave error checking and modem-based compression on.  People
    complain about latency due to compression, but it really gives
    you a LOT more throughput, because packet header information is
    compressed even if data cannot be.

:What modem init string should I use for a USR Sportster?
:
:Is there a way to ensure the line won't drop, and reestablish it when
:it does?
:

    Yes, pop dslip201.tgz from ftp.west.oic.com in /pub/linux/dillon_src

:What kind of speeds can I expect?
:

    It depends on the files being transfered and the connection speed
    of the modem.

:My main criteria is response.  How do I cut "latency"
:

    Four things:

    * modem<->host communications rate
    * TCP receive window size
    * TCP transmit window size
    * MTU

    (1) modem<->host comm rate.  Reduces latency by allowing the modem to
        burst data to and from the host.  This occurs because the modem<->modem
        communication itself is packetized.  Note:  You CANNOT reliably go
        faster then 19200 bps if you only have 16450 serial chips in your
        computer.

    (2) TCP receive window size.  This defaults to 8192 bytes which is usually
        way too high for a TCP connection.  It's fine if you are doing one
        transfer at a time, but if you are doing multiple transfers or trying
        to type while an FTP download is in progress, latency goes way up
        because the remote hosts are attempting to keep 8K ahead of you.
        8K is around 4 seconds worth of data that may be in the pipeline.

        You want to set your TCP receive window to around 2048 bytes.  Newer
        test kernels allow you to specify the receive window size in the
        routing table.  Older kernels require you to modify the kernel source
        to limit the window size.

    (3) TCP transmit window size.  The default is 32768 bytes which is
        even worse then the default receive window size.  Don't get me
        wrong, 32768 is fine for an ethernet, but for SLIP it will cause
        your host to queue up to 32K (16 seconds) worth of packets into
        the pipeline to your modem.  Generally you want the transmit
        window size to be 2048 bytes or 4096 bytes.  You have to modify
        the kernel source and recompile to do this.

    (4) MTU.  The MTU should not be so large that the TCP window size will
        fit into a single packet.  If this occurs, TCP will be unable to
        'stream'... have multiple packets in the pipeline.  For window
        sizes between 2 and 4K I suggest an MTU of 576 bytes.

        Note that the MTU has *NO* effect on an interactive connection since
        the packets sent and received for your typing are always small.
        However, the MTU has a *major* effect on an interactive connection
        when other things are going on at the same time, like an FTP upload
        or download.

    Also note that having too large a TCP window is a disaster when it
    comes to simultanious uploads, downloads, or a combination, because
    ACK latency becomes highly random and one or both hosts may start
    dropping packets due to the packet backlog.  For example, if you have
    a TCP receive window of 8192 bytes and are doing two simultanious
    downloads and two uploads, and your MTU is 576, the remote hosts
    may have up to 16384 bytes (32 packets) queued to you.  Your uploads
    will suffer greatly because they will transmit a packet and it will
    take 8+/-random() seconds for the ACK to come back.  You may think:
    "great, just increase the transmit window size".  That works, sorta,
    except then you get a packet backlog if you have simultanious uploads
    (or other things) going on, not to mention interactive sessions.

:Why does it take so long to get a login prompt?  Why does it take so
:long to say "password"
:

    If you are using 16450 serial chips and talking faster then 19200,
    your computer is probably dropping packets, requiring resends, which
    is slow.

    There are a number of other possibilities, including a misconfigured
    DNS system (domain name service).  How long does it take the machine
    to resolve a host name?

:Is there a difference in kernel versions?  What should I use?
:
:What 14K modem would you recommend.  What would you NOT recommend?
:What 28K modems?

    Don't know about 28K modems, but I would recommend ZyXEL U-1496E
    for 14.4 (it does 16.8 between two ZyXELs).  I have had very good
    results from the ZyXEL compared to Supra.  Intel, Telebit, and
    USRobotics modems are also good brands.  However, avoid *ANY* hybrid
    modem such as modems that go over the parallel port instead of
    serial port, or modems that require device drivers to do V.42, or
    stupid things like that.  Avoid Supra, or any modem that uses the
    Rockwell V.32bis chipset.

:What MTU should I use?  What's the difference?
:

    I suggest an MTU of 576.  Basically if you use too large an MTU
    packet latency gets worse and interactive response goes to hell.
    See above.  If the MTU is too small, then uploads and downloads
    suffer greatly.  MTU is unrelated to interactive sessions since
    typing normally produces small packets.

:How can I tell if/who someone is ftp/gopher/www'd into my system?  Is
:there a way to tell what kind of performance *they're* getting?
:

    netstat -t          Print machine names (Assuming you are running
                        named and/or going to an external DNS resolver).

    netstat -tn         print IP numbers instead of machine names

    For a performance standpoint, run your FTPD with options to turn
    on logging and look at the logs.  I dunno about gopher/www, but
    I assume they have options to.

:Thank you all for any help you can supply!
:
:luke
:
:--
:----------------------------------------------------------------------
:Luke McCormick    *    lu...@a2i.rahul.net    *    Free
...

read more »

 
 
 

How do you tune SLIP parameters for minimum latency?

Post by Bart Kin » Fri, 12 Aug 1994 15:42:58




>Subject: How do you tune SLIP parameters for minimum latency?
>Date: Tue, 9 Aug 1994 08:13:14 GMT
>Help!  I have a Linux box connected full time to the Internet, which I
>run WWW, ftp, and gopher servers off of.  It works great, except that
>it is excruciatingly slow!  The throughput is about what I would
>expect, but I experience all sorts of lags - what I believe is called
>"latency", though I'm not completely sure.  The problem is delayed
>response when I (or my users) telnet in - I type a letter, and it
>takes a while to echo back.  This is annoying when it's a half second;
>it's unbearable when it's 10 seconds or more, which it seems to be
>sometimes.  There are also LONG delays - 10, 20 secs, between the
>"connect" message when I telnet in and the appearance of a login prompt.
>So I officially appeal to the net for help achieving better serial IP
>performance!  I have RTFMs I could find, I'm not much better off.  I have
>some ideas, but I have low confidence that I'll be able to figure this out
>alone.  I'll summarize any useful information I get, post it here, and
>send it to the maintainers of the Net and Serial howtos.
>My Setup:
>486SX/25 ISA, "noname" motherboard
>8 MB RAM / 1.08G Quatum SCSI harddisk / Adaptec 1542B
>Slackware 1.1.1
>Kernel: /proc/version says "Linux version 1.0.8"
>USR Robotics Sportster 14.4
>Serial card w/16550s
>2 serial cables joined together to get right male/female thing :-(
>MTU=256   <- for no really good reason.
>SLIP connection to "The Little Garden"
>I'm planning on getting a 28K modem soon, although the latency is a MUCH
>bigger problem than the throughput for now.
>I'm willing to change anything.  Here are some of the things I'm thinking
>of changing, I appeal to the net for advice as to which ones matter!
>- New modem (hayes?  Intel?)
>- 28K connection
>- "Lock" the serial port  (I don't yet know how to do this)
>- change the MTU
>- turn off v42, v42bis, etc (not sure how)
>- other modem init strings
>- switch to PPP or CSLIP
>- change the kernel version
>- faster processor
>- more RAM
>Ok, ready?  I'm going to toss out a BUNCH of questions that have had
>me mystified for months.  Any of them that you can take a stab at
>answering would be greatly appreciated.  If I get some good responses,
>I'll summarize to the net, resulting in a "mini-FAQ" about SLIP
>performance.
>Questions:
>Should I "lock" serial line?  How do I do this?  At what speed?

Yes!  at 38400 for a 14.400 bps modem with compression.

Quote:>What speed should I communicate with my modem at?

See above. You will run 14.000 bps on the phone line side, and 38400 on the
computer side. Needed because of  un-compression in the modem!

Quote:>Should I turn off modem-based compression, error-checking?  How?

No. Compression really helps a lot. Error protection is the main cause of slow
response times (!) but if you switch it off, and your line is not 100%
perfect, your *throughput* will drop back to nothing. I know, I tried all this!

Quote:>What modem init string should I use for a USR Sportster?

Look in the manual...

Quote:>Is there a way to ensure the line won't drop, and reestablish it when

What kind of SLIP program do you use? Slattach? DIP? Look in the MAN pages.

Quote:>What kind of speeds can I expect?

about 50 % of the same modems running a Zmodem connection... Don't know why.

Quote:>My main criteria is response.  How do I cut "latency"

Only be swiching off the error protection. This will cut the 'response time'
about in halve. (on a empty line!) You can excpect a PING to come back at
about 100 ms without error protection, and about 200 ms with error protection.
But if your line is not absolutely PERFECT, you will loose all your througput
speed!

Quote:>Why does it take so long to get a login prompt?  Why does it take so
>long to say "password"

Get a T1 line at a few $1000's a month!

Quote:>Is there a difference in kernel versions?  What should I use?

Nah.

Quote:>What 14K modem would you recommend.  What would you NOT recommend?

err..

Quote:>What 28K modems?

They are twice as fast as 14K modems..! (:-))

Quote:>What MTU should I use?  What's the difference?

This is important. You should ask your provider what THEY use: It should be
'compatible'.

Quote:>How can I tell if/who someone is ftp/gopher/www'd into my system?  Is
>there a way to tell what kind of performance *they're* getting?

type: Netstat
These are also special tools around, don't know where.

Quote:>Thank you all for any help you can supply!
>luke

good luck!

Bart
-------------------------------------------------
Bart Kindt (ZL4FOX/PA2FOX), Dunedin, New Zealand.
-------------------------------------------------

 
 
 

How do you tune SLIP parameters for minimum latency?

Post by Matthew Aaron Armstro » Fri, 12 Aug 1994 03:33:07



: :>Help!  I have a Linux box connected full time to the Internet, which I
: :>run WWW, ftp, and gopher servers off of.  It works great, except that
: :>it is excruciatingly slow!  The throughput is about what I would
: :>expect, but I experience all sorts of lags - what I believe is called
: :>"latency", though I'm not completely sure.  The problem is delayed

: (2) TCP receive window size.  This defaults to 8192 bytes which is usually
:     way too high for a TCP connection.  It's fine if you are doing one
:     transfer at a time, but if you are doing multiple transfers or trying
:     to type while an FTP download is in progress, latency goes way up
:     because the remote hosts are attempting to keep 8K ahead of you.
:     8K is around 4 seconds worth of data that may be in the pipeline.

:     You want to set your TCP receive window to around 2048 bytes.  Newer
:     test kernels allow you to specify the receive window size in the
:     routing table.  Older kernels require you to modify the kernel source
:     to limit the window size.                    ^^^^^^^^^^^^^^^^^

: (3) TCP transmit window size.  The default is 32768 bytes which is
:     even worse then the default receive window size.  Don't get me
:     wrong, 32768 is fine for an ethernet, but for SLIP it will cause
:     your host to queue up to 32K (16 seconds) worth of packets into
:     the pipeline to your modem.  Generally you want the transmit
:     window size to be 2048 bytes or 4096 bytes.  You have to modify
:     the kernel source and recompile to do this.              ^^^^^^
      ^^^^^^^^^^^^^^^^^

    I'm no stranger to re-compiling my kernel, but could you give some
pointers on where to find the TCP receive and transmit window sizes in
the code?  I found no obvious #defines, or other clues.  Am I looking
for #defines?  In what header/source file?  I'd love to try the
changes you suggest, but am confused by the source.

   Thanks, Matt

 
 
 

How do you tune SLIP parameters for minimum latency?

Post by Mr Robert J Log » Sat, 13 Aug 1994 03:42:03


<lots about modems, TCP et al - see the post its useful>

Boy, that was one of the most helpful bits of help
Ive read in a while(!). Thanks Matthew - this would
be a useful contribution for the NET-2-HOWTO.

bert (working on a poor SLIP line)

--
-------------------------------------------
 Linux - you cant buy more powerful relief
-------------------------------------------

 
 
 

How do you tune SLIP parameters for minimum latency?

Post by Dennis Duffn » Mon, 15 Aug 1994 03:23:29





: : :>Help!  I have a Linux box connected full time to the Internet, which I
: : :>run WWW, ftp, and gopher servers off of.  It works great, except that
: : :>it is excruciatingly slow!  The throughput is about what I would
: : :>expect, but I experience all sorts of lags - what I believe is called
: : :>"latency", though I'm not completely sure.  The problem is delayed

: : (2) TCP receive window size.  This defaults to 8192 bytes which is usually
: :     way too high for a TCP connection.  It's fine if you are doing one
: :     transfer at a time, but if you are doing multiple transfers or trying
: :     to type while an FTP download is in progress, latency goes way up
: :     because the remote hosts are attempting to keep 8K ahead of you.
: :     8K is around 4 seconds worth of data that may be in the pipeline.

: :     You want to set your TCP receive window to around 2048 bytes.  Newer
: :     test kernels allow you to specify the receive window size in the
: :     routing table.  Older kernels require you to modify the kernel source
: :     to limit the window size.                    ^^^^^^^^^^^^^^^^^

: : (3) TCP transmit window size.  The default is 32768 bytes which is
: :     even worse then the default receive window size.  Don't get me
: :     wrong, 32768 is fine for an ethernet, but for SLIP it will cause
: :     your host to queue up to 32K (16 seconds) worth of packets into
: :     the pipeline to your modem.  Generally you want the transmit
: :     window size to be 2048 bytes or 4096 bytes.  You have to modify
: :     the kernel source and recompile to do this.              ^^^^^^
:       ^^^^^^^^^^^^^^^^^

:     I'm no stranger to re-compiling my kernel, but could you give some
: pointers on where to find the TCP receive and transmit window sizes in
: the code?  I found no obvious #defines, or other clues.  Am I looking
: for #defines?  In what header/source file?  I'd love to try the
: changes you suggest, but am confused by the source.

:    Thanks, Matt

Now, I have a question.  How do you recompile the kernel?  I'm curious, as I
may have to exactly this for a project.

Thanks, Matt, for your input.  I should have known that it was you. ;-)

Duff

 
 
 

1. Tuning PCI latency/max_grant or priority settings on Sun Blade 150 PCI-bus

For a special device (streaming video capture)  in a Sun Blade150, I want to
configure the devices on the PCI in such a way, that this special device
gets the PCI-bus within a certain max-time, when it request the bus. And
when it got the bus, it should keep it for a minimum number of bus-cycles.

As far as I know the PCI-bus,a PCI-device has a registor with a
latency-timer value on board. This tells the board how much bus-cycles it
may keep the bus, after getting it.
There's also another setting, called "max_grant". If PCI-devices or the
PCI-arbiter use the max_grant, is not clear to me. Even when used, its
unclear to me if it could give me a worse-case max-grant time before the
device will get the bus. If it's not used, the only other way, I think, to
give the device, faster the bus, is by decreasing the latency-timers of all
the other devices on the same PCI-bus.
In one of Sun's whitepapers about UPA, I saw that there are 2 methods
possible in which the arbiter on the bus could work: in a round-robin
fashion or based on PCI-slot priority.
Normally the round-robin is used I think and I don't know if it's changable.
PCI-priority could solve maybe else also the problem.

Are there tools available under Solaris ,like setpci under Linux, to change
these values ? I've tried to set the values via the driver.conf files and
via /etc/system for all or specific devices. I can set/cange the values for
the special device, thats not the problem. But I want to set(decrease) on
the sametime the values for latency for the other devices, like IDE etc. But
this didn't seem that anything did change in the behaviour of the devices.

I know, playing with these values, could lead in a corrupted disk, or system
etc. I have to find out what possible is. First I've to findout the tools
and the way how to do it under Solaris2.8/Sparc Sun Blade150.

Johan

2. FreeSCO / Realtek 8139 / Digital Venturis problem

3. max bomb segment tuning with read latency 2 patch in contest

4. gpg, gpa and restoration of keys

5. Kernel tuning for high latency satellite link??

6. READ THE ONLY WEB SITE THAT WANTS TO KILL JEWS AND BLACKS

7. Fiddling with 'm' ( minimum degree of multiprogramming ) Parameter

8. Help: dvips problem

9. Latency with SLIP

10. very bad latency on RedHat 7.1 with GeForce2 AND low-latency patch

11. REPORT: NFS and ReiserFS very high latencies, with low-latency and preempt applied

12. Setting 2.5.1 kernel tuning parameters

13. Dedicating a Machine to SLIP? Minimum requirements?