to the timing issues, let me show an example why some hardware TNCs do not fit
the IP networking scenarios discussed in this thread.
The maximal TXDelay of TNC-Pi is only 255 per pitnc_setparams utility.
The value is calculated by 256-modulo addition. For example, if you do
"pitnc_setparams 1 0 1 256", it will be 0; 257 equals 1,
etc. And the time unit is milli-second (as the Slottime field
explicitly says "in 10 mS", but TXDelay field doesn't say so, also the
empirical sense of time confirms it is in mS, not in 10 mS).
A separated TNC with maximal 255ms TNC-TXDelay can hardly cope with the
transmission delay (which is also called TX delay in many contexts, but it
refers to frame-length-in-bits divided by transmission rate, not the TXDelay
used in TNC) of a 90-byte ping packet over a 1200bps channel. Obviously
it is designed for uni-directional transmission without expecting the coming
back ACK/response traffic. The transmission sequence of a 90-byte
packet is at least 720 bits long (without counting overheads like the frame
header and physical sync sequence), and the corresponding transmission delay on
a 1200bps channel is at least 600ms. This implies that, when
the ping response comes back at the ping requester/sender side radio, it will
incur 600ms delay to keep the sender radio in receiving mode. But
the sender side TNC's waiting time is less than 256ms. At 256ms timeout
or later, any frame in the MAC queue could be sent to the radio and collide
with the receiving ping response.
Then I have to switch to software TNC so that it is possible to use larger TNC
TXDelay (TNC TX waiting time). In order to cope
with VOX delay, the transmission delay in the above example is increased from
600ms to 1000ms, then still no coming back traffic as the IP protocol stack is
upset by this long latency (i can see from wireshark the ping request is
successfully received, but no ping response is firing back). To make the
thing worse, lots of the timeouts in the TCP/IP protocol stack is not
adjustable at user level, you have to modify the kernel source code and rebuild
the kernel to update the value, and the updated value is not guaranteed to
work. Well, you do the math.
Finally by using hardwired PTT to get rid of VOX, I figured out a TNC TXDelay
around 750ms will get the job done with near optimal result. The
TCP (by wget or ftp) goodput can be as large as 140 byte-per-second (1120bps)
over the 1200bps AFSK channel. If the extra delay caused by VOX is added back
by DCD, I expect that things go back to the case described in the previous
However, if the DCD/CS delay is only a few milli-seconds, like what happens in
802.11 or some DMR radios, then it will be a different story.
James Kong, KM6JNN