Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Optimum Trumpet Winsock settings for SLIP/PPP?

83 views
Skip to first unread message

W. Anthony Ross III

unread,
Feb 17, 1995, 2:45:22 PM2/17/95
to

Has anyone found an optimum setting for Trumpet Windsock 2.0b
in Windows 3.1 for PPP/SLIP. The setup window allows you
to change packet settings, etc.

My setup consist of a 486DX4 100Mhz, 16 Megs Ram, 14.4
fax/modem, Windows 3.1

I run Mosaic a9 and Netscape 1.0. I don't recall the
actual names of the boxes but mine is setup like this:

MTU?=1500 RWIN?=4096 MSS?=1460

If I dial up a PPP account with this setup for Tcpman,
I notice a slowdown/lockup in downloading of homepages
using Mosaic or Netscape. If I dial up a SLIP account
with the same settings, I get a little better performance.
It never locks up though like PPP does.

With the following settings in Tcpman, I get much faster
download times of homepages, etc. in both PPP and SLIP.


MTU?=1173 RWIN?=4532 MSS?=1133

OR

MTU?=1064 RWIN?=4096 MSS?=1024


Anyone else care to share their settings with Trumpet
Windsock?


Thanks,
| W. Anthony Ross, III \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\Email:\\\\\\\\\\\\\\\|
| DSC Communications Corporation \\\\\\\\\\\\\\\\\\\\ ar...@spd.dsccc.com\\|
| 1000 Coit Rd, MS/120, Plano TX 75075 \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\|
| X-Disclaimer: My views/comments/opinions are my own, not DSC's.\\\\\\\\\\|

Tom Weber

unread,
Feb 18, 1995, 8:10:14 AM2/18/95
to
In article <3i2uci$f...@sun001.dsccc.com> ar...@spd.dsccc.com (W. Anthony Ross III) writes:
>From: ar...@spd.dsccc.com (W. Anthony Ross III)
>Subject: Optimum Trumpet Winsock settings for SLIP/PPP?
>Date: 17 Feb 1995 19:45:22 GMT


>Has anyone found an optimum setting for Trumpet Windsock 2.0b
>in Windows 3.1 for PPP/SLIP. The setup window allows you
>to change packet settings, etc.

>My setup consist of a 486DX4 100Mhz, 16 Megs Ram, 14.4
>fax/modem, Windows 3.1

>I run Mosaic a9 and Netscape 1.0. I don't recall the
>actual names of the boxes but mine is setup like this:

> MTU?=1500 RWIN?=4096 MSS?=1460

>If I dial up a PPP account with this setup for Tcpman,
>I notice a slowdown/lockup in downloading of homepages
>using Mosaic or Netscape. If I dial up a SLIP account
>with the same settings, I get a little better performance.
>It never locks up though like PPP does.

>With the following settings in Tcpman, I get much faster
>download times of homepages, etc. in both PPP and SLIP.


> MTU?=1173 RWIN?=4532 MSS?=1133

> OR

> MTU?=1064 RWIN?=4096 MSS?=1024


>Anyone else care to share their settings with Trumpet
>Windsock?

Someone suggested these settings for a 28.8 PPP connection. They're working
fine for me. (I use a DX2-66 w/ 8mgs RAM).

MTU 576 RWIN 1608 MSS 536

Tom Weber
twe...@icon-stl.net
St. Louis, MO

Allin Cottrell

unread,
Feb 18, 1995, 4:30:21 PM2/18/95
to

> With the following settings in Tcpman, I get much faster
> download times of homepages, etc. in both PPP and SLIP.
>
>
> MTU?=1173 RWIN?=4532 MSS?=1133
>
> OR
>
> MTU?=1064 RWIN?=4096 MSS?=1024
>
>
> Anyone else care to share their settings with Trumpet
> Windsock?

I find that

mtu=256
rwin=848
mss=216

works quite nicely for me. I use ppp, but these are what
Peter Tattam recommends for SLIP in the Trumpet documentation.

Allin Cottrell

Daniel Steinborn

unread,
Feb 19, 1995, 10:55:37 AM2/19/95
to
In article <3i2uci$f...@sun001.dsccc.com>, ar...@spd.dsccc.com says...
>
If you look in the documentation that comes with the shareware
release of the program, you will see recommended set up information
on about the third page. This information speaks to SLIP and CSLIP
connections, but does not address PPP connections. However, I have
found that CSLIP works better in that many WWW homepages simply
won't load through a PPP connection with Netscape.

