| |
PB0AFK > BPQ 17.03.99 19:20l 532 Lines 26813 Bytes #-10078 (0) @ WW
BID : 23725-PB0AFK
Read: VK3EUB SP6VXT GUEST
Subj: BPQ-NEDA.TXT by VE2BMQ
Path: DB0AAB<DB0MWS<DB0RBS<DB0PSC<DB0ACH<DB0ACC<PI8DRS<PI8ZWL<PI8AWT<PI8JYL<
PI8WFL<PI8MBQ<PI8VNW
Sent: 990317/1253 41554@PI8VNW.#ZH2.NLD.EU $:23725-PB0AFK
From: PB0AFK@PI8VNW.#ZH2.NLD.EU
To : BPQ@WW
[¯¯¯ TST HOST 1.43b, UTC diff:5, Local time: Wed Mar 17 15:30:58 1999 ®®®]
--------------------------------------
---------------------------------------------------------------------------
N.E.D.A. - Devoted to Packet Neworking in the NorthEast
---------------------------------------------------------------------------
--------------------------------------
G8BPQ PACKET SWITCH
--------------------------------------
Recommended CONFIGURATION FILE
Suggested BPQ Parameters equivalent to
regular NEDA Network Parameters.
for BPQ Version 4.08a
(Revised Draft Copy from May 95 meeting for testing purposes)
Rev:March 1996
Compiled and edited by: Burt VE2BMQ
Only the parameters that should be adjusted from the values in
the supplied default BPQCFG.TXT are mentioned. You must still
enter all the parameters needed for your particular system in the
BPQCFG.TXT file. Consult the BPQ PORTS.DOC for required
parameters. Just try to make sure that the following parameters
are adjusted to the values shown.
Note: Any changes since the May 1995 meeting are detailed at the end of
this document.
*****************
Network System Parameters
OBSINIT=5 INITIAL OBSOLESCENCE VALUE
OBSMIN=3 MINIMUM OBSOLESCENCE TO BROADCAST
NODESINTERVAL=15 NODES BROADCAST INTERVAL IN Minutes
IDINTERVAL=0 We don't need IDs.
L3TIMETOLIVE=13 MAX L3 HOPS.
L4RETRIES=2 (1) LEVEL 4 RETRY COUNT - Does 1 actually work?
L4TIMEOUT=180 LEVEL 4 TIMEOUT in seconds
L4DELAY=10 LEVEL 4 DELAYED ACK TIMER in seconds
L4WINDOW=2 DEFAULT LEVEL 4 WINDOW SIZE (L4 MAXFRAME)
MAXNODES=100 Maximum known nodes in node table
MINQUAL=50 MINIMUM QUALITY TO ADD TO NODES TABLE.
Note:this is not the same definition as the
MINQUAL in the ports configuration section.
Also it is overridden by QUALITY in the
ports section.
BBSQUAL=128 BBS Quality relative to NODE - used to limit
'spread' of the BBS through the network to
your required service area. Start with 128
and adjust so that BBS shows ONLY at the
nodes normally used by its users. IE: At
your stack and at the most one visible
hop away.
TNC DEFAULT PARAMS
PACLEN=236 MAX PACKET SIZE in bytes. More would
fragment NET/ROM frames.
LEVEL 2 PARAMETERS
T3=320 LINK VALIDATION TIMER in seconds (5 MINS)
IDLETIME=7200 IDLE LINK SHUTDOWN TIMER in seconds (2 hrs)
CONFIGURATION OPTIONS
HIDENODES=1 # Nodes only listed with N * command
**********************
AX25 PORT DEFINITIONS
User LAN Port
* These parameters are for a visible port where live keyboard stations
access the network and access resources over the network. No station
is heard on-channel by the user port that transmits more than 3K/hour
average or 300K/Month. No node-to-node communications on this port. No
node broadcasts out on this port. All node broadcasts in on this port
are ignored.
PORT
ID=USER PORT
QUALITY=0 Inhibits node broadcasts and L3/L4 connects
on this port.
MAXFRAME=1 for 1200 bps. =4 for 9600 bps (See note #9)
TXDELAY=350 Milliseconds
SLOTTIME=200 Milliseconds
PERSIST=64
FRACK=6000 Milliseconds(See note #8)
RESPTIME=500 Milliseconds
RETRIES=10
PACLEN=236
DIGIFLAG=0
ENDPORT
**********************
Non-Ideal User Port
* These parameters are for a visible port hearing other nodes, servers or
any station generating large amounts of data. It probably would also be
plagued by serious HTS (Hidden Transmitter Syndrome) effects.
Affectionately known as a "ZOO" channel.
PORT
ID=NON-IDEAL USER PORT
QUALITY=0 Inhibits node broadcasts and L3/L4 connects
on this port.
MAXFRAME=1
TXDELAY=350 Milliseconds
SLOTTIME=200 Milliseconds
PERSIST=64 Or even 40 for extremely congested channels.
FRACK=15000 Milliseconds. This is the price you pay
for a zoo channel. Depends on TNC type.
(See note#8)
RESPTIME=500 Milliseconds
RETRIES=10
PACLEN=236
DIGIFLAG=0
ENDPORT
*********************************
Gateway Port
* These parameters are for a visible non-2m port that acts as a hopping
point between networks. Accepts node broadcasts from the other network but
only broadcasts itself. The purpose of this is to allow two networks that
have conflicting parameters to meet, allowing users and services to cross
over, but without having the node lists intermingle. We're never going to
get a gateway defined exactly because they will be customized for the
various circumstances every time but this is the general idea.
PORT
ID=GATEWAY PORT
QUALITY=50
MAXFRAME=1 (See note #9)
TXDELAY=xxx Milliseconds - Set depending on Radio and
parameters of the other networks that
are gatewayed into.
SLOTTIME=200 Milliseconds
PERSIST=64
FRACK=12000 Milliseconds- Adjust according to other
stations on port.(See note#8)
RESPTIME=500 Milliseconds
RETRIES=10
PACLEN=236
DIGIFLAG=0
MINQUAL=210 This effectively limits node broadcasts
(on the port directed towards the other
network) to this node information only.
ENDPORT
***************************
NETROM Matrix Port
* These port parameters are for a port connected to a NETROM/TheNET Node
RS-232 port or to a diode matrix. It assumes that there will be no feedthru
of Node information from any other ports on the BPQ switch. If there are
nodes fed thru to be broadcast on this port, then Quality should be set to
161 on both ends of the NETROM link (See note #7). Also make sure that this
port is actually connected to a matrix or NETROM node (See note #11).
PORT
ID=NETROM CONNECTION
QUALITY=203 (See note #7)
MAXFRAME=1 (See note #9)
FRACK=1000 Milliseconds. Not important-few retries.
RESPTIME=0 Milliseconds (See note #10)
RETRIES=10
PACLEN=236
FULLDUP=0/1 0 for diode matrix, 1 for connection to
a single NETROM/TheNET node RS232 port.
DIGIFLAG=0
QUALADJUST=100 (See note #1)
ENDPORT
*********************************
Direct BPQ Radio Ports
BPQ Ports with a direct radio connection are usually interfaced with a TNC
operating in KISS mode or with an internal HDLC card like a DRSI card. The
following are for KISS TNCs. Where other interfaces are used, use these
parameters as guidelines.(See also: Shared KISS Ports (below))
BPQKISS Dedicated Point-to-Point Link Ports
* These port parameters are for a port used as a dedicated point-to-point
link in a network using a TNC with BPQKISS EPROM installed or a Kantronics
TNC with special KISS eprom. Use of standard KISS TNCs should be
discouraged wherever possible.
PORT
ID= DEDICATED POINT-TO-POINT PORT
TYPE=ASYNC
PROTOCOL=KISS
CHANNEL=A Or B,C,..according to how the BPQKISS
EPROM was burnt.
QUALITY=203 or 161 Use 203 if you are not broadcasting
nodes from other ports. Use 161 if you
are broadcasting nodes from other ports.
Node at other end of this link should
also have HDLC quality set to the same
quality as this port.(See note #7)
MAXFRAME=1 (See note #9)
TXDELAY=xxx Milliseconds - Set to value appropriate
for the radio used.
SLOTTIME=10 Milliseconds. See also: Shared KISS Parms
PERSIST=255 See also:Shared KISS Parms
FRACK=4000 Milliseconds. (See note #8)See also:Shared KISS Parms
RESPTIME=200 Milliseconds
RETRIES=10
PACLEN=236
DIGIFLAG=0
KISSOPTIONS=POLLED,CHECKSUM,ACKMODE
VALIDCALLS=<callsign1,callsign2,...> Used instead of locking ROUTES.
See note #6.
ENDPORT
*******************************
Standard KISS Dedicated Point- to-Point Link Port
* These port parameters are for a port used as a dedicated point-to-point
link in a network using a TNC and standard KISS mode where it is not
possible to use BPQKISS mentioned above. Standard KISS TNCs should only be
used if it is impossible to use BPQKISS (or equivalent KISS using
handshaking on the serial connection).
PORT
ID= DEDICATED POINT-TO-POINT KISS PORT
TYPE=ASYNC
PROTOCOL=KISS
QUALITY=203 or 161 (See note #7) Use 203 if you are not
broadcasting nodes from other ports. Use
161 if you are broadcasting nodes from
other ports. Node at other end of this
link should also have RS-232 quality set
to the same quality as this port.
MAXFRAME=1 (See note #9)
TXDELAY=xxx Milliseconds - Set to value appropriate
for the radio used.
SLOTTIME=10 Milliseconds. See also: Shared KISS Parms
PERSIST=255 See also: Shared KISS Parms
FRACK=4000 Milliseconds.(See note #8)See also:Shared KISS Parms
RESPTIME=200 Milliseconds
RETRIES=10
PACLEN=236
DIGIFLAG=0
VALIDCALLS=<callsign1,callsign2,...> Used instead of
locked ROUTES. See note#6.
ENDPORT
*********************************
Shared KISS Ports
* On the last two KISS port lists, if the port is used on a HTS (Hidden
Transmitter Syndrome) Free SHARED channel, then the following parameters
are to be used instead. A SHARED HTS Free channel would be one where more
than two (2) stations, all of whom can hear each other well, are linked or
where a regenerating digital repeater is used.
FRACK=8000 Milliseconds (See note #8)
PERSIST=xx Adjust according to number of stations
PERSIST=256/(N-1)
SLOTTIME=200 Milliseconds
QUALADJUST=100 Enables equivalent to X1J alternate
broadcast algorithm. (See note #1).
********************************************************** ******
Notes:
QUALADJUST
1. To enable the equivalent to the X1J "ALTERNATE BROADCAST ALGORITHM",
add QUALADJUST=100 (percent) to the Ax.25 port definition. This will
kill the quality of any node in the node broadcast from this port
whose best quality route also comes in on the same port. This has been
checked and verified. Use this feature on any port that sees more than
one network node such as a diode matrix connection or radio port on a
SHARED HTS Free channel including a channel with a regenerative
repeater.
Disabling Node Broadcasts
2. To disable all node broadcasts from a BPQ port, set QUALITY=0 in ax.25
port definition. This will also prevent all L3/L4 connects on this
port. Use this parameter on all direct user ports.
Limit Node Broadcasts to Node Itself
3. To disable all node broadcasts except the BPQ switch itself from one
of its ports, set MINQUAL=210 (or any number higher than the highest
node quality in the node table but less than 255) in the ax.25 port
definition. This would be appropriate for Gateways. Do not confuse
this MINQUAL with the MINQUAL in the Network System Parameters section
of BPQCFG.TXT which defines the minimum quality to add to the node
table. This has been checked and it appears to be valid. Note: This
will NOT broadcast any BBS or other server application running on the
BPQ switch. This has also been verified.
UI Transmissions
4. Where it is necessary to transmit UI frames on a radio port, such as
when a BBS sends TPK or "Mail For" beacons, the radio port must
operate directly from the BPQ. In these cases it is necessary to use
an internal HDLC card in the computer or a TNC operating in "DED Host
Mode" or in KISS mode. If you must use KISS mode, then use dedicated
BPQKISS firmware if possible. This is especially true for congested
radio channels where the "standard" KISS mode can seriously affect
throughput on the channel for all users. BPQ documentation says that
certain Kantronics TNCs using a special KISS EPROM are also equivalent
to BPQKISS. In a recent chat, a Kantronics representative said that
all Kantronics TNCs now had this special KISS as standard firmware. A
local JNOS user with a KPC-3 carried out tests that would appear to
confirm this. Can anyone else verify it?
If you do not need to transmit UI frames on the radio port, we
recommend that the BPQ switch be connected to a diode matrix and all
radio ports operated as X1J nodes using regular TNCs. Even when you
have only one radio port, it should be connected as a TheNET node with
a "NETROM" cable linking the serial port and NETROM protocol used in
the BPQ switch. Then the BPQ becomes simply a multi-connection
interface for the BBS or other application. We recommend using a
BPQ/RS-232 timeout timer to prevent matrix lockups should the computer
crash.
Public Parameters
5. It has long been NEDA policy that NEDA node parameters be open and
accessible to anyone for examination whenever possible. BPQ parameters
are normally totally hidden as an inaccessible file on the computer.
Putting the BPQCFG.TXT file in a public directory on an associated BBS
would meet this policy and would confirm that the BPQ switch was being
operated in a network compatable manner. The BPQCFG.TXT file should be
edited to remove John's explanatory notes so as to make it as short as
possible. A note in the INFOMSG could show the location of the file.
Controlling Access
6. Controlling access to the network ports of a BPQ switch is different
from a TheNET node. The VALIDCALLS parameter in the ax.25 port
definition section will limit those callsigns that can do L2 connects
to that port of the switch. It will not however distinguish between
SSIDs. It can also be used in much the same manner as the ACL function
of X1J but only for L2 connections.
Locking ROUTES and setting default port quality to 0 (a common network
management practice with TheNET nodes) will not work with BPQ. Setting
QUALITY to 0 disables the node broadcasts from that port AND it
ignores all incoming node broadcasts. Setting QUALITY to a low
non-zero value like 1, even if it is lower than MINQUAL (in Network
System Parameters) still results in the neighbor nodes being entered
in the node list. This is not documented but comes from my own
observations. The only way to prevent connects from uncontrolled
stations is to use the VALIDCALLS parameter mentioned above.
Port Quality Assignment
7. The QUALITY assigned to a BPQ port on a node stack can be quite
confusing so let me explain the rationale. The NEDA policy of
assigning a quality=203 to backbone ports is designed to limit the
node propagation to a maximum of 7 TNC hops (usually equivalent to
three visible node hops). This policy effectively limits the size of
the node list to a manageable length of less than 100.
BPQ has different hardware than a dedicated hardware TNC node. One BPQ
switch (containing 1 CPU) will do the job of 2 TNC nodes (containing 2
CPUs) on each path through the node stack. The quality "decrement"
through 2 TNCs is equivalent to a quality of 161 (203/256 x 203/256 =
161/256). So to have the BPQ reflect the same parameters as a TNC node
stack the Quality would have to be set to 161. However this only
affects node listings that pass through the BPQ from one port to
another. A user port is usually configured with QUALITY=50 (and no
nodes broadcasts) so that it will not propagate nodes heard on that
port and so this quality argument does not affect it. Therefore in a
BPQ switch that does not pass any node information from one port to
another, QUALITY=203 is appropriate (since it is functionally
equivalent to one TNC). If node information is propagated from one
port to another, then use QUALITY=161.
Another special case is a BPQ switch where all the ports are
interfaced to individual TheNET nodes. One purpose of such a "node
stack" would be to allow many more circuits (TheNET is generally
limited to 24) through a busy Hub node. In this special case, each
path contains three CPUs (one BPQ and two TNCs). We suggest that
QUALITY=228 on each end of all of the BPQ<>NETROM links would achieve
an overall quality = 161.
Whatever the QUALITY assigned to a network port, the quality on the
node or BPQ port at each end of a network link should be the same.
This will avoid "non-symmetrical" routes which show further in one
direction than the other and may not be connectable from the extreme
ends.
FRACK Settings
8. FRACK parameter settings in a BPQ switch are a dilemma. It is very
dependant on the port configuration and even on the data rate. We have
to examine the conditions on the radio channel, the average number of
users at peak times, the mode in which the TNC is operated, etc. An
extreme example is the effect of using a regular KISS mode TNC on a
congested radio channel. The computer has no way of knowing when the
TNC has been able to transmit the frame so it must start the FRACK
timing immediately after sending the frame to the TNC. The FRACK must
be set to a value equal to the sum of the average time delay in
transmitting the frame plus the length of the frame (2 seconds at 1200
bps) plus the normal NEDA FRACK for a radio port of that type. This
could result in a value as much as 20 seconds and you can imagine how
that would slow up the throughput on a congested channel where
collisions are frequent.
On the other extreme, a BPQ port feeding a NETROM node serial port or
a diode matrix, will not have any significant retries so the FRACK can
be set to 1 second. Other types of ports would naturally fall
somewhere in-between these extremes.
Added on top of this dilemma is a lack of knowledge on just how the
computer handles FRACK. This will require a series of appropriate
experiments before we can choose the suitable values for FRACK under
differing conditions. We already know how it handles FRACK in a
regular KISS mode TNC. What we need to know is the operating mode for
the following:
a/ TNCs operating BPQKISS with KISSOPTIONS=POLLED,CHECKSUM,ACKMODE.
b/ TNCs operating in DED HOST mode and G8BPQ HOST mode.
c/ Operation with internal HDLC cards like DRSI (may be
the same as /b ??).
d/ Anything I forgot???
Meanwhile until we can get results on some experiments, let's set
FRACK at 6 seconds (6000 milliseconds) on a quiet LAN user port and
dedicated links running KISS mode, 12 seconds on a busy LAN USER port
and 15 seconds on a "ZOO" channel. If you are running regular KISS
mode, please convert to BPQKISS which at least allows the computer to
monitor the outgoing transmit buffer. Better still if you can, convert
the TNC to a TheNET node and link the BPQ using NETROM protocol. (This
is not possible if running TPK or other UI frames on the radio port.)
The best situation would be to operate all ports in your facility as
TheNET nodes. Then use the BPQ switch linked to a diode matrix solely
as a multiconnect interface with an application like a BBS.
MAXFRAME
9. There is a considerable controversy over the proper value of MAXFRAME
in a network. NEDA has from an early period recommended MAXFRAME=1.
Others say that this is ridiculous, that MAXFRAME=1 is inefficient and
slows throughput on links. Unfortunately neither side can back up
their positions with clear, logical and experimentally proved
evidence. Let's examine the positions.
NEDA's policy is that all users have an equal opportunity to access
the available resources of the network. On a user port no- one should
have to wait a long time to get a frame transmitted or to receive a
frame from the node or server. This is achieved by setting L2
MAXFRAME=1 and setting appropriate persistence and slottime parameters
to allow opportunities for transmission to the node. At 1200 bps one
frame + TXD typically takes two seconds to send. Assuming say five
users on the channel, most of whom are receiving information from the
node or server, each user should not have to wait more than 10 seconds
per frame. If the MAXFRAME was set to 4 for example, some users might
have to wait as long as 30 seconds for their share. Not very fair.
Note: This MAXFRAME value only affects transmissions made by the node
or switch downlinking to the user. All uploaded frames are controlled
by the MAXFRAME parameter in the user's TNC.
The opponents to the MAXFRAME=1 would say that may be fine for 1200
bps ports but for 9600 bps ports, the value should be higher. After
discussing it at the last meeting, I proposed that for higher speed
ports, higher MAXFRAME values were appropriate so long as any one
transmission to a user did not exceed say 2 seconds. MAXFRAME=4 or
even =6 on 9600 bps user ports would meet this criteria. MAXFRAME=3
would be appropriate on a 4800 bps port.
MAXFRAME settings on the backbone links are another matter. NEDA has
again held that MAXFRAME=1 insures equal sharing of network resources
and has results of early experiments that supports the claim that the
overall throughput of the network is higher at MAXFRAME=1. Opponents
counter that this is the result of a large number of slow 1200 bps
links in our network and if we were to install all high speed links,
the NEDA claims would be proven wrong. At this point however, there is
no solid experimental evidence to prove either way. There is great
need to research this important matter. Meanwhile we continue to
recommend MAXFRAME=1 because we know it works and has no serious
detrimental effects on the network (like totally locking up).
It is my opinion that one of the most important factors in overall
network performance of TheNET networks is how "chokes" are handled and
the effect of chokes on network data flow. It was my impression (on
reading the original NETROM documentation) that if a NETROM L4 link
chokes due to one circuit being unable to deliver its data, then all
the circuits being handled on that L4 link are also stopped although
they may well have clear destinations that are not affected by the
choke. However, as a result of a recent "accidental" experiment, this
was proven not to be true, at least not for TheNET and NOS systems
(the "experiment" involved a circuit through more than 20 TheNET nodes
- both X1J and 2.0x types - ending in a JNOS converse node system).
Even though that one circuit was totally choked, other streams moved
through parts of the same path without hindrance. A similar experiment
involving a BPQ switch has yet to be run.
******************
Changes and added notes since may 95 meeting.
Response Time on NETROM Port
10. It has been noted that the response time is also active when linked to
a NET/ROM diode matrix. This is different from the serial port of a
NET/ROM:TheNET node where response time is ignored. A significant
response time on a BPQ port feeding a diode matrix has the effect of
greatly slowing communications on that port. Set RESPTIME=0 to
eliminate this slowing effect. Setting RESPTIME=0 does not seem to
have any detrimental effect but if you would feel better with non-zero
value such as 1 (millisecond), then do it.
Unconnected NETROM Ports
11. Unused ports, especially NETROM configured ports, should be commented
out or at least make sure the pull-up resistor is in place on the
serial connector. Several installations have had problems with the
switch locking up for no aparent reason. When the unused ports were
commented out, the lockups stopped. (Credit: W6GO report)
***************************************************
Call to Action
If you guys have any better ideas, let's hear them. Meanwhile all of
us that run BPQ can check out these above-mentioned parameters for
serious problems.
***********************
"Boy who goes to bed with sex problem wake up with solution in hand."
/---\____________
_ / /\_)___________) 73 de Henk.
()_____)
()_____)
--\___()____)
Pc :486Dlc/40MHz Tnc:AEA Pk-88 Trx:Bosch Kf-161 Ant:Dualband 2m/70cm
Dit station wordt NIET gesponsord door 'T for Telecom'!
Read previous mail | Read next mail
| |
