home *** CD-ROM | disk | FTP | other *** search
/ The Datafile PD-CD 5 / DATAFILE_PDCD5.iso / utilities / c / comlink / Manual / General / TNC_Params < prev   
Encoding:
Text File  |  1993-01-23  |  8.1 KB  |  160 lines
  1. TNC PARAMETERS
  2. --------------
  3.  
  4. (With acknowledgements to G8TIC, G0RLG and others, who first sent out this
  5. information)
  6.  
  7. It has been recognized for some time now, that the default parameter
  8. settings in virtually all TNCs are far from optimum. I have been using a
  9. different set of parameters for over a year now, and I find that it gives a
  10. significant improvement.
  11.  
  12. The first impression is that the TNC has gone to sleep, as it seems to wait
  13. long periods without doing anything. Normally, the old PTT lamp is flashing
  14. away merrily, and the TNC is obviously busy doing something useful, right?
  15. WRONG! A great deal of its activity is completely wasted, and only serves to
  16. clog up the frequency. Also, you are liable to frequent disconnection due to
  17. the TNC being too 'impatient'.
  18.  
  19. I can draw two crude parallels, which might serve to get the message across.
  20. Have you ever been in a queue, when people start pushing from the back? The
  21. whole queue gets squashed into a smaller length, so those towards the back
  22. move forward some considerable distance, and therefore feel that they are
  23. making useful progress. In fact, the queue still has the same number of
  24. people in it, and the crushing and jamming at the front will make the queue
  25. move more slowly once the gates/doors etc. are finally opened. Ie it was
  26. completely useless activity, just like on packet.
  27.  
  28. Also, imagine talking on a trans-Atlantic satellite phone link to someone,
  29. so that there is a slight delay. An impatient person will expect an instant
  30. reply to a question, and so will not give the other person a chance to reply
  31. (remember the delay) before 'polling'  eg saying something like "hello, can
  32. you still hear me"? In all probability, the other person will start speaking
  33. at that moment, and you have a 'collision'. If this goes on long enough, the
  34. impatient person may get frustrated and hang up  ie disconnect.
  35.  
  36. So, I have found that although the TNC seems more 'lazy', far fewer of its
  37. transmissions are wasted ie the 'hit' rate is higher. Also, because it is
  38. more patient, I almost never get disconnected from the mailbox due to
  39. exceeding the retry count, even when things are very busy indeed. Traffic
  40. slows right down as the channel gets very busy at peak times, but at least
  41. the link holds slow but sure! At quiet periods I can download stuff from
  42. my local BBS just as fast as ever.
  43.  
  44. If more and more users change their parameters, (and mail forwarding is kept
  45. off user access freqs like 144.650, 432.675 and 433.675 MHz), the situation
  46. would improve dramatically. Sure, there will always be antisocial 'hogs' on
  47. packet, but then you find the same type on HF, flattening all the opposition
  48. in an attempt to work the DX. The same type of person pushes into queues
  49. too! That is no reason for the majority to follow their example, and so I
  50. have avoided all temptation to change my TNC parameter settings back.
  51.  
  52. OK, enough of the hard sell, here are the changes to make. Don't worry if
  53. you don't understand the explanations; they are there for interest only.
  54.  
  55.  
  56.  
  57. >> MAXframe 2
  58. A packet sent over the air is made of separate frames, each one complete in
  59. itself and containing information, (eg text). You can think of it as a train
  60. with several carriages, each one carrying passengers. In the case of a
  61. 'live' user, a frame is generally one line of text, as each frame normally
  62. ends when RETURN (CR) is pressed, unless you're one of these people who
  63. forgets!
  64.  
  65. By limiting the TNC to 2 frames per packet, it will ensure that even though
  66. you might have typed, (or uploaded off disc), many lines of text ahead of
  67. what has actually been sent, the TNC will never try to send more than 2 at a
  68. time. Short packets stand more chance of getting through without umpteen
  69. retries etc..
  70.  
  71. >> Paclen 80
  72. This defines the maximum length of an individual packet frame, not the
  73. entire packet. The setting is rather academic, as in normal use a RETURN
  74. will terminate the frame before Paclen is reached. However, in case you tend
  75. to forget to press RETURN, or if you have a PMS facility, it is advisable to
  76. reduce the setting from the default 128. Do not exceed 128, as some PMSs
  77. have software bugs that will cause corruption of forwarded messages!
  78.  
  79. >> FRack 7   (ie 7 seconds)
  80. After a TNC has sent a packet, it waits a certain time for a response. If no
  81. acknowledgement is forthcoming within that time, it will 'poll' the other
  82. station to check if the link is still good. The default time of 2 or 3
  83. seconds is far too short on a busy frequency, as the BBS or Node may have to
  84. wait 5 seconds or more for the channel to go quiet, before it gets a chance
  85. to acknowledge. Meanwhile, your TNC keeps polling impatiently, thus
  86. increasing the channel congestion, and risking disconnection due to
  87. exceeding the retry count.
  88.  
  89. FRack 7 is a much more suitable setting, and even though it may appear to
  90. make the TNC very lethargic, it is much more efficient. This is the single
  91. biggest improvement you can make to the network!!
  92.  
  93. BAYCOM uses 100ms units for the FRACK timer, so you should set it to 70
  94. rather than 7. According to the v1.5 manual, the FRACK setting should adjust
  95. during connection, but it is wise to have a sensible value right from the
  96. start.
  97.  
  98. >> RESptime 30   (ie 3 seconds) This is a figure used by the TNC to calculate
  99. the delay before sending an acknowledgement to a packet  ie it is the
  100. opposite to FRack. The default setting is very antisocial, and causes the
  101. collision of a very high percentage of packets. By increasing the setting to
  102. 3 seconds, you will not notice any change, but you will be helping a lot.
  103.  
  104. >> PPersist ON   (note the double 'P')
  105. Many TNCs have two sets of timing parameters, and the newer ones are more
  106. effective than the old ones. Therefore, by setting this ON you will enable
  107. the new ones. Don't worry if you get an error message in response to this
  108. command, eg Eh? or ?unknown command.
  109.  
  110. >> PErsist 38   (only one 'P' this time)
  111. This is a figure used by the TNC to determine how much it tends to 'grab'
  112. the frequency. Ideally it is 256 divided by the number of users on the
  113. channel; perhaps around 25. However, due to a bug in some TNC firmware, the
  114. lowest you can use reliably is 38. Using a high figure is very antisocial,
  115. so please don't!
  116.  
  117. If your TNC gives an error message in response to this command, then it is
  118. using old firmware. In that case, you need to enter an appropriate DWait
  119. setting  see below.
  120.  
  121. >> DWait 0   (or 16 on older firmware)
  122. Having set Persist 38, you should set DWait 0 in order to complete the
  123. enabling of PPersist. Some TNCs do not accept the PPersist ON command, but
  124. do accept the PErsist 38 command. In this case, setting DWAIT 0 auto-
  125. matically sets PPersist ON.
  126.  
  127. If you have older firmware that does not accept the PErsist 38 command, DO
  128. NOT SET DWait TO ZERO!!! Set DWait 16 instead, otherwise your TNC will try
  129. and hog the frequency all to itself, and you won't be at all popular!
  130.  
  131. >> SLottime 10   (or 100 with BPQ code) This is a timer value, used in
  132. conjunction with Persist. The 'standard' value used is 100ms, ie SLottime 10
  133. with most firmware, but 100 with BPQ due to different units. Some newer AEA
  134. firmware has a default of 30 for some strange reason. Older firmware will not
  135. recognize this command.
  136.  
  137. >> TXdelay 23   (or as needed)
  138. This is the delay between the transmitter being keyed up, via the PTT line,
  139. and any actual useful data being sent. This is to give the TX circuits time
  140. to settle down, and for the squelch in the receiving station's RX to open.
  141. Most modern rigs can manage with typically 20 to 25, so try 23 as a starting
  142. figure. Even the oldest and most relay-filled rig shouldn't need more than
  143. 50! Using less than 20 might prevent the other stations' squelches opening
  144. in time, even though 15 is theoretically possible on many rigs.
  145.  
  146. SUMMARY
  147. -------
  148. MAXframe  2
  149. Paclen   80
  150. FRack     7   (70 in the case of BAYCOM)          ie   7 seconds
  151. RESptime 30                                       ie   3 seconds
  152. PPersist ON   (may not work on some TNCs)
  153. PErsist  38   (may not work on some TNCs)
  154. DWait     0   (16 if PErsist 38 doesn't work)
  155. SLottime 10   (may not work on some TNCs)         ie 100 millseconds
  156. TXDelay  23   (or as needed)
  157.  
  158. Go on give them a whirl! Think of the warm glow of smug satisfaction that
  159. you will feel, by being so virtuous, hi hi.  73...
  160.