As long as you have an error correcting modem (and all 14.4 and
28.8 modems are error correcting), this should not be a problem,
in that the modem takes care of error correction over your local
phone line connection to your internet service provider.

--
Daniel Steinborn
Seattle, Washington
(dste...@cyberquest.com)

David Dolkart

unread,
Feb 19, 1995, 4:31:07 PM2/19/95
to
In article <3i5otd$e...@eis.wfunet.wfu.edu>, cott...@wfu.edu says...


I use following seetings with PPP:

MTU=1173
MSS=1133
RWIN=5120.

This is an unscientific compromise from the defaults my POP gave me.
(I changed from default to solve PPP Frame Error 1500.)

I'd be interested in finding out how to figure out optimal settings (For
example, does it vary by PC resources available?).

Dave Dolkart
7432...@compuserve.com


cyberia

unread,
Feb 19, 1995, 7:42:15 AM2/19/95
to
Regarding the optimal settings for PPP/SLIP and your modem. You may
want to disable MNP compression also, since this tends to slow down
an IP link quite considerable. Try AT%C0 (on mine, anway).

Regards

JM

Rob Ruggenberg

unread,
Feb 19, 1995, 8:44:32 AM2/19/95
to
In article <3i2uci$f...@sun001.dsccc.com> ar...@spd.dsccc.com (W. Anthony Ross III) writes:

>Has anyone found an optimum setting for Trumpet Windsock 2.0b
>in Windows 3.1 for PPP/SLIP.

>My setup consist of a 486DX4 100Mhz, 16 Megs Ram, 14.4
>fax/modem, Windows 3.1

> MTU?=1500 RWIN?=4096 MSS?=1460

>If I dial up a PPP account with this setup for Tcpman,
>I notice a slowdown/lockup in downloading of homepages
>using Mosaic or Netscape. If I dial up a SLIP account
>with the same settings, I get a little better performance.
>It never locks up though like PPP does.

>With the following settings in Tcpman, I get much faster
>download times of homepages, etc. in both PPP and SLIP.
> MTU?=1173 RWIN?=4532 MSS?=1133
> OR
> MTU?=1064 RWIN?=4096 MSS?=1024

>Anyone else care to share their settings with Trumpet Winsock?

Last week I registered Trumpet Winsock, upgraded to 2.0 revision E, and from
that moment on I did not get anymore any overruns or any other com- or
frame-error.
I have seen postings in this newsgroup of users who said that they found
no difference between revision E and the shareware version revision B.
But I do! Am I the only one?

Before I registered my system was already running fine, with a 28k8
modemconnection to a local PPP-provider, using 2.0 rev B.
I always connected on 28.800 because if I choose a higher setting I certainly would
experience overruns. Now, after registration and using rev. E, I
connect on 115.200 with no problems.

BTW: I use cybercom.drv and in my trumpwsk.ini I have these unchanged values:
mss=512
mtu=552
rwin=1656
rtomax=60
ip-buffers=32

Remarkable is that the Trumpet-registration automatically added the next item in my
trumpwsk.ini:
pkt-buffers=16

I have no idea what this thing does...

- Rob
_______________________________________________________________

Rob Ruggenberg - The Netherlands - Email: ro...@iaehv.nl

"A ship in harbor is safe, but that is not what ships are built for."
(John A. Shedd)
_______________________________________________________________

Daniel Steinborn

unread,
Feb 20, 1995, 12:39:36 PM2/20/95
to
In article <3i960v$u...@matlock.mindspring.com>, pwis...@mindspring.com
says...

>I have never had a problem with any page not loading through my PPP
>connection with Netscape. Could you give an example?
>
Gladly---the Startrek Voyager material on its homepage balked at
loading over a PPP connection but did fine over a CSLIP connection.
The National Center for Atmospheric Research and its links to
other weather related information were also quite balky. There
are others too numerous to mention that were incredibly slow over
a PPP connection and reasonably quick over a CSLIP connection.

Patrick Wiseman

unread,
Feb 19, 1995, 11:32:31 PM2/19/95
to
dste...@cyberquest.com (Daniel Steinborn) wrote:
>
[clip]

