-
Notifications
You must be signed in to change notification settings - Fork 313
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Please add CHECK and RESPTIME #133
Comments
This is a more precise definition from AX.25 protocol spec version 2.0. 2.4.7.1.2 Response Delay Timer T2 The second timer, T2, may be implemented by the DXE to specify a maximum amount of delay to be introduced between the time an I frame is received, and the time the resulting response frame is sent. This delay may be introduced to allow a receiving DXE to wait a short period of time to determine if there is more than one frame being sent to it. If more frames are received, the DXE can acknowledge them at once (up to seven), rather than acknowledge each individual frame. The use of timer T2 is not mandatory, but is recommended to improve channel efficiency. It was removed from the v2.2 protocol spec because it is unnecessary and harmful. |
I'm probably the wrong person to answer that question, since I'm not an AX.25 expert. I have no idea why T2 is 'harmful'. I'm an emergency communications worker in Santa Clara County, California. The county uses AX.25 version 2.0, BBS servers and Outpost for message passing. I'm told experts have tested this system under load, and chosen AX.25 parameters that help prevent congestion, including RESPTIME 500 msec and CHECK 300 sec. Operators are strongly advised to set these parameters when communicating with the county. By the way, it seems like RESPTIME and T2 mean different things. RESPTIME is the minimum time to delay; T2 is the maximum time. |
Thanks for the feedback. The protocol spec has obscure names like T1, T2, N1, and k. TNC configurations have more mnemonic names. I've seen many references that indicate T2 is the same as RESPTIME. e.g. https://www.qsl.net/kx4z/UsingWindowsBPQ32.pdf (for BPQ32), http://linuxdocs.org/HOWTOs/AX25-HOWTO-5.html (AX.25 for Linux), http://buxcomm.com/pdfzips/node-parameters.pdf (The NET), http://vss.pl/mods.dk/mods.php3-radio=tnc&model=g3ruh&selectid=all.htm (G2RUH modem tuning), https://www.langelaar.net/projects/jnos2/archive/documents/manuals/JNOS2-MAN.doc (JNOS). RESPTIME of 0.5 seconds will end up sending an ACK for every "I" frame, rather than one for the last one in a transmission. |
I'm out of my depth here. Would you care to converse with the experts in my county? Perhaps you both might learn something. |
Here is a discussion of the various AX.25 timing parameters: |
Please enable configuration of AX.25 parameters like AGWPE's CHECK and RESPTIME. They're described in https://www.soundcardpacket.org/5traffic.aspx#Parameters . To recap:
CHECK: the amount of time (in seconds) to wait after hearing nothing from a 'connected' station before sending a 'check' ("are you still there?") frame.
RESPTIME: the minimum delay to wait after a clear channel before sending an acknowledgement packet. Increments of 100 milliseconds.
Parameters of these names in direwolf.conf would be good. Of course, please update the documentation to describe how to set these parameters and their default values.
I couldn't find these parameters in Direwolf version 1.4 or 1.5 Beta, running on Windows XP SP3.
The text was updated successfully, but these errors were encountered: