According to Julian =?ISO-8859-1?Q?Mu=F1oz?= =?ISO-8859-1?Q?Dom=EDnguez?=: While
burning my CPU.
>
> Hello Richard,
>
> >Firstly one would imagen a t_2 timer time of 1.5 seconds far to short for a
> >1k2 link.
>
> I am using this value long time with jnos, and that worked perfectly. It was
> enough to piggy-back and to concatenate acks. In fact, it seems not to be the
> problem, because if t2 expires it should be sent before the Information frames,
> not after.
1) Are you sure the value is the same as you used in JNOS. ?
>
> >Seconly it looks like you are using mode VC,
>
> Yes ! That's not an accident ! :-)
>
> >thirdly you have not set the "window" or "mss/mtu" correctly with the
> >available commands. that can be seen because you are experiencing packet
> >fragmenation, which is realy a bad thing on radio links.
>
> Yes. The ax25 paclen is set to fragment the 256 tcp/ip bytes pdus in 2
> ax25 fragments. 256 bytes packets are quite long at 1200 bauds, it's difficult
> to share the qrg... Having a paclen of 131 does more optimum the work of the
> link layer at this speed.
>
> I am near to be sure that I am doing nothing wrong... And there is more things
> in the behaviour of linux ax25 implementation that I don't understand, even
> "looking very much the sources"
I think you need to think again about what you just wrote, you are
experiencing "packet fragmentation" you say yourself its a busy qrg, now if
you recieve the first packet of the 2 which have been splitup by the remote
host, and you do not receive the second within x seconds then the first
packet will be discarded, that i think has a lot to do with "your" problem.
Futher more i cant agree about a small mss/mtu as i always used 256 MTU on a
1200 port, the qrg was busy, but busy or not 256 was proved to be beter for
all on the qrg, 1) less overhead more data, 2) less trx time consumed.
>
>
> --
> Saludos de Juli�n
> -.-
> >> Powered by KDE / Linux <<
>
--
Regards Richard.
[EMAIL PROTECTED]