>However, I have
> found that CSLIP works better in that many WWW homepages simply
> won't load through a PPP connection with Netscape.
I have never had a problem with any page not loading through my PPP
connection with Netscape. Could you give an example?

Cheers
Patrick

Rex Deaver

unread,
Feb 22, 1995, 8:13:00 AM2/22/95
to

PMJI, but I have had no trouble with the Voyager site using Netscape
(1.0 or .94) or QMosaic with Trumpet (2.0 or 1.0) over PPP or CSLIP.
I will try some other combinations, but it doesn't seem to be a software
problem so far. FWIW.

Rex Deaver

unread,
Feb 22, 1995, 8:15:12 AM2/22/95
to
dste...@cyberquest.com (Daniel Steinborn) wrote:
>In article <3i960v$u...@matlock.mindspring.com>, pwis...@mindspring.com
<snip>

>Gladly---the Startrek Voyager material on its homepage balked at
>loading over a PPP connection but did fine over a CSLIP connection.

Sorry, previous post should have read "CSLIP in Trumpet 1.0 and 2.0 and PPP in 2.0"

Sinned

unread,
Feb 23, 1995, 12:16:12 AM2/23/95
to
Daniel, i had the same problem and corrected it by changing the settings
in the Winsock set up box as follows, let me kn ow if this works for you>

MTU 1173 TCP RWINN 4532 TCP MSS 1133

Good Luck!

Dennis
sin...@intellinet.com

Mike Anthis

unread,
Feb 23, 1995, 1:55:52 PM2/23/95
to
In article <3igqmq$h...@taco.cc.ncsu.edu>,
Rhett Guthrie <rdgu...@unity.ncsu.edu> wrote:
>>...

>> MTU?=1173 RWIN?=4532 MSS?=1133
>> OR
>> MTU?=1064 RWIN?=4096 MSS?=1024
>>...
>
>Well I am using:
>mtu=1046
>rwin=4096
>mss=1006

Could someone who understands the tradeoffs give a brief
description of them? I looked at the definitions of these
fields, and understand the basics, but I don't know what
compels someone to adjust them up or down.

Thanks,
.mike
--
Mike Anthis ant...@sleepy.ns.cs.boeing.com
ant...@halcyon.com
90% of good taste is found in 10% of the population.
These opinions are mine and not those of my computer.

Rhett Guthrie

unread,
Feb 22, 1995, 9:08:26 PM2/22/95
to
>With the following settings in Tcpman, I get much faster
>download times of homepages, etc. in both PPP and SLIP.
>
>
> MTU?=1173 RWIN?=4532 MSS?=1133
>
> OR
>
> MTU?=1064 RWIN?=4096 MSS?=1024
>
>
>Anyone else care to share their settings with Trumpet
>Windsock?

Well I am using:
mtu=1046
rwin=4096
mss=1006
I have been told that these are good settings, although it depends upon
many factors: eg whether you are downloading binray,text,images,
amount of net traffic etc.

Steve Wetherell

unread,
Feb 24, 1995, 10:33:56 AM2/24/95
to
In article <D4Gv9...@bcstec.ca.boeing.com>, ant...@bcstec.ca.boeing.com says...

>
>In article <3igqmq$h...@taco.cc.ncsu.edu>,
>Rhett Guthrie <rdgu...@unity.ncsu.edu> wrote:
>>>...
>>> MTU?=1173 RWIN?=4532 MSS?=1133
>>> OR
>>> MTU?=1064 RWIN?=4096 MSS?=1024
>>>...
>>
>>Well I am using:
>>mtu=1046
>>rwin=4096
>>mss=1006
>
>Could someone who understands the tradeoffs give a brief
>description of them? I looked at the definitions of these
>fields, and understand the basics, but I don't know what
>compels someone to adjust them up or down.
>
>Thanks,
>.mike

In December, Peter Tattam, the author of Trumpet Winsock, posted the following on
another newsgroup in response to a similar question :

--------------------------------------------------------------------
Subject: Re: Best settings for 28.8??
From: pe...@trumpet.com.au (Peter R. Tattam)


As much baud rate as your serial card can handle. (I use 38400 without a
16550A, 115200 with a 16550af)

Online DCD detection (the modem must have at&c1 saved), and auto dial on
startup clicked in the dialler menu.

