| |
PA2AGA > HDDIG 26.09.99 10:13l 200 Lines 6985 Bytes #-9758 (0) @ EU
BID : HD_99_241T
Read: GUEST
Subj: HamDigitalDigest 99/241T
Path: DB0AAB<DB0PV<DB0MAK<DB0SON<DB0SIF<DB0FHK<DB0HSK<PI8DRS<PI8DAZ<PI8APD<
PI8WNO<PI8HGL<PE1NMB<EA7URC<PE0MAR<PI8VNW
Sent: 990926/0255Z @:PI8VNW.#ZH2.NLD.EU #:2730 [HvHolland] FBB7.00g $:HD_99_241
From: PA2AGA@PI8VNW.#ZH2.NLD.EU
To : HDDIG@EU
Received: from pa2aga by pi1hvh with SMTP
id AA19958 ; Sun, 26 Sep 99 01:50:33 UTC
Received: from pa2aga by pa2aga (NET/Mac 2.3.67/7.5.3) with SMTP
id AA00015980 ; Sun, 26 Sep 99 01:11:04 MET
Date: Sun, 26 Sep 99 01:04:26 MET
Message-Id: <hd_99_241T>
From: pa2aga
To: hd_broadcast@pa2aga
Subject: HamDigitalDigest 99/241T
X-BBS-Msg-Type: B
> proxim in the 100-150$ range. they hit 11mbits/second over short (very
> short) paths and 1 mbit/sec over longer paths. mebby with some proper
> front end design we can reach gary's ideal BER and a little more ooph
> on the TX to extend the working range.
>
> I like this solution speed and price wise a little better than the 56k
> solution. now, can we make it work?
>
> --- eric
Sounds interesting. Do you have a pointer to the specs?
I'll poke around Lucent's web site a bit ...
--
... Hank
http://horedson.home.att.net
>.
------------------------------
Date: Fri, 24 Sep 1999 09:38:46 GMT
From: nomail@pe1chl.demon.nl (Rob Janssen)
Subject: Those Wide, Open Spaces
Hank Oredson <horedson@att.net> wrote:
>> >> Of course that approach is much too simple... it is just like the
>> >firmware
>> >> in the old TNC's: when the CONNECT succeeds, it starts retrying the
>data
>> >> transmission until hell freezes over.
>> >This is not true.
>> It is. When a link is that marginal that an SABM/UA or an RR(P)/RR(F)
>> can be exchanged, but an I frame never makes it through, the classic
>> TNC firmware will retry forever.
>Ah. "... the classic TNC firmware ..."
>Yes, of course it will. Nobody would run such junk anymore,
>would they?
Maybe some people are still writing AX.25 implementations following the
official spec, that included this buggy behaviour?
>Just ask the FLEXNET folks, check out what has
>been done in Linux and the modern *NOS codes. Welcome to
>the 90's ...
I don't know how Flexnet handles retries on the AX.25 level, as I don't
live near a Flexnet node. Maybe they have implemented an overall timeout,
as I did in my version of NET.
The TCP retry timer behaviour and failure mechanism in JNOS just sucks.
I hope it has been done better in some of the 25 other versions.
I only know that it was OK in the original KA9Q version, but then some
inexperienced people started to hack it...
>> My software measures link quality by sending numbered UI frames on
>> the link and evaluating the ratio between received/missed frames at
>> the other end. This allows evaluation of link quality independently
>> in each direction, even when the link is completely dead in one direction.
>Oh, you are talking packet. Thought we were discussing HF, where
>packet is not among the useful protocols.
Such techniques are possible in most protcols. It is just measuring
the loss rate independent from any error recovery mechanisms in the
connection protocol.
[further nitpicking deleted]
Rob
--
+----------------------------------+--------------------------------------+
| Rob Janssen pe1chl@amsat.org | WWWhome: http://www.pe1chl.demon.nl/ |
| AMPRnet: rob@pe1chl.ampr.org | AX.25 BBS: PE1CHL@PI8WNO.#UTR.NLD.EU |
+----------------------------------+--------------------------------------+
>.
------------------------------
Date: Fri, 24 Sep 1999 08:10:17 -0700
From: "Hank Oredson" <horedson@att.net>
Subject: Those Wide, Open Spaces
Rob Janssen <nomail@pe1chl.demon.nl> wrote in message
news:slrn7umhl6.d47.nomail@linux.pe1chl.ampr.org...
> Hank Oredson <horedson@att.net> wrote:
> >> >> Of course that approach is much too simple... it is just like the
> >> >firmware
> >> >> in the old TNC's: when the CONNECT succeeds, it starts retrying the
> >data
> >> >> transmission until hell freezes over.
>
> >> >This is not true.
>
> >> It is. When a link is that marginal that an SABM/UA or an RR(P)/RR(F)
> >> can be exchanged, but an I frame never makes it through, the classic
> >> TNC firmware will retry forever.
>
> >Ah. "... the classic TNC firmware ..."
> >Yes, of course it will. Nobody would run such junk anymore,
> >would they?
>
> Maybe some people are still writing AX.25 implementations following the
> official spec, that included this buggy behaviour?
I hope not!
We have over 15 years experience with AX.25 now, and anyone
who writes code can make the needed changes. The information
is available in the proposed new specs (there are at least two
proposals for extensions to AX.25, they contain a lot of good
analysis of those protocol implementation problems).
> >Just ask the FLEXNET folks, check out what has
> >been done in Linux and the modern *NOS codes. Welcome to
> >the 90's ...
>
> I don't know how Flexnet handles retries on the AX.25 level, as I don't
> live near a Flexnet node. Maybe they have implemented an overall timeout,
> as I did in my version of NET.
>
> The TCP retry timer behaviour and failure mechanism in JNOS just sucks.
> I hope it has been done better in some of the 25 other versions.
> I only know that it was OK in the original KA9Q version, but then some
> inexperienced people started to hack it...
It is a mess in JNOS. That is one of the reasons for SNOS, I wanted
to get the basic networking working well before doing the applications
work - the fun part. Discovered I needed to rewrite a
lot of (or all of) tcp, ax.25 and net/rom. Nearly done with that now,
and the tcp/ip works well over net/rom links. The SYN flood problem
is fixed for example, as well as the net/rom CHOKE bug, and dozens
of other problems.
> >> My software measures link quality by sending numbered UI frames on
> >> the link and evaluating the ratio between received/missed frames at
> >> the other end. This allows evaluation of link quality independently
> >> in each direction, even when the link is completely dead in one
direction.
>
> >Oh, you are talking packet. Thought we were discussing HF, where
> >packet is not among the useful protocols.
>
> Such techniques are possible in most protcols. It is just measuring
> the loss rate independent from any error recovery mechanisms in the
> connection protocol.
Ok, I understand. Thought you were saying something different.
Of course you are correct, these techniques can be used on any
band(s) with any protocol network. The only issue is the ability of
the controller to report the appropriate observations.
The software to do this should be "interesting" to write.
> Rob
> --
>
+----------------------------------+--------------------------------------+
> | Rob Janssen pe1chl@amsat.org | WWWhome: http://www.pe1chl.demon.nl/
|
> | AMPRnet: rob@pe1chl.ampr.org | AX.25 BBS: PE1CHL@PI8WNO.#UTR.NLD.EU
|
>
+----------------------------------+--------------------------------------+
>.
------------------------------
End of Ham-Digital Digest V99 #241
******************************
You can send in your contribution to this digest by
sending an e-mail to: hd-group@pa2aga.ampr.org
or (via BBS-net) to: hdaga@pi8vnw.#zh2.nld.eu
Read previous mail | Read next mail
| |
