Hi all!
> The solution seems to be the maxkeyup parameter in the
> /etc/z8530drv.conf
> file. After increasing the value from 7 to 15 all seems to work well.
At sk6sa we uses 30 and still have problems. Exactly when/why the problems
occure is hard to tell, sometimes we have to restart the computer
once a day, but other times it takes much longer, we have had the
computer running for 35 days without problems, so it is very hard
to see a trend here... :-)
> We
> are using a clean 2.0.36 kernel, ax25-utils-42a and z8530drv-2.4c utils
> without any patches or changes. The card is a PA0HZP opto SCC card (4
> ports).
We uses the same except the kernel, 2.0.33, with everything compiled in,
i.e. no modules.
> It seems that the problem only occurs on very busy hours. On that port
> we
> also send unproto beacons from Xfbb and no node (national regulations).
Is this the port that have the most traffic? We seem to have problems
with the ports not having that much traffic. But the problem seem to
show up when we have much traffic on another port. Xfbb sends data
on all ports on one of the computers, on the other one we do not
use Xfbb so the problem is not associated with Xfbb.
> Also the TX and RX buffer is set very high at 25 and the bufsize has a
We uses 16.
> value
> of 2048 bytes.
Bufsize is 384.
> Please correct me if I'm wrong, the value of maxkeyup is to prevent a
> long
> transmission time.
Yes.
> And when it must have a very high value to work,the
> maxkeyup parameter doesn't have any meaning.
It depends if you want to be channel hog or not :-)
Remember that a packet at 1k2 takes approximatly 1.8 sec to send.
If you uses a maxframe of 7 you may very well send continously for
12.6 sec. So 7 seem too low for a port using maxframe 7 (for tcp/ip-
traffic we may very well send for even longer periods.)
73 de Lars, sm6rpz
--
Lars E Pettersson | Chalmers University of Technology
[EMAIL PROTECTED] | Gothenburg, SWEDEN
