Dial-up connection multiple connections?

[T. 'Nifty New Hat' Mitchell]

On Mon, Jun 14, 2004 at 09:02:55AM -0400, srb wrote:
> From: "srb" <srb at softhome.net>
> To: "For users of Fedora Core releases" <fedora-list at redhat.com>
> Date: Mon, 14 Jun 2004 09:02:55 -0400
> Subject: Dial-up connection multiple connections?
> Reply-To: For users of Fedora Core releases <fedora-list at redhat.com>
> 
> Hi,
> 
> I'm using Fedora Core 2 with a USR 56k internal PCI hardware modem.
> Everything in Linux works great, however, is there a setting somewhere that
> controls number of connections for PPP? For instance if I am downloading a
> file, I cannot browse to a new website or check my e-mail until the download
> is finished (I get a timeout error if I try). Whereas in M$ windows, you can
> have more than one connection at a time (I think 4 is the max default for
> dial-up modems), allowing you to still do these things (albeit slower :-)).
> Does anyone have any ideas/suggestions, or is this just impossible in
> Linux??
> 

I do not have a low bandwidth situation to test this on so RTFM and be
cautious.  Keep notes so you can remember and if necessary undo
changes.  Here are some thoughts...

In general such net badness is the result of buffer sizes simply
being too large for the bandwidth (not wrong, just mismatched).

So first look and gather some data.
If you do a "netstat -a" you can often see bytes in the outgoing queues:
   Proto Recv-Q Send-Q Local Address
   tcp   0      39802  box100.private.net:ssh    box200.private.net:49014  ESTABLISHED

If you do the bandwidth arithmetic the sum of the size of all the
send-Queue data means that some real amount of time will elapse before the
outgoing data has flushed.  Measure Send-Q and do the arithmetic.

If the arithmetic results in large multiple second latency -- ifconfig
has an option "txqueuelen" that might help tune outgoing transmit
side.  Play with this first.

   txqueuelen length
              Set the length of the transmit queue of the device. It is useful
              to set this to small values  for  slower  devices  with  a  high
              latency  (modem links, ISDN) to prevent fast bulk transfers from
              disturbing interactive traffic like telnet too much.
 
For incoming data that might be filling big buffers at your ISP router
and beyond there are some useful variables exposed in
/proc/sys/net/ipv4 for 2.6. kernels.  Since these queue depths on routers
cannot be seen by you simple arithmetic will not help, snoop packets and guess.

You can however inspect packets to see what window size is being
advertised (look with tethereal, dump or any of the packet sniffers).
Ideally one should not see a window size that represents more than a
couple seconds of data at the connected baud rate (bandwidth).  Big tcp
windows are great for fat pipe connected boxes on the Internet where
latency dominates throughput.  A fat pipe connected to a small modem
pipe might find these to be a mismatch.

I glanced and did not see an easy way to limit the advertised window
size to be smaller.  If I was bold setting tcp_window_scaling to 0
might be tinkered with early on.

Also verify the MTU size, with ppp you might want to set the MTU to
make room for the ppp overhead.  Google for the numbers ...

Recall that this is going to apply to your ppp modem link.

-- 
	T o m  M i t c h e l l 
	/dev/null the ultimate in secure storage.