shields@pur-ee.UUCP (Jeffrey Shields) (11/19/85)
We have been putting together a packet radio network in the midwest
on 145.01 Mhz and are beginning to experience some of the congestion
problems that have been going on for some time in other more heavily
populated areas of the country. In a few years when the network
is better (high speed links on 220 Mhz and above, smarter digipeaters,
network node controllers, etc.) most of these problems will probably go away.
In the meantime we have been thinking of ways to cut down on the congestion,
and are interested in approaches that other groups have been using.
Here are some of the ideas that we have been discussing locally :
General things:
- Agree on some standard value for DWAIT in your area (the time each TNC
waits after channel is clear before sending a packet). Most people are
probably using the default, which is ok as long as it has the same value
from one manufacturer to another, and as long as everyone sticks to it.
- Coordinate frequencies through state repeater council, using the other
"packet frequencies" (145.03, 145.05, etc.) for local QSO's, local BBS's,
etc.
- Coordinate Bulletin Board tasks. I understand that in New Jersey area, they
use one BBS for HF gateway only, one for main message server, one for files
(Gateway, ARRL newsletter, W5YI report, packet maps, etc.), and one for a
mail trunk to forward messages.
Bulletin Boards (System Operator) (mostly have W0RLI type BBS in mind here)
- If possible, have the BBS located at a station that has good local coverage
(good antenna, higher power - say 30 watts or so, etc.). Then local users
can connect directly, rather than having to go through a digipeater.
- Route beacon through one digipeater at most.
- Increase the time between beacons to, say, every 30 minutes.
- Stamp any personal messages and messages to be forwarded as "P"rivate so
that others won't tie up BBS reading them.
- Set the flag in CONFIG.TNC file to erase messages after they are forwarded.
- If you have a chain of W0RLI BBS's, forward messages to next solid link in
each direction, and let them forward on, rather than trying to connect
directly to each BBS through a chain of digipeaters.
- Make up a disk catalog file, which contains a 1 line description of
every file on the disk. Then people can quickly see what a file is before
tying up the BBS downloading a large file that they really don't want.
- The "J" command, which lists connections and calls heard, seems to be
popular, so set length of J list to a reasonable value (say 10 lines).
During "prime time" hours (say 5-11 PM), the following things might help:
- Increase DWAIT above the standard value, so that others have a higher
channel priority than the BBS.
- Decrease MAXFRAME so that fewer packets are sent at once, which ties up
digipeater for less time per transmission and reduces collisions. Although,
looks like there would be a higher protocol overhead (need more ACK's from
receiver) for smaller MAXFRAME.
- Is there some optimum combination of TNC settings for a BBS? I see from the
W0RLI sysop manual that W3IWI and others use SENDPAC $0D, MAXFRAME 5, and
DWAIT 36 (TAPR-2). Some fellows in this area are using SENDPAC $7F and lower
MAXFRAME to send everything out in 128 byte packets. Also, when using a
longer DWAIT on the BBS, we have had some timing problems that seem to cause
a lot more retries than normal (which makes the congestion problem worse).
- Seems like there are some trade-offs here between utilizing the channel
more efficently and utilizing the BBS more efficently. During prime time,
we could set the TNC parameters to give the channel (i.e. non-BBS users on
frequency) higher priority at the expense of slower BBS throughput, and then
at other times maybe we could bump up the BBS priority.
- When forwarding messages, you would probably want good BBS throughput.
This can be done now by setting the TNC parameters in the FWD.TNC file,
but is there a way at present to set BBS parameters automatically during
a designated "prime time" segment? Maybe a possibility for future software
release? Also during this "prime time" segment, you could have software
disable file transfers to cut down on BBS traffic.
- Some people are in favor of solving these problems by getting the BBS's
off of 145.01 altogether. But then very few can connect because we have no
digipeaters on other frequencies right now (one reason for having BBS located
at a station with good local coverage).
Bulletin Boards (Users)
- If possible, connect directly rather than going through a digipeater.
- Stamp any personal messages and messages to be forwarded as "P" so that
others won't tie up BBS reading them.
- Erase any messages addressed to you after you read them.
- Refrain from long file transfers during "prime time" hours (say 5-11 PM). If
you're using your PC as a terminal, it may be possible to set up your
terminal software to wake up in the wee hours and download the file to your
printer or disk. This can be done, for instance, with MEX114.COM (for details
see file PD:<CPM.MEX>AUTOMEX.IQF.1 on simtel20).
- If you receive a lot of mail at a BBS, it might be useful to set up your
home station to look like a BBS using the CTEXT string and have the BBS
forward everything to your station in the wee hours (see recent TAPR Packet
Status Register for details).
- Refrain from DX'ing other BBS's through multiple digipeaters during "prime
time" hours. The experience here has been that (if you connect at all) the
throughput is very slow because of the high number of collisions.
Packet QSO's in general
- Stick to the agreed upon value of DWAIT.
- Don't route beacons through multiple digipeaters.
- Make beacon text short and to the point. Seems like Name/QTH would do.
- Increase beacon time or, after the novelty wears off, maybe just refrain from
beacons altogether, especially during "prime time".
- For local QSO's, connect directly and QSY to another frequency if possible.
- Refrain from DX'ing through multiple digipeaters during "prime time" hours.
(Although, that's probably the time when everyone is around to be connected
to .... same problems with throughput mentioned above, though.)
Well, anyway, those are some of the things we are thinking about here. At this
point, none of this is carved in stone. While most of the suggestions seem
fairly reasonable (and may be in practice by most already), it will take the
cooperation of everybody to make it all work.
Maybe we should view these "national packet radio calling frequencies" as a
scarce, shared resource. I had 145.01 Mhz in mind when I wrote this, but I
understand that a lot of the same problems are cropping up on 14.103 Mhz also.
Looks like the main tasks ahead will be to make everyone aware of the problem,
openly discuss the alternatives, and adopt some reasonable guidelines that
everyone can live with until we go on to the next level of the network.
We are interested in hearing other people's thoughts on all of this.
73's .... Jeff Shields N9CZA (ihnp4!pur-ee!shields)
W.Lafayette,Indiana