OpenBCM V1.13 (Linux)

Packet Radio Mailbox

DB0FHN

[JN59NK Nuernberg]

 Login: GUEST





  
PA2AGA > HDDIG    20.02.00 06:35l 205 Lines 7875 Bytes #-9573 (0) @ EU
BID : HD_2000_49D
Read: GUEST
Subj: HamDigitalDigest 2000/49D
Path: DB0AAB<DB0PV<OE2XOM<OE5XBL<OE6XAR<OE3XPR<OM0PBM<SR9ZAA<YO2KJY<HG8GL<
      HA5OB<HA3PG<SV1AAW<EA7URC<PE0MAR<PI8VNW
Sent: 000220/0120Z @:PI8VNW.#ZH2.NLD.EU #:52754 [HvHolland] FBB7.00g24
From: PA2AGA@PI8VNW.#ZH2.NLD.EU
To  : HDDIG@EU

Received: from pa2aga by pi1hvh with SMTP
	id AA30722 ; Sat, 19 Feb 00 23:12:13 UTC
Received: from pa2aga by pa2aga (NET/Mac 2.3.70/7.5.3) with SMTP
	id AA00018029 ; Sat, 19 Feb 2000 17:18:19 MET
Date: Sat, 19 Feb 00 17:11:42 MET
Message-Id: <hd_2000_49D>
From: pa2aga
To: hd_broadcast@pa2aga
Subject: HamDigitalDigest 2000/49D
X-BBS-Msg-Type: B

that
I've done with my networks, I might just not want to packet at all. Maybe it's
not worth it.

A long ways back in the thread, someone asked, what do I want packet to do. To
be
honest, I still have a long ways to go to make up my mind. I am now in a
position
to be able to 'chase storms.' I just purchased a lightning detector and want
to
be able to see the plots that it generates when I'm mobile. That's just the
tip
of the iceberg. Wouldn't it be nice to be able to do that with the things that
I've already got?

To complete the 'company' senario that I started above, there is a way to
finish
it out. Pretend that it's time to upgrade the modem pool due to the customer
base
expansion. The current pool is a Max 4048. This pool is bought as a single
shot,
48 modem, no other options, solution. But if you would want to be able to
offer
other services, the 4048 won't cut it. The next step up would allow other
services such as ISDN, and even SDSL. But if I were going to offer a new xDSL,
it
would be HDSL. For that, I would have to go to the TNT chassis. For me, as the
ISP, it would mean flexibility including routing, switching and transport
capability that the 4048 can't match. For my customers, it means that grandpa
with his 'screamin' 9600 modem can happily chug away, while my DS1
manufacturing
plant and HDSL customers all get what they want. Speed, reliability,
flexibilty.
We've all won.

Why does amateur radio have to throw something away that is working just fine?
Why not, as shown above, include it with other offerings? Maybe it will die on
it's own. But what none of us wants is for amateur radio to die. So, if I can
get
a few converts to our community because of my computer's sound card, then we
all
win.

By the way, I would have to thank everyone that has been posting to this
thread.
It has been quite helpful, and the discussion has been lively and enjoyable.
I've
had fun with it. Maybe I will be up on packet by the weekend. Thank you all.

73

mike KC0GPM

>.

------------------------------

Date: Fri, 18 Feb 2000 04:05:00 -0600
From: "Steve Sampson" <ssampson@usa-site.net>
Subject: What is a good TNC?

> > > The thread diverged because the Sound Card is merely a hardware change
to a
> > > failed mode.  AX.25 is dead.  It is a lingering death, but the day is
done.
> >
> > What do you suggest as layer two transport if not AX.25?
> >
>
> Can't we get around this particualr point instead of beating it to death?
Why
> can't we keep AX.25 as we move forward? Why must it be thrown away?

Your argument is just as valid as mine.  I offer my argument only as debate.
Whether you agree or not is not important.  If you can convince me that my
argument is bogus, I will concede (and the Ham population on AX.25 will
explode with activity).

Steve


>.

------------------------------