I always leave MTU=1500, if your slip server accepts it, or the maximum
allowable. You want to avoid IP fragmentation at all costs...it causes too
many problems with fragment reassembly. This will only apply to outgoing
packets, the winsock will handle any data up to 1500, with full reassembly.

MSS & RWIN are tricky ones.

I suggest for CSLIP/CPPP MSS=212, RWIN=848

For SLIP/PPP MSS=512, RWIN=2048

As a rule of thumb, RWIN = 4 times MSS.

I definitely *DON'T* suggest MSS less that 200 or so unless you are using
CSLIP. The packet overheads will soak up your transfer rate.

If you have a lot of trouble with packets being dropped and it is an
interactive connection...e.g. telnet, talk etc, setting the TCP RTO MAX to
a smaller figure may help significantly. Also reducing the RWIN to MSS
ratio to 2 or 1 may help too.

Modem settings..
Error correction is a must. One bad or dropped character can cause havoc
with a tcpip connections. Compression in the modem is always beneficial -
leave it on, the modem hardware handles it quite well.

Comm drivers & hardware.
I've tried them all - they all fail with overrun errors when doing heavy
disk i/o. A 16550AF is more or less standard if you want high transfer rates
using speeds of 9600 or more. Unfortunately, the DOS/Windows/BIOS architecture
still cannot prevent overrun errors at high speeds. The usual problem is
that either DOS/Windows or the BIOS disables interrupts for quite a long time
while doing disk i/o. The real solution is for some smart person to go in and
hack up a better disk driver. Unfortunately, as far as I can see, the WDCTRL
driver is part of the windows 386 kernel, so this would be exceedingly
difficult to do.

However, my experience shows that internal modems don't suffer the same
problems because the modems themselves buffer much more than 16
characters..typically around 1K or so. This makes them much more reliable than
extranl modem/comms card solution. The only drawback is that they can be
difficult to configure correctly and sometimes clash with other comms cards.
of course all this mileage will vary greatly.. what works well for me may
just not work well for you.

Cheers...

Peter

--
Peter R. Tattam - Managing Director P.Ta...@trumpet.com.au
Trumpet Software International Pty Ltd.
Phone: 61-02-450220 Fax: 61-02-450210

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

David Rowe

unread,
Feb 28, 1995, 12:38:16 PM2/28/95
to
In article <tweber.37...@icon-stl.net>,
twe...@icon-stl.net (Tom Weber) wrote:

[stuff deleted]
>
For a PPP account, the minimum MTU is 1500. The RWIN should be 3 to 4
times the MTU and the MSS should be MTU-40. This is from the trumpet
docs.
For a SLIP account, the MTU can be between 256 and 1006. It is set by the
system you are dialing into. I am using a 14.4 modem with a MTU set to
1006 with no problems. The key is to match the MTU on each end of the
link. The RWIN and MSS follow the same rules as for PPP.

Jason R. Mastaler

unread,
Mar 22, 1995, 1:12:11 AM3/22/95
to
In article <tweber.37...@icon-stl.net>, Tom Weber says...

>>Anyone else care to share their settings with Trumpet
>>Windsock?
>
>Someone suggested these settings for a 28.8 PPP connection. They're working
>fine for me. (I use a DX2-66 w/ 8mgs RAM).
>
> MTU 576 RWIN 1608 MSS 536

According to the Winsock Documentation, the following settings are
said the be the BEST if you connect via a slip/ppp connection. Indeed,
I have found that to be true.

MTU 256, TCP RWIN 848, TCP MSS 212, TCP RTO MAX 60

--
Jason R. Mastaler <ja...@IS.NET> | PGP Public Key: Available
http://www.ticllc.net/home/jason/index.html | Running OS/2 at WARP speed!

David Lieberman

unread,
Mar 23, 1995, 4:56:51 PM3/23/95
to

Is anybody succesfully running TCP/IP over Arcnet on a Windows NT
system?

The NT documentation certifies Arcnet cards from Thomas Conrad and
comes with a generic Arcnet driver. We bought two cards and put them
in two NT systems. The two systems can talk to each other just fine.
But when we try to talk to an Arcnet box it doesn't work.

We suspect that the driver is encapsulating Ethernet frames within
Arcnet frames and when you have two of them talking to each other it
works but if you talk to a true Arcnet system it doesn't.

