: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)
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
:>- 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
:>- 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
: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
: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
: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
: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
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"
* modem<->host communications rate
* TCP receive window size
* TCP transmit window size
(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
(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
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
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 McCormick * lu...@a2i.rahul.net * Free
read more »