G8BPQ PACKET SWITCH

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  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.
  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           More would be subject to fragmentation by NETROM
  DIGIFLAG=0           Digipeat not commonly used today.
ENDPORT

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      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
  RETRIES=10
  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.
ENDPORT

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   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)
  RETRIES=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)
ENDPORT

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)

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 This ID will show in response to Ports
                        command. Edit to show frequency or purpose of port.
  TYPE=ASYNC
  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
  RETRIES=10
  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.
ENDPORT

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   This ID will show in response to
                        Ports command. Edit to show freq or purpose of port.
  TYPE=ASYNC
  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
  RETRIES=10
  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.
ENDPORT

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

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 apparent reason. When the unused ports were commented out, the lockups stopped. (Credit: W6GO report)
    
    

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.

Compare with the NEDA X1JR4 Recommended Node Parms.

Back to the NEDA Home Page