Does anybody have any experience they can share with us? Most of the
drivers floating around are for ms-dos, not for NT.

Any advice will be appreciated.

David Lieberman

The Old Bear

unread,
Mar 23, 1995, 6:59:22 PM3/23/95
to
In article <3kof3r$o...@news1.is.net> ja...@IS.NET (Jason R. Mastaler) writes:
>From: ja...@IS.NET (Jason R. Mastaler)
>Subject: Re: Optimum Trumpet Winsock settings for SLIP/PPP?
>Date: 22 Mar 1995 06:12:11 GMT

>In article <tweber.37...@icon-stl.net>, Tom Weber says...
>
>>>Anyone else care to share their settings with Trumpet
>>>Windsock?
>>

>According to the Winsock Documentation, the following settings are


>said the be the BEST if you connect via a slip/ppp connection. Indeed,
>I have found that to be true.

>MTU 256, TCP RWIN 848, TCP MSS 212, TCP RTO MAX 60

If you want to use the /DCC function on the WS-IRC client, you need to
have the MTU set to 512 or greater because of the block size that
WS-IRC uses. If MTU is set lower, when you call /DCC, the first block
partially transfers and then the transfer hangs.

At the other extreme, I have just discovered (with the help of several
people on this newsgroup) a problem of transfers hanging from certain
WWW and FTP sites was due to settings of MTU at 1500 and MSS at 1460.

I am now settled in with MTU 1064, MSS 1024, and RWIN 4096 and everything
seems to be working smoothly.

Cheers,
The Old Bear
old...@arctos.com

Dan Lanciani

unread,
Mar 23, 1995, 11:36:22 PM3/23/95
to
In article <davelD5...@netcom.com>, da...@netcom.com (David Lieberman) writes:

[...]


| We suspect that the driver is encapsulating Ethernet frames within
| Arcnet frames and when you have two of them talking to each other it
| works but if you talk to a true Arcnet system it doesn't.

It is indeed true that Microsoft's ARCnet drivers use fake Ethernet
frames. I think this is even described in one of the Windows resource
kits. They state that such frames will not be compatible with (what
is called) Novell's standard. Now, I believe Microsoft has compatible
NDIS ARCnet drivers for NT, Windows, and DOS. So the quickest solution
is probably to switch the ``true Arcnet'' system(s) to Microsoft ARCnet.
If you can't beat them, join them. :) (Oh, you have 500 existing systems?
Well... :)

Dan Lanciani
ddl@harvard.*

Jim Cook

unread,
Mar 24, 1995, 10:32:44 AM3/24/95
to
> Are these settings optimal for 14.4 connections as well 'cause my
> settings are much higher?
> MTU 1500 RWIN 4096 MSS 1460 RTO MAX 60

What does it all mean ????

This is all very well, but I would love to understand more about
this and hence determine what configuration is optimal.


Regards

Jim Cook.

D K

unread,
Mar 23, 1995, 3:14:07 AM3/23/95
to
ja...@IS.NET (Jason R. Mastaler) wrote:

>>Someone suggested these settings for a 28.8 PPP connection. They're working
>>fine for me. (I use a DX2-66 w/ 8mgs RAM).
>>
>> MTU 576 RWIN 1608 MSS 536
>
>According to the Winsock Documentation, the following settings are
>said the be the BEST if you connect via a slip/ppp connection. Indeed,
>I have found that to be true.

>MTU 256, TCP RWIN 848, TCP MSS 212, TCP RTO MAX 60

Are these settings optimal for 14.4 connections as well 'cause my

Bing Ho

unread,
Mar 25, 1995, 2:27:58 PM3/25/95
to
In article <3kuoms$9...@newsgate.dircon.co.uk>,

This is a good point. I don't know very much about tcp/ip and the relationship
these settings have on how optimally (C)SLIP/PPP run, but I think they depend
on the the SLIP provider's settings. Here in Berkeley, we have a small and
large packet setup for SLIP and the small packet (same as the recommended
settings for Trumpet) has extremely low latency (as low as 90-100 ms under
ws-ftp32 ping) and the large packet size (MTU=1006), the latency shoots up but
the throughput is correspondingly higher.

I think that the reason why so little is understood about this is because it
varies so much from site to site. I would be happy to mail my latency and
throughput numbers for my given configuration, applications, etc. to anybody
who would like to know.
--
Bing Ho
bi...@mendel.berkeley.edu University of California at Berkeley

