| |
PE1DNN > BPQ 19.02.00 14:57l 109 Lines 5517 Bytes #-9732 (0) @ WW
BID : S4F5QFPE1DNN
Read: GUEST
Subj: Re: Solution to BPQ32
Path: DB0AAB<DB0SL<DB0RGB<DB0MAK<DB0BOX<DB0ABH<DB0SRS<DB0AIS<DB0ME<DB0QS<
DB0PKE<DB0ACH<PI8JOP<PI8ZAA<PI8GCB<PI8DAZ<PI8APD<PE1DNN
Sent: 000218/2313Z @:PE1DNN.PI8APD.#GLD.NLD.EU #:19986 [Apeldoorn] $:S4F5QFPE1D
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: <slrn8arkeo.1dd.pe1dnn@os.pe1dnn.ampr.org>
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.
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. Also the protocol stack cannot take DCD into account when sending
data to the KISS TNC since the DCD status is not known in the protocol stack.
That means that the protocol stack is not sure when his I frame will be realy
transmitted. That means that the response-timer has to have a bigger value
than the optimal value to avoid redundant transmissions of RR+ polls.
So to addapt the response-timer to the most optimal value the protocol-
stack needs:
* Actual DCD status on the medium (radio) with minimum delay
* When the protocol stack wants to send an I frame it should be done so
without delay.
You say that your KISS TNC will send the data within 2 ms. But that cannot
be true if DCD is set, than you have delays in seconds at 1200 baud! Or do
you work with your KISS TNC in full-duplex (and thus ignoring DCD). That
cannot be used on half-duplex links!
I think the lack of DCD and the time between sending of the I frame by the
protocol stack and the real transmission (DCD could have changed in the
meantime, delaying the packet!) is the problem for an adaptive system that
tries to figure out the most optimal value. With the conditions with KISS
you need redundant time in the response-timer to accomodate for extra delay
and to avoid transmission of RR+ packets when the I frame is being held in
the KISS TNC because of DCD. It is worth noting that this problem does
not exist on a point-to-point link with no interfearring stations.
>Same way you keep claiming "FlexNet is better" but provide no
>evidence. The evidence I have seen shows that FlexNet is WORSE
>than NET/ROM, by up to a factor of TWO in throughput. So I
>don't use it, since NET/ROM is better.
Did you test on a busy frequency with many stations or just point-to-point?
I think NET/ROM is used on point-to-point connections, true? If you understood
what I wrote than you are aware of the impact your test-setup has.
Measurements can be manipulated any way you want to. If you have only
point to point connections with known stations than having adaptive
parameters is rather pointless. So maybe FlexNet does not perform in
your environment.
FlexNet has to learn by measurement what the optimal values are. This is
benneficial if the parameters are not known at forehand, i.e. when
connecting to many different stations. The problem of not knowing the DCD
status in the protocol stack is only a problem on a shared QRG.
I hope this makes it clear to you what the technical problem with KISS is.
If these problems bother you depends on your environment. If you can
live with more sloppy response-timers than fine.
A related note is the use of the poll-bit on the last I frame of a
transmission. That may speed-up the transmission and then you are not
depending on the response-timer setting. But the nasty effect of this on
a shared link is that transmission is so thight that other can not
'break-in'. When this happens with FlexNet (which does not have a poll
bit on the last I frame transmission), FlexNet addapts the response-timer
to a more relaxed timing to leave room for the other station. When using
'tight' parameters in for example BPQ then the setting will be too aggressive
when a third station wants to use the same QRG too. Solution is to use
more relaxed timers but then you are wasting time when the third station is
not there. The same for Persistance, you want to use 255 when you are alone
for maximum speed, but drop to 128 as soon as a second station drops in etc.
Also all this does not bother you if your links are point-to-point on a
otherwise empty QRG.
I hope you can respond on this in technical terms if you do not agree.
Please keep it technical and based facts. I also want to separate the
theory behind this regardless whether or not in practice FlexNet does
a good job in reaching its goal. At least this theory was the
fundamantal reason for not supporting KISS, in theory it just cannot
reach the same speed as for example a 6pack solution.
I can very well imagin that the way networks work in the US differs so
much from our crowded western-europe that FlexNet does not make sense.
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
Read previous mail | Read next mail
| |