Date: Fri, 18 Feb 2000 11:21:29 GMT
From: nomail@rob.knoware.nl (Rob Janssen)
Subject: What is a good TNC?

Steve Sampson <ssampson@usa-site.net> wrote:
>> What do you suggest as layer two transport if not AX.25?

>Anything that uses a MAC address of less than 56 bits, and does not do bit
>shifting.
>Using a Ham callsign is cute, but very wasteful of binary bits.  Bit
>shifting is something
>only a Ham could find value in.

You will have to do better than that!
56 bits is not a big waste when decent speeds would be used.  you will be
horrified to see that the Internet protocols are moving towards 128-bit
addresses.
Besides, the current address field nicely doubles as a station
identification.  When it would not include the station call, the call would
have to be broadcast in another way, potentially wasting a lot more.
(in many countries, when you would not use an agreed-upon identification in
packet, you would have to ID in CW.  this usually wastes lots of bittimes)

The bit shifting is "required" compatability with the existing LAPB standard.
I don't see why anyone would see it as a disadvantage of AX.25, it is an
issue you deal with in the low-level software and never see as a user or a
programmer of the higher level protocols.
Sure the address field could have been compacted to 40 bits or so, but it
would have required even more bit shifting.

The serious problems in AX.25 have nothing to do with the address header.
They are in:

- the channel access algorithm
- the handling of damaged packets, especially the case of one damaged
  packet in a longer series of good packets
- the explicit or implicit limits to packet size and unacked packet count,
  which are too restrictive at higher speeds

Solutions to these problems have been developed, and some of them could
simply be adopted from the LAPB standard from which AX.25 was derived.
However, widespread use of these solutions is often difficult with so
many firmware implementations around.  This tells us how important it is
to get things right within the first few releases of the spec, before
widespread implementation begins.

Example: DAMA was developed as a solution for the channel access problem,
but in an attempt to make it compatible with existing AX.25 implementations
(an attempt that failed anyway), it was integrated into the AX.25 connection
layer instead of being inserted as a separate layer.  This causes problems
when there is no AX.25 connection, and one still wants to use the improved
channel access algorithm e.g. to send UI frames.

Rob
-- 
+----------------------------------+--------------------------------------+
| Rob Janssen     pe1chl@amsat.org | WWW: http://www.knoware.nl/users/rob |
| AMPRnet:     rob@pe1chl.ampr.org | AX.25 BBS: PE1CHL@PI8WNO.#UTR.NLD.EU |
+----------------------------------+--------------------------------------+
>.

------------------------------

Date: Fri, 18 Feb 2000 10:52:17 GMT
From: nomail@rob.knoware.nl (Rob Janssen)
Subject: What is a good TNC?

Steve Sampson <ssampson@usa-site.net> wrote:
>As far as I know, everything in your home-town is 1500% better
>than anything across America.  Anyway, that's how you make it all sound.

No, I just want to adjust the typical-American attitude that "the best we
have seen locally" is equal to "the best there is" (often even cited as
"The World's Best").  It just might be that in the underdeveloped world
outside the USA there are things happening you are not aware of.

Most of the packet radio stuff I have listed as examples of products better
suitable than a TNC have not been developed in my home town or my home
country.  The only product I have helped develop and have promoted is the
OptoPcScc card and a couple of its associated modems.  It is a good
solution for the above-average packet station (multiple modems) and for a
network node.  It is sold through our national packet radio amateur club
(something like TAPR).  Others have copied the design and are selling it
commercially.
All the other stuff is developed in other countries, like Germany, France,
Greece, Switzerland, etc.

Rob
-- 
+----------------------------------+--------------------------------------+
| Rob Janssen     pe1chl@amsat.org | WWW: http://www.knoware.nl/users/rob |
| AMPRnet:     rob@pe1chl.ampr.org | AX.25 BBS: PE1CHL@PI8WNO.#UTR.NLD.EU |
+----------------------------------+--------------------------------------+
>.

------------------------------

End of Ham-Digital Digest V2000 #49
******************************

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


 08.05.2026 05:18:48lGo back Go up