Peter H. Lemieux

unread,
Mar 27, 1995, 10:42:58 PM3/27/95
to
In article <3kuoms$9...@newsgate.dircon.co.uk>, Jim Cook <ji...@docctrl.dircon.co.uk> says:
>
>> Are these settings optimal for 14.4 connections as well 'cause my
>> settings are much higher?
>> MTU 1500 RWIN 4096 MSS 1460 RTO MAX 60
>
>What does it all mean ????

Imagine, first, that you're on an Ethernet. Ethernet packets contain 1500
bytes of data and a 14 character header. TCP/IP packets over Ethernet
fit in the 1500 byte space, but they have a 40 byte header (IP addresses
etc etc). In this model, therefore, the Maximum Segment Size is 1460,
while the Maximum Transmission Unit is 1500.

PPP uses the same framing model as Ethernet so PPP connections over
TW should also have MTU's of 1500 and MSS's of 1460. SLIP connections,
on the other hand, work better with smaller packet sizes; numbers like
MTU=296 and MSS=256 are common. (P. Tattam recommends MSS=212 for CSLIP.
I use this and it seems quite efficient.)

The receive window (RWIN) is essentially a buffer; it's value indicates
the largest amount of data that can be downloaded before being sent on
to the application. 4096 isn't bad, though for CSLIP Tattam recommends
a number like 5*MSS.

I'm still in the dark about RTO MAX, though I think it is a "timeout"
parameter in seconds.

Get yourself a book on TCP/IP if you're curious about the details of
this stuff.

Peter


Peter H. Lemieux, President http://www.cyways.com
cyways, inc. Voice: +1 (800) 529-9297
Watertown, Massachusetts, USA Fax: +1 (617) 926-8440
--- Your source for total Internet solutions(TM) ---

James Culbert

unread,
Mar 31, 1995, 3:00:00 AM3/31/95
to

>Peter

WIth serial line connections, the tuning parameters that you are most
concerned with are the MSS and the RWIN parameters. MSS is generally
not controlled directly rather most configurations let you specify the
MTU. MSS and MTU are roughly equivalent. The Segment Size is a TCP
(Transport Level) specific quantity that limits the largest chunk of
data that TCP will try to aggregate before sending out on the network.
The MTU is an IP specific quantity (Network Level) which specifies the
largest chunk of data that can be sent by the network out on the
pyhiscal wire. They are generally related in the TCP/IP teamed world
by the difference of the TCP packet header.

When tuning for a serial line there are a number of considerations.
The most important one, however, is the MSS to RWIN ratio.
Specifically, you want RWIN/MSS to be a number between 3 and 5. Note
this is very much a generalization. The actual number is determined by
your average throughput and latency.

The problem is the following: If your MSS is some big number (say
1460) and your receive window is small (say 2048) then when your
machine talks to another TCP stack, the following occurs. By setting
the MSS to 1460, you advertise to your peer that your network will
support TCP segments that are that large. Even if the sender can send
larger packets, it will clamp its MSS back to 1460 for communication
on the virtual circuit that connects the two of you. By setting your
receive window to 2048, you advertise to your peer that you have room
enough for 2048 bytes before you will no longer be able to accept any
more data.

Now consider what happens when you try to FTP a large file. The sender
takes the biggest chunk of data possible and puts it on the wire. This
chunk is 1460 bytes. It then says "I know the receiver has a 2048 byte
buffer, I just sent her 1460 bytes so there are 588 bytes of room left
in her receive buffer". Now we have another segment to send. We want
to send 1460 bytes but we know that you can't eat that many bytes so
we wait for an acknowledgement from you saying that you have cleared
some buffer space. The problem here is that the receiving end has to
receieve all of the 1460 bytes before it can send you an
acknoledgement.

