>
>That's interesting. I have no idea how TX underruns (an error condition
>signaled by the Z8530 itself) could have anything to do with (de)queueing
>of buffers. It may, however, trigger another problem. The kernel AX.25
>does not recover from the retransmission state (i.e. when one or more
>frames were lost) under a special condition. Jean-Paul has a fix for
>this problem, I believe.
Hi Joerg,
while I didnt ever investigate the reason fully, the max keyup problem
seemed to be under heavy load. I'd calculated my window size, paclen and
baud rate to give an estimate of this period. However, once I increased the
value (and I dont think there is any drawback to doing so?) substantially,
my error rate plummetted.
What was disconcerting though was that once the driver aborted the
transmission, the far end took the (incomplete) frame and accepted it as
valid (always!). I dont know why an FCS error didnt occur, but a third
station doing a "listen" on the channel definately also saw the aborted
frame as a valid (but shortened!) ax25 frame.
As far as dequeing goes, the code comments indicate that the earliest used
buffer gets dropped. I was seeing buffer exhaustion (on my busy channel)
regularly. I didnt make the new number as high as Arjan did though!
(Check your transmitter for heat problems if
>you can reproduce this behaviour, it only occurs when the other DXE
>constantly cannot decode the last frame(s) of your transmission window).
>
As I mentioned, this problem occurred on a very busy channel, with lots of
hidden transmitters. I was probably just getting overpowered by other
stations! With the above config changes, the SCC works extremely well, and
I am very happy with the driver. I think Joerg has done an excellent job
with it.
73
Steve, vk5asf