On Mon, 7 Feb 2000, Robin Gilks wrote:
> On Mon, 07 Feb 2000, you wrote:
> > While playing around with hdlcdrv I came across two problems:
> >
> > Before arbitration was called by driver and when higher level decided to
> > transmit driver immediately keyed PTT. Now driver and DDI have separate
> > timers which results in DDI deciding to transmit BUT driver keying PTT
> > with some delay when driver gets its own interrupt.
> > In case of BayCom serial driver its interrupt is called in 10ms
> > intervals. So in the worst case we might have abt. 10ms delay before
> > actually keying PTT. I'm not sure how big issue that is but we are
> > needlesly increasing collision probability.
> > So question is how big issue that is .. (ie. whether we should implement
> > some downcall from hdlc to hw-driver to start TX)
> > I put some printk in ser12fdx driver to see how often that happens ..
>
> Does this mean that now each driver using hdlcdrv has to do its own
> arbitration? This seems like a backward move if this is the case.
Drivers need own interrupts not arbitration.
To be more exact. We definitely *should* add downcall from hdlc to its
drivers to immediately start TX.
BUT that requires quite good knowledge of respective drivers and their
function. Maybe their authors could add it.
Again this relies only to HDLC.
> > Second problem is what should driver do when it receives new data
> > while sending txtail. Since new ax25 is designed that driver just sends
> > what it gets from higher level it seems obvious it should send new data
> > and restart txtail. But shouldn't there be some flag so that does not
> > happen ?
>
> If its sending txtail then the transmission is complete - thats it. The new
> data has to wait!! At least thats what I think is relevant. Consider higher
> speed interfaces using this code and full duplex implementations as well before
> changing too much.
Problem is:
Driver is sending txtail but higher level decides to TX some more data.
There is no flag preventing that. It is unlikely to happen but it's
possible. This is all-drivers problem (not just hdlc).
> Have you by any chance done anything about the fact that the MTU is hard coded
> in hdlcdrv and hence full of potential lost packets for all the drivers that
> use it? See my ideas from 20th January in the "Can't get packet length over 338
> bytes when using SCC card." thread
I'll look at that ..
Jan
