N.E.D.A.  - Devoted to Packet Neworking in the NorthEast


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:May, 1996

Compiled and edited by: Burt VE2BMQ


This document is a preformatted alternative to the NEDA Recommended BPQ Parms document using tables, intended for those who use web browsers that cannot handle tables. However all links from other documents will go to the tables version. If you link to other documents from here, you must use your browser "back" button to return to this document.

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
IDINTERVAL=0        We don't need IDs.
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
MAXNODES=100        Maximum known nodes in node 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.


PACLEN=236          MAX PACKET SIZE in bytes.  More would
                     fragment NET/ROM frames.


T3=320              LINK VALIDATION TIMER in seconds (5 MINS)
IDLETIME=7200       IDLE LINK SHUTDOWN TIMER in seconds (2 hrs)  


HIDENODES=1         # Nodes only listed with N * command


User LAN Port
Non-Ideal User Port (ZOO Channel)
Gateway Port
NETROM Matrix Port
BPQKISS Dedicated P-P Link Ports
Standard KISS Dedicated P-P Link Ports
KISS Shared Link Ports
User LAN Port
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.

      ID=NON-IDEAL USER PORT  This ID will show in response to Ports command.
                           Edit to show frequency or purpose of port.
      QUALITY=0            Inhibits node broadcasts and L3/L4 connects
                            on this port.
      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
      PACLEN=236           More would be subject to fragmentation by NETROM
      DIGIFLAG=0           Digipeat not commonly used today.

    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.

      ID=GATEWAY PORT      This ID will show in response to Ports command.
                           Edit to show frequency or purpose of port.
      QUALITY=50           Inhibits propagation of any received node.
      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           Depends on number of station on channel - 256/(N-1)
      FRACK=12000          Milliseconds- Adjust according to other
                            stations on port.(See note#8)
      RESPTIME=500         Milliseconds
      PACLEN=236           More would fragment in NETROM
      DIGIFLAG=0           Digipeat is not commonly used today
      MINQUAL=210          This effectively limits node broadcasts
                            (on the port directed towards the other
                            network) to this node information only.

    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).

      ID=NETROM CONNECTION   This ID will show in response to Ports command.
                           Edit to show frequency or purpose of port.
      QUALITY=203          Assumes no feedthru of node information form other 
                           BPQ ports (See note #7)
      MAXFRAME=1           (See note #9)
      FRACK=1000           Milliseconds. Not important-few retries.
      RESPTIME=0           Milliseconds (See note #10)
      PACLEN=236           More would fragment in NETROM
      FULLDUP=0/1          0 for diode matrix, 1 for connection to
                            a single NETROM/TheNET node RS232 port.
      DIGIFLAG=0           Digipeat is no longer commonly used.
      QUALADJUST=100       Equivalent to X1J Alternate Broadcast Algorithm
                            (See note #1)

    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.

      ID= DEDICATED POINT-TO-POINT PORT This ID will show in response to Ports
                            command. Edit to show frequency or purpose of port.
      PROTOCOL=KISS        Protocol type
      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. Se 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
      PACLEN=236           More would fragment in NETROM
      DIGIFLAG=0           Digipeat is not commonly used today
      KISSOPTIONS=POLLED,CHECKSUM,ACKMODE  Important for proper operation 
                            of BPQKISS port
      VALIDCALLS=<callsign1,callsign2,...>   Used instead of
                            locking ROUTES.  See note #6.

    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).

      ID= DEDICATED POINT-TO-POINT KISS PORT   This ID will show in response to
                            Ports command. Edit to show freq or purpose of port.
      PROTOCOL=KISS        Type of protocol
      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
      PACLEN=236           More would fragment in NETROM
      DIGIFLAG=0           Digipeat is not commonly used today
      VALIDCALLS=<callsign1,callsign2,...>  Used instead of
                            locked ROUTES. See note#6.

    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
      SLOTTIME=200         Milliseconds
      QUALADJUST=100       Enables equivalent to X1J alternate
                            broadcast algorithm. (See note #1).



    Disabling Node Broadcasts
    Limit Node Broadcasts to Node Itself
    UI Transmissions
    Public Parameters
    Controlling Access
    Port Quality Assignment
    FRACK Settings
    Response Time on NETROM Ports
    Unconnected NETROM Ports


    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:

        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.


    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 apparent 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.


    END of FILE

    Compare with the NEDA X1JR4 Recommended Node Parms.

    Back to the NEDA Home Page
    Accesses: 2
    Comments and suggestions regarding this web page should be addressed to the
    NEDA Web-Master
    Please identify which page you are referring to in your comments

    Copyright © 1996-1997 by North East Digital Association . See NEDA Home Page for conditions.
    html mark up by Dino, VE2DM and Burt, VE2BMQ rev 23/03/97
    Most graphics were created by Burt, VE2BMQ using CorelDraw 3 and Corel clipart
    NEDA Logo was created by Tadd, KA2DEW, redrawn by Dino, VE2DM for this WEB effort
    and is © NEDA, 1990-1997