> - 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.
> - 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.
> - RRv (response without pool bit) is not sent if there is command to be
> sent (RR+ etc.)
Hmm. I think you're right here.
> - 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).
> - 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.
> - 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.
> - 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.
73,
Joerg Reuter http://poboxes.com/jreuter/
And I make my way to where the warm scent of soil fills the evening air.
Everything is waiting quietly out there.... (Anne Clark)
PGP signature
