On Wed, 9 Feb 2000, Joerg Reuter DL1BKE wrote:
> > - removed arbitration stuff from hdlcdrv.c & dependent drivers,
> > removed slottime+persistence, removed some (very old) kernel version
> > checks
> > removed kernel stuff from linux/include/linux/hdlcdrv.h, put it in
> > drivers/net/hamradio/hdlcdrv.h
>
> Sounds good, but please ask Tom if it is okay.
So .. Tom .. is it okay ? :)
(ie. it works, is cleaner, etc.)
> > - initial value for persistence set to 32, 1 is too low
>
> Apparently it was good for the 76k8 LAP in Darmstadt -- that leads
> directly to the main problem of using heuristics to set parameters:
> how do I prove that they are right in every situation? Of course
> you could include a way to set the parameters of the algorithm, but
> this is contrary to the goal of an adaptive scheme: no user interaction
> required to work.
>
> How about providing the data needed for the calculation through the
> netlink device and let a user space daemon do the calculation? Set
> reasonable default values so that everything still works w/o the
> daemon running. In my opinion it's worth the extra work. We'll
> need a way to disable the adaptive mode anyway as it isn't apropriate
> for every case.
Initial value for persistence is used only after initializing interface.
It should automagically adapt itself after some time. But that is quite
slow. (ie. transmitting required .. maybe it could be modified to adjust
itself even when we don't want to TX)
And I think adaptive scheme could be adjusted to work well under 99%
situations (ie. FlexNet) .. but some way to manually adjust it could be
fine .. (via /proc or ioctl .. perhaps)
> > - retransmission of I+ instead of sending RR+ only for packets shorter
> > than 40B. Maybe we could increase this value, but not blindly resend
> > 255B packets.
>
> Why not? On one hand, you avoid some transmition time if the connection
> is failing beyond recovery, on the other hand we often have the situation
> that small packets get through but not large ones. It will then get through
> RR+/RR-/I^ cycles -- and timing out much later with more transmission
> time used. I am pretty sure it buys you nothing (it looks nicer in the
> trace, though).
I'm more concerned about other users on the channel .. but this thing
needs to be experimented with ..
> > - ax25_check_iframes_acked restarts (t1/t3) timer at any case
> > we should restart timers when we get new packet ..
>
> This is a frame collector issue, right? Please think it over _very_
> carefully if your patch is correct, I have the feeling that the
> current behaviour is correct.
We have received new packet, if there is nothing unacked we should restart
T3 since we know our partner is there. If there is something to be acked
we should restart T1 since there may be some packet after it with correct
number.
And that has nothing to do with frame collector.
> > - when we send DISC+ and get UA or DM socket is now closed immediately,
> > there is no need to keep it (I consider that a bug)
>
> Uh, I _know_ there was a reason why it is that way -- I think it has
> something to do with the fact the whole thing is running in NET_BH
> and this has to wait for the next NET_BH run to work correctly.
> Alan, Jonathan?
>
> Please be _extremely_ careful if you touch this behaviour, otherwise
> weird things will happen.
Weird things happen without that. Disconnected socket is kept until T3
expires which is _very_ annoying especially while testing anything
(combined with strange link-reset which happens when you try to connect
again. I think closing immediately is the right behaviour.)
Socket is closed by setting killtimer=0 .. it is really closed bit later.
> > - when we get RR- in state 4 tx_cmd is cleared, that solves problem when
> > T1 expires before RR- is received but due to persistence etc. RR+ is
> > sent after we got RR-, caused snowball effect with too low T1
>
> Ouch. Okay, but be careful that this doesn't lead to starving connections
> in return.
>
> > - changed T1 calculation. It was too low on 1200bd links. I think timers
> > still need adjusting.
>
> Another reason why this really should be done by a user space daemon.
I've got some thoughs about whole AX25 should be done in userspace .. but
now we would throw away almost everything what has been done ..
Userspace AX25 would have many advantages .. portability not being
smallest of them.
Bye
Jan
