OpenBCM V1.13 (Linux)

Packet Radio Mailbox

DB0FHN

[JN59NK Nuernberg]

 Login: GUEST





  
W0RLI  > BPQ      20.02.00 20:58l 61 Lines 2369 Bytes #-9731 (0) @ WW
BID : 1803CW0RLI
Read: GUEST
Subj: Re: Solution to BPQ32
Path: DB0AAB<DB0SL<DB0RGB<OK0PPL<OK0POK<9A0YRB<HI8GN<WU3V<VE7KIT<VE7VBS<
      VE7DIE<N7WE<KB7CNN<WA7SJN<N7YSS<K7IQI<W0RLI
Sent: 000219/2034 @:W0RLI.OR.USA.NA #:5188

<pe1dnn@pe1dnn.pi8apd.#gld.nld.eu> wrote in message news:s4f5qfpe1dnn...


> Hello Hank,
>
> Op Fri, 18 Feb 2000 00:33:00 +0000, schreef w0rli@w0rli.or.usa.na:
> >They keep claiming "it does not work", and refuse to provide any
> >proof. Since it *does* work, right here at this station, I conclude
> >that folks who say "it does not work" are either ignorant or stupid.
>
> 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.

> If you want to make the response-timer and frack-timer as tight as possible
> without making redundant transmissions then you need to be realy good to
> measure round-trip times. When the protocol stack sends an I frame but
> the KISS TNC keeps it for some reason (DCD) then you get jitter in the
> timing

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.

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 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
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.

(Remainder of discussion deleted, it was based on a false premise.)

A lot of folks will continue to argue from this same state of ignorance
about the KISS TNC / host protocol.

Oh well ...

--

   ...  Hank

http://horedson.home.att.net





Read previous mail | Read next mail


 13.10.2026 11:09:02lGo back Go up