[irda-users] Re: F-timer question

[Martin D. <li...@md...>]

On Mon, 17 Nov 2003, Jean Tourrilhes wrote:

> 	Ok, I got it. Yes, I think that could explain some perf
> anomaly I've seen with irtty. Nice catch !
> 
> 	A bit more info :
> 	1) The network layer will always buffer frames between the
> IrDA stack and the IrDA driver. If you check ifconfig, you will see
> txqueuelen:8.
> 	2) So, even if the driver accept frames one at a time, the
> entire window will be buffered in there.

Right. I was first thinking about netif_stop_queue should avoid this 
issue, but it became clear it can't.

> 	3) Therefore the IrDA stack "send" the pf=1 frame *always* at
> the beggining of the window (plus processing time).

I think so, yes. What if there's not enough data waiting to fill the 
window? Am I right with your latency improvements we are turning the line 
then instead of waiting in case more data arrives?

> 	Now for a simple solution...
> 	1) We need to leave max-turn-around to the secondary to
> answer, but from the time we send the last bit of the pf=1 packet.

Yes.

> 	2) Because we know which frames compose our window (we sent
> them), and we know the bitrate, we could calculate fairly accurately
> at which time is the last bit of the pf=1 packet.

What about the escapes? Sending 3000 bytes at 115.2kbps usually takes 
about 260 msec. Depending on transparency-escapes it might take up to 
twice that long! I.e. we'd need to now the length of the wrapped frames in 
irlap. For MIR this means calculate the effect of HDLC bit-stuffing.

> 	3) Therefore, we don't need any new driver API ;-)

This would be very good of course. Meanwhile I've also learnt it's not a 
good idea to use a scheme where the driver is responsible for directly 
calling irlap_start_final_timer in this situation: it's racing with irlap 
in case there is a fast rr:rsp (pf=1) response which might be seen by 
irlap before the driver managed to start the timer after transmitting the 
previuos frame. Then we'd start the timer after irlap thinks it has 
already stopped it...

> 	4) So, all we have to do is to set the F-timer to :
> 	irlap_start_final_timer(self, self->final_timeout + transmission_time);

Yes - given we now what the remaining transmission time is from the moment 
when we start the timer.

> 	5) However, in the worst case, our transmission time has to be
> lower than the max-turn-around time. Because we want to be safe rather
> than fast, we could always assume that we are filling our Tx
> window. So, all we need to do :
> 	irlap_start_final_timer(self, self->final_timeout * 2);

Sounds good. But wait, besides this one in irlap_frame.c there are 17 
other places in irlap_event.c where we start the final timer. Can we leave 
them all unchanged? Are we sure the F-timer is always started at the 
beginning of our tx-window?

> 	6) However, you still need to make sure that you are dealing
> with L1 and L2 properly, so you need to divide them by 2 to account
> for the slower timer.
> 	7) In fact, at this point the final_timer is processed exactly
> like the wd_timer, which make things easier to understand.

Well, I was thinking the secondary might have the same issue with the 
WD-timer - haven't checked yet.

> 	8) Don't forget the comment this code, it's not obvious ;-)
> 
> 	What do you think of that ?

Well, I'm far from understanding the subtle details of the stack. So I'm 
just believe what you are saying. If it's really that simple I might try 
something later (after dongles...). For most drivers it's only a 
performance issue. I've never looked deeper into this until it triggered 
the fifo-lockup with the stir. But even there it seems it can be avoided 
by limiting the window size=1.

Martin