From: PE1DNN@PE1DNN.PI8APD.#GLD.NLD.EU To : BPQ@WW T:From: pe1dnn@os.pe1dnn.ampr.org (Henk de Groot) T:Newsgroups: ampr.org.ww.bpq T:Message-Id: Op Sat, 19 Feb 2000 20:34:00 +0000, schreef w0rli@w0rli.or.usa.na: >> 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 KISS TNC: 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 in the 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 it directly 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 is only 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. -- ######################################################################### The difference between theory and practice in practice is bigger than the difference between theory and practice in theory. Henk de Groot | Apeldoorn, The Netherlands, JO22XF PE1DNN@PI8APD.#GLD.NLD.EU | NOKIA-ATF2, YAM Modem, Linux RedHat 5.2