wierd solution to slow PPP found

wierd solution to slow PPP found

Post by llecle » Fri, 09 Feb 1996 04:00:00



Tonight, I did alot of experimenting to figure out why PPP on a serial
link was so slow. The solution  to fix this problem turns out to
affect modem PPP as well, and may interest alot of you who may wonder
why PPP in windows 95 is faster (and the fix for linux is below).

It turns out that to get the top pppd to work (for modem or serial
link) you must do the following: (there's a big catch...see below)

setserial /dev/cua0 spd_vhi   {or /dev/cua1 ...} this sets 115200 port spd

pppd 38400 ...other usual parms when you run pppd.

****The previous is the wierd part; if you put in any other figure (even
a faster one like 57600, or 115200 in the pppd cmd, things go really slow. 38400 is
the only number which works to make ppp go at the correct high speed
over modems and serial links (tested with multiple ftps, pings..e.tc..etc).

I tried this on two different linux boxes (a 386, and a p-100) with
1.2.8 and 1.2.3 linux, with the same results.

...so now that we all know how to get fast ppp, does anyone know why
pppd exhibits such wierd behavior when figures other than 38400 are
fed to it?

Lou Leclerc

 
 
 

wierd solution to slow PPP found

Post by llecle » Sat, 10 Feb 1996 04:00:00


Actually, I get speeds much higher than 38400 on my serial PPP link
between the two Linus boxes (After I did the fix below), so it seems
that something else is at play. The "slow" speed BTW, on my setups turns out to
be around 20000bps or so.

L.L.

: >Tonight, I did alot of experimenting to figure out why PPP on a serial
: >link was so slow. The solution  to fix this problem turns out to
: >affect modem PPP as well, and may interest alot of you who may wonder
: >why PPP in windows 95 is faster (and the fix for linux is below).
: >
: >It turns out that to get the top pppd to work (for modem or serial
: >link) you must do the following: (there's a big catch...see below)
: >
: >setserial /dev/cua0 spd_vhi   {or /dev/cua1 ...} this sets 115200 port spd
: >
: >pppd 38400 ...other usual parms when you run pppd.
: >
: >****The previous is the wierd part; if you put in any other figure (even
: >a faster one like 57600, or 115200 in the pppd cmd, things go really slow. 38400 is
: >the only number which works to make ppp go at the correct high speed
: >over modems and serial links (tested with multiple ftps, pings..e.tc..etc).
: >
: >I tried this on two different linux boxes (a 386, and a p-100) with
: >1.2.8 and 1.2.3 linux, with the same results.
: >
: >...so now that we all know how to get fast ppp, does anyone know why
: >pppd exhibits such wierd behavior when figures other than 38400 are
: >fed to it?
: >
: >Lou Leclerc

: >

: The same works with DIP, too.  I believe (and I'm sure somebody can
: correct me if I'm wrong), that neither DIP nor pppd can currently handle
: rates > 38400.  Giving a larger number than this as a parameter causes
: them to use their default speed, 9600, or some-such.  Hence the
: slowdown.

: Charlie
: --------------------------------------------------


: #include <std/disclaimer.h>

 
 
 

wierd solution to slow PPP found

Post by Charlie Kempso » Sat, 10 Feb 1996 04:00:00



>Tonight, I did alot of experimenting to figure out why PPP on a serial
>link was so slow. The solution  to fix this problem turns out to
>affect modem PPP as well, and may interest alot of you who may wonder
>why PPP in windows 95 is faster (and the fix for linux is below).

>It turns out that to get the top pppd to work (for modem or serial
>link) you must do the following: (there's a big catch...see below)

>setserial /dev/cua0 spd_vhi   {or /dev/cua1 ...} this sets 115200 port spd

>pppd 38400 ...other usual parms when you run pppd.

>****The previous is the wierd part; if you put in any other figure (even
>a faster one like 57600, or 115200 in the pppd cmd, things go really slow. 38400 is
>the only number which works to make ppp go at the correct high speed
>over modems and serial links (tested with multiple ftps, pings..e.tc..etc).

>I tried this on two different linux boxes (a 386, and a p-100) with
>1.2.8 and 1.2.3 linux, with the same results.

>...so now that we all know how to get fast ppp, does anyone know why
>pppd exhibits such wierd behavior when figures other than 38400 are
>fed to it?

>Lou Leclerc


The same works with DIP, too.  I believe (and I'm sure somebody can
correct me if I'm wrong), that neither DIP nor pppd can currently handle
rates > 38400.  Giving a larger number than this as a parameter causes
them to use their default speed, 9600, or some-such.  Hence the
slowdown.

Charlie
--------------------------------------------------


#include <std/disclaimer.h>

 
 
 

wierd solution to slow PPP found

Post by Erik Kara » Tue, 13 Feb 1996 04:00:00


Quote:>****The previous is the wierd part; if you put in any other figure (even
>a faster one like 57600, or 115200 in the pppd cmd, things go really slow. 38400 is
>the only number which works to make ppp go at the correct high speed
>over modems and serial links (tested with multiple ftps, pings..e.tc..etc).>

I think that the highest speed it knows is 38400
 when you use
setserial spd_hi  it sees the 38400 as 57600   and

when you setserial spd_hi it sees the 38400 as 115200  

Erik

 
 
 

wierd solution to slow PPP found

Post by David Colquho » Wed, 14 Feb 1996 04:00:00



>Actually, I get speeds much higher than 38400 on my serial PPP link
>between the two Linus boxes (After I did the fix below), so it seems
>that something else is at play. The "slow" speed BTW, on my setups turns out to
>be around 20000bps or so.
>L.L.


>: >Tonight, I did alot of experimenting to figure out why PPP on a serial
>: >link was so slow. The solution  to fix this problem turns out to
>: >affect modem PPP as well, and may interest alot of you who may wonder
>: >why PPP in windows 95 is faster (and the fix for linux is below).
>: >
>: >It turns out that to get the top pppd to work (for modem or serial
>: >link) you must do the following: (there's a big catch...see below)
>: >
>: >setserial /dev/cua0 spd_vhi   {or /dev/cua1 ...} this sets 115200 port spd
>: >
>: >pppd 38400 ...other usual parms when you run pppd.
>: >
>: >****The previous is the wierd part; if you put in any other figure (even
>: >a faster one like 57600, or 115200 in the pppd cmd, things go really slow. 38400 is
>: >the only number which works to make ppp go at the correct high speed
>: >over modems and serial links (tested with multiple ftps, pings..e.tc..etc).
>: >
>: >I tried this on two different linux boxes (a 386, and a p-100) with
>: >1.2.8 and 1.2.3 linux, with the same results.
>: >
>: >...so now that we all know how to get fast ppp, does anyone know why
>: >pppd exhibits such wierd behavior when figures other than 38400 are
>: >fed to it?
>: >
>: >Lou Leclerc

>: >
>: The same works with DIP, too.  I believe (and I'm sure somebody can
>: correct me if I'm wrong), that neither DIP nor pppd can currently handle
>: rates > 38400.  Giving a larger number than this as a parameter causes
>: them to use their default speed, 9600, or some-such.  Hence the
>: slowdown.
>: Charlie
>: --------------------------------------------------


>: #include <std/disclaimer.h>

I think you are seeing 'wrap-around' , the spd_hi and sp_vhi switches in
setserial actually map 57600 and 115200 into the 38400 'slot' , so when
you do agetty or pppd at 38400 your port is actually set to 115200.

It seems to me (a guess) that when you set another speed the mapping
falls over and only the lower bits of the word are fed to the UART chip.
Result , a much lower speed setting.

I could be assuming too much about what is going on , but I know that
setting the setserial flags and pppd at 38400 gives good 115200.

I hear later kernel versions don't need this 're-mapping' , but it works
fine.

--
-----------------------------------------------------------------------------
             I don't need to come , I'm on the internet.
              *** ALL replies to NewsGroup Please ***
-----------------------------------------------------------------------------

 
 
 

wierd solution to slow PPP found

Post by Robert Nicho » Thu, 15 Feb 1996 04:00:00



:
:I think you are seeing 'wrap-around' , the spd_hi and sp_vhi switches in
:setserial actually map 57600 and 115200 into the 38400 'slot' , so when
:you do agetty or pppd at 38400 your port is actually set to 115200.
:
:It seems to me (a guess) that when you set another speed the mapping
:falls over and only the lower bits of the word are fed to the UART chip.
:Result , a much lower speed setting.
:
:I could be assuming too much about what is going on , but I know that
:setting the setserial flags and pppd at 38400 gives good 115200.

You are assuming too much.  The actual parameter in the system call is
not an integer but a set of flags that encode the valid speed settings.
When you try to set a port speed that is not supported by both libc and
the kernel, the speed change is silently ignored and the port remains at
its current speed setting.  That might be 9600, but could just as well
be something else, depending on how the port had been used previously.

Linux kernels have supported the 38400 and 115200 rates for some time
(it's in 1.2.x), but you need a fairly recent libc in order to pass the
request to the kernel.  The program you are using to set up the port
needs to understand that the character strings "38400" and "115200"
represent valid speed settings, too.

Your statement about 'setserial' is correct.  The "spd_hi" and "spd_vhi"
parameters cause setserial to set flags in the driver such that when
you request a speed of 38400, the clock divisor that is actually passed
to the UART yields a speed of 57600 or 115200.

--

 
 
 

1. ppp problem found (I think) solution a new modem?

Haven't been able to get ppp to work, I THINK it may be my modem.  Any ideas
on "enabling" CSN1?

Check out CSN lines of dmesg:

sf0jb56u to root on /dev/ttyp0
reboot by sf0jb56u:
exiting on signal 15
Copyright (c) 1992-1999 FreeBSD Inc.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
FreeBSD 3.3-RELEASE #0: Thu Sep 16 23:40:35 GMT 1999

Timecounter "i8254" frequency 1193182 Hz
CPU: i486 DX2 (486-class CPU)
Origin = "GenuineIntel" Id = 0x435 Stepping = 5
Features=0x3<FPU,VME>
real memory = 33554432 (32768K bytes)
config> di zp0
config> di ze0
config> di lnc0
config> di le0
config> di ie0
config> di fe0
config> di ex0
config> di ed0
config> di cs0
config> di wt0
config> di scd0
config> di mcd0
config> di matcdc0
config> di bt0
config> di aha0
config> di adv0
config> en wdc1
config> po wdc1 0x170
config> ir wdc1 15
config> f wdc1 0
config> q
avail memory = 29237248 (28552K bytes)
Preloaded elf kernel "kernel" at 0xc0379000.
Preloaded userconfig_script "/boot/kernel.conf" at 0xc037909c.
Probing for PnP devices:

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


[0x00000000]
CSN 1 is disabled.

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

Probing for devices on the ISA bus:
sc0 on isa
sc0: VGA color <16 virtual consoles, flags=0x0>
atkbdc0 at 0x60-0x6f on motherboard
atkbd0 irq 1 on isa
psm0 not found
sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa
sio0: type 16450
sio1 at 0x2f8-0x2ff irq 3 on isa
sio1: type 16450
fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa
fd0: 1.44MB 3.5in
wdc0 at 0x1f0-0x1f7 irq 14 on isa
wdc0: unit 0 (wd0): <WDC AC2340H>
wd0: 325MB (666600 sectors), 1010 cyls, 12 heads, 55 S/T, 512 B/S
wdc0: unit 1 (atapi): <E-IDE CD-ROM Max 54X/Ver7.32I>, removable, accel,
dma, iordy
acd0: drive speed 171 - 8250KB/sec, 128KB cache
acd0: supported read types: CD-R, CD-RW, CD-DA, packet track
acd0: Audio: play, 255 volume levels
acd0: Mechanism: ejectable tray
acd0: Medium: no/blank disc inside, unlocked
wdc1 not found at 0x170
ppc0 not found
1 3C5x9 board(s) on ISA found at 0x300
ep0 at 0x300-0x30f irq 10 on isa
ep0: utp[*UTP*] address 00:10:5a:87:e5:7f
vga0 at 0x3b0-0x3df maddr 0xa0000 msize 131072 on isa
npx0 on motherboard
npx0: INT 16 interface
changing root device to wd0s1a

2. SOCKS client help

3. found solution for connecting 2 networks by ppp

4. Unix Admin. - Boston

5. PPP slow. Browsing slow but download fast

6. DiskSuite and Veritas File System?

7. Modem: wierd and slow response

8. Help!

9. Wierd slow machines...

10. PPP Speed is slow - VERY SLOW

11. PPP Slow. Browsing slow but download fast.

12. Why is find so slow (Re: Why use find?)

13. Slow linux ppp/fast 95 ppp