Therefore, after sending the 1460 byte packet, the sender will have to
wait the full transmission time of the last byte, plus the sender side
latency (sender to receiver) plus the receiver side latencey (receiver
to sender). Now for a carrier like sprintnet, for instance, round trip
latencies average between 600-900ms. For a 9600bps connection, lets
assume that you average 1byte/ms transmission rate. Therefore, total
time that the sender has to wait for an ack from the receiver is
approximately 750ms. This means that while streaming large chunks of
data, having this mistuned RWIN/MSS ratio can introduce an unnecessary
750ms deadspace between 1460 byte transmissions. Therefore, to
transmit N 1460byte packets, the transmission time is 1460*N +
750*(N-1) milliseconds = (2210*N - 750) giving you a packet rate of
(1000+750)/2210 packets per second. Bytes per second =
1460*packets-per-second so, drumroll please, your total throughput is
8 bytes per second. This calculation was made based on an average
1byte/sec transmission rate so you just lost 20%.

The two ways to combat this scenario are to increase the size of the
receive buffer relative to the MSS or to decrease the size of the MSS
relative to the receive buffer. Decreasing the MSS size has the
disadvantage of generating more/smaller packets decreasing your header
to data efficiency but has the advantage that it does not chew up
memory on the receiving machine (some applications use lots of memory
so to increase the buffer size also is not an attractive option).

Note that the analysis of what the right RWIN/MSS ration is has
nothing to do with the link level protocol used. So distinguisihing
between PPP and SLIP does not make a lot of sense. There are other
considerations, of course, like what the most efficient packet size is
given your link level framing (i.e dialup over x.25 has some
interesting tuning considerations). But the most important issue for
dialup ip is the RWIN/MSS ratio.


Greg Sullivan

unread,
Apr 1, 1995, 3:00:00 AM4/1/95
to
What happens when RWIN/MSS is increased well above the range 3 to 5?
The reason I ask is that I am using RWIN = 4240, MSS = 212 (ratio = 20!)
at the moment, and it seems to work fine. I need to have a relatively large
RWIN to get maximum throughput for file transfers from remote locations.
(i.e, otherwise round-trip delays cause the throughput to drop, as
described in previous reply, I would assume).

When connected to machines that have a LAN connection to the terminal
server that I dial into, I have to be careful of how large I make RWIN,
due to (I think) the terminal server's buffer overflowing. But,
RWIN = 4240 seems to be working fine for this case as well.

Greg.

-------------------------------------------------------------------------------
Greg Sullivan email: sull...@aussie.enet.dec.com
Digital Equipment Corporation phone: +61 2 561-6445
Sydney fax: +61 2 427-4386
AUSTRALIA

Alex Gemici

unread,
Apr 3, 1995, 3:00:00 AM4/3/95
to
In article <3ljod1$n9g...@sna.dec.com>, sull...@aussie.enet.dec.com
says...

>
>What happens when RWIN/MSS is increased well above the range 3 to 5?
>The reason I ask is that I am using RWIN = 4240, MSS = 212 (ratio = 20!)
>at the moment, and it seems to work fine. I need to have a relatively
large
>RWIN to get maximum throughput for file transfers from remote locations.
>(i.e, otherwise round-trip delays cause the throughput to drop, as
>described in previous reply, I would assume).
>
>When connected to machines that have a LAN connection to the terminal
>server that I dial into, I have to be careful of how large I make RWIN,
>due to (I think) the terminal server's buffer overflowing. But,
>RWIN = 4240 seems to be working fine for this case as well.
>

I have had problems with high MSS settings and have been able to work
great using MSS of 212 and RWIN of 1060. After reading this post, I
switched to RWIN of 4240 leaving MSS at 212 and culd not access some www
sites. (Netscape says Host contacted waiting for reply and just sits
there. The site is http://espnet.sportszone.com/nfl/) I then switched
back to RWIN=1060 and it worked great. So I am staying at 1060.

-Alex


Greg Sullivan

unread,
Apr 4, 1995, 3:00:00 AM4/4/95
to
In article <3lp9ff$7...@uucp.intac.com>, gem...@intac.com (Alex Gemici) wrote:
>I have had problems with high MSS settings and have been able to work
>great using MSS of 212 and RWIN of 1060. After reading this post, I
>switched to RWIN of 4240 leaving MSS at 212 and culd not access some www
>sites. (Netscape says Host contacted waiting for reply and just sits
>there. The site is http://espnet.sportszone.com/nfl/) I then switched
>back to RWIN=1060 and it worked great. So I am staying at 1060.

Interesting - I am the author of the original post, and I have no problems
accessing that site, with RWIN set to 4240. The first time I tried,
my RWIN was actually set to 4140, by accident. So, I disconnected
and tried again at 4240. Still no problems.

0 new messages