| |
EU50FR > BPQ 03.09.00 09:41l 184 Lines 9192 Bytes #999 (0) @ WW
BID : 31721CB
Read: DG4MFN GUEST
Subj: Re: Solution to BPQ32
Path: DB0AAB<DB0ZKA<DB0ABH<DB0RGB<OE5XBL<OE3XSR<OK0PBX<OK0PRG<OK0POK<9A0YRB<
PP5BLU<KA6EYH<HR2PAQ<IK1ZNW<GB7CRV<EA7URC<PE1NMB<PI8RWD<PI8BLK<PD0RXP<
HF1BBS<SK1BBS<NL3IPR<NL3ONB<NL3ONB<NL3ONB<IT5TNT<GA3DHG<RT0BBS<DBO274<
MK5BBS<FRA435<FRA229
Sent: 000822/1744Z 31721@FRA229..FBRE.FRA.EU [Quimper] FBB7.00g $:31721CB
From: EU50FR@FRA229..FBRE.FRA.EU
To : BPQ@WW
>> I think you don't run DAMA. For DAMA the protocol-stack wants to exactly
>> time the moment a poll-frame is send out. It should not be delayed at all.
>> This is a problem if there is a box between the protocol-stack and the
>> phyical radio with a mind of its own.
>
>This is *exactly* what KISS can provide.
>
>KISS will send a "frame sent" response to the host *exactly* when
>the frame is actually transmitted. i.e. when PTT is asserted. This is
>exactly the same thing 6PACK does.
>
No! You don't seem to understand DAMA. The proto stack sends polls to each
connected station in turn. As soon as the protocol stack decides to send
a poll it has to be transmitted with *no delay*. The reason is that if an
answer does not come back immediately the next station will be polled. So
this is what happens with your KISSTNC:
First when the KISS TNC sends without delay:
DAMA node KISS 6PACK Station1 Station2
| | | | |
|-DAMA-POLL->| | | |
| |--------DAMA-POLL------->| |
|<---DATA----|<----------DATA----------| |
|<---DATA----|<----------DATA----------| |
|--------DAMA-POLL------->| | |
| | |--------DAMA-POLL------->|
|<----------DATA----------|<----------DATA----------|
|<----------DATA----------|<----------DATA----------|
|-DAMA-POLL->| | | |
| |--------DAMA-POLL------->| |
|<---DATA----|<----------DATA----------| |
|<---DATA----|<----------DATA----------| |
|--------DAMA-POLL------->| | |
| | |--------DAMA-POLL------->|
|<----------DATA----------|<----------DATA----------|
|<----------DATA----------|<----------DATA----------|
| | | | |
This is the way DAMA is supposed to work (the DATA reaction on the POLL
shall be send in one continues transmission). Now what can happen if the
KISS TNC thinks it can decide on its own when to transmit and delays
the DAMA-POLL:
DAMA node KISS 6PACK Station1 Station2
| | | | |
|-DAMA-POLL->| | | |
| | | | |
| | | | |
| | | | |
| |--------DAMA-POLL------->| |
***>|--------DAMA-POLL------->| | |
| | |--------DAMA-POLL------->|
| | X---------DATA----------| |
| | | X---------DATA----------|
| | X---------DATA----------| |
| | | X---------DATA----------|
| | | | |
(data collides due to 2 stations transmitting at the same time)
***> The node does not receive data from Station1 and decides to POLL
the next station in the POLL sequence.
You see now? Because your wonderfull KISS TNC is delaying the DAMA-POLL
both Station1 and Station2 are orderd to transmit immediately. DAMA
slaves shall start their transmission immediately at a POLL (required by
DAMA).
Okay, and now what can happen if Station1 uses a KISS TNC:
DAMA node 6PACK 6PACK Station1 Station2
| | | | |
|-DAMA-POLL->| | | |
| |--------DAMA-POLL------->| |
| | | | |
| | | | |
|--------DAMA-POLL------->| | |
| | |--------DAMA-POLL------->|
| | X---------DATA----------| |
| | | X---------DATA----------|
| | X---------DATA----------| |
| | | X---------DATA----------|
| | | | |
(data collides due to 2 stations transmitting at the same time)
Now Station1 got the POLL but it's KISS TNC decided to send the DATA back
later. This is a clear violation of the DAMA protocol.
>Again, you seem not to understand what KISS can do. It can send a
>"frame sent" response to the host, which identifies which frame *just
>began transmission*. It is up to the host, of course, to do the appropriate
>exact timing calculations to take account of ISR latency, etc. etc.
>But that needs to be done for *any* TNC / host protocol, which obvious
>fact is pointed out inthe 6PACK documentation.
Yes I know. But what if the protocol-stack wants to manage the timing. Neat
that KISS tells the protocol stack when it started the message but that
puts the protocolstack out of control. Thats the whole point. KISS is
managing the radio and not the protocol-stack. Anything smart in the
protocol-stack does not help as long as KISS is inbetween. Channel
control is done by KISS and will not get smarter as what KISS can do.
KISS Radio will stay KISS, whatever you try to accieve in the protocol
stack to manange the channel-load.
>There is no advantage to 6PACK over KISS here.
>Both must send the "frame sent" indication to the host, with the
>possible small jitter due to uncertain ISR latency in either case.
The difference is that 6PACK sends when the protocol stack orders it
to do so, KISS transmists whenever the KISS firmware thinks it is any
good. As you may have noticed now this is particulairy important
when you try to use DAMA. DAMA is not a balanced protocol but is
Master/Slave where the slave is only sending when told by the master.
If the master contains a KISS modem then the POLLS can get delayed. Yes,
the master could wait until KISS reports that the POLL was transmitted,
but that is a waste of time. KISS should send itdirectly when told. Now
what about other activity on the channel (with other baudrates)? FlexNet
handles that in the protocol stack. But KISS does not give this DCD
information to the protocol stack, so how can the protocol stack know
when it is save to start a transmission?
Now you could say that the KISS TNC handles this, but the protocol
stack needs to know for its algorithms how busy the QRG is, also with
DATA on another baudrate which the KISS TNC does not decode but is still
there. Giving DCD information to the protocol stack also enables
detection of too long TXDELAYs of users. The FlexNet drivers measure
the time between DCD and the reception of the first byte of the frame
(of course not feasible for all drivers). With KISS this will not be
possible due to lack of data by the protocol stack.
>The entire advantage of FlexNet with respect to this issue comes from
>two causes: 1) FlexNet appears to actually make use of the "frame sent"
>information, where *most* other software does not; 2) FlexNet appears
Well, in FlexNet a frame is send when it was given to the MAC layer, so
it does not need "frame send" information, as soon as the protocol stack
puts it onto the MAC layer it is considered send (only the delay to
serialize the data, which can be calculated).
>to do a fairly reasonable job of automatically adjusting network timing
>parameters. Other software exists which does both these things,
>but is perhaps not in wide use yet.
As long as KISS is managing the channel it is KISS behaviour you get. You
cannot realy make it any smarter.
A dirty hack used in TFPCX is to set the KISS modem to DUPLEX when using
DAMA. This will make the KISS modem to immediatly transmit frames when
asked. But then you lost all DCD control so be sure that there isonly
DAMA traffic and nothing else because it will not be respected anymore.
TFPCX is only a slave and not a master; in DAMA the master cares about
the channel and DCD (this is because the master receives all the stations
in the area - the slave does not due to the hidden transmitter problem).
So this setup seems to be acceptable for TFPCX with KISS, but definately
not for a DAMA-node!
I hope you understand the KISS problem with DAMA now. I understand the
feedback at transmission time from the KISS modem. As far as I've seen
I have not seen it used in TFPCX - but I did not realy look into that
part of the code I must confess. It seems to solve some of the issues,
that is, if this is employed in every KISS TNC. Thanks for this info
anyhow, it is much appriciated (realy, I like this kind of info). I
hope you also gained something from my message too.
Kind regards,
Henk.
--
73's
e-mail : cb@fairesuivre.fr
Message writed on 22-Aou 2000 at 18:44.
Read previous mail | Read next mail
| |
