OpenBCM V1.13 (Linux)

Packet Radio Mailbox

DB0FHN

[JN59NK Nuernberg]

 Login: GUEST





  
PA2AGA > HDDIG    20.09.99 23:40l 157 Lines 7250 Bytes #-9772 (0) @ EU
BID : HD_99_236C
Read: GUEST
Subj: HamDigitalDigest 99/236C
Path: DB0AAB<DB0ZKA<DB0ABH<DB0SRS<DB0SIF<DB0HSK<PI8DRS<PI8DAZ<PI8GCB<PI8HGL<
      PE1NMB<EA7URC<PE0MAR<PI8VNW
Sent: 990920/1759Z @:PI8VNW.#ZH2.NLD.EU #:405 [HvHolland] FBB7.00g $:HD_99_236C
From: PA2AGA@PI8VNW.#ZH2.NLD.EU
To  : HDDIG@EU

Received: from pa2aga by pi1hvh with SMTP
	id AA19358 ; Mon, 20 Sep 99 17:25:59 UTC
Received: from pa2aga by pa2aga (NET/Mac 2.3.67/7.5.3) with SMTP
	id AA00015724 ; Mon, 20 Sep 99 18:19:08 MET
Date: Mon, 20 Sep 99 18:11:22 MET
Message-Id: <hd_99_236C>
From: pa2aga
To: hd_broadcast@pa2aga
Subject: HamDigitalDigest 99/236C
X-BBS-Msg-Type: B

types have been busting a gut for a decade or so to try to wipe out the BBS
and Packet nets in the US, got so far and then found themselves up against a
stone wall. The reason for this is that strategic removal of key stations in
the net only causes mail to "route around" the bad spot and keep right on
moving. It generally repairs itself quicker than they can damage it.
While it's true that the A geekoids have managed to set the US packet and
BBS nets back, they have come up way short of their goal of utterly
destroying them and replacing it all with tcpip. Now that Hams in the
northeast and other places are starting to reject A type thinking and
rebuild their networks, I think we can pretty well sit back and relax on
this issue. The A types tried, but failed. People can only sit on their
hands and listen to doom 'n gloom for so long.

In my case, most of the messages arrive over a dedicated BBS fwd link. My
fwd activities are literally the only traffic on that link, though it is
open for hams to use for other purposes if they want to. Some of the
messages come in on the ZOO channel, but these are individual hams, not BBS
stations.

There was a BBS I used to forward personal messages to, over the ZOO
channel, but never bulletins as it's kind of stupid to do that unless there
is absolutely no other choice.

>
> Composing a single line message in some chat mode might take 10-15
> seconds and in order to have some feel of interactivity, the
> propagation time should not be more than that. How far, in terms of
> hops can you reach in the evening, when people have time to chat ?

I'm sorry,but there are lots of variables there as well. I have access to
several nets (NetRom, TexNet, ROSE, IP) all of which have chat servers. I've
got a 255 channel chat server on my FlexNet node too, which can be accessed
from any of these nets.
The X1J net in Oklahoma is the only one I hop around on myself, and I
generally get good enough performance for what you are talking about out to
three hops, sometimes four. That's 150, maybe 200 miles I would suppose.

Then again, the criteria "good enough" varies a lot as well!  Maybe my "good
enough" is not, for you. I have no way of knowing about that.

>
> The problem is that if the network has been mainly built for bulletin
> forwarding, it is tuned towards high throughput and high channel
> utilisation. Unfortunately, this increases the latency time and the
> latency times become less predictable, thus making interactive
> applications not very comfortable to use and easily killing the
> enthusiasm for any new interactive applications. OTOH, tuning for
> better interactive response drops the channel usage and total net
> throughput.

This is where we differ.

My theory is that if your backbone links are at least 8-10 times faster than
the access, all the various applications can co-exist quite nicely.
HTS-free, fulldup backbone links running 8-10 times faster than the halfdup
access are going to be pretty hard to tie up with an overload. That's the
formula for a good packet network that makes the most sense to me.

This is the strength of AX25 Packet, and the weakness of tcpip, which just
HAS to have fast user access speeds to work decently. The faster user access
cuts down on the backbone/access speed ratio, thus reducing the load your
network can handle without loading up and slowing down.

This is why in this time of struggling to develop and speed up our networks,
tcpip is not the most clever way to utilize our RF networking. In fact, it's
one more handicap we just don't need at this point.

-And don't respond to this by chanting the "applications mantra". That
theory has absolutely nothing to support it, when the general packet
community is considered instead of a tiny minority of outspoken geeks.

Most hams could care less about running tcpip apps over Packet. They just
want the network to perform decently, so they can enjoy Amateur Packet Radio
apps to the fullest. (BBS, Cluster, Chat, APRS,QSO)

>
> Even a 1200 bit/s full duplex backbone link would be great for
> interactive use, since short frames could be sent effectively, without
> taking the penalty from TxDelay. Unfortunately the good latency times
> could be easily destroyed, if bulletin forwarding with long AX.25
> packets would be inserted. On 9600 bit/s full duplex, a full length
> AX.25 (bulletin) frame (sent at moderate intervals) would not destroy
> the latency times for other users very badly (only 250 ms compared to
> 2 s on 1200 bit/s).

That 1.2kb fulldup deal is just a demo.

In practice, you want to use that expensive, complicated high-speed stuff at
full-duplex on your backbone links, where it will do the most good. Use the
cheap, easy, no-brainer 1.2kb or 9.6kb halfdup stuff for user access, where
THEY will do the most good. - What you end up with is a decent network,
difficult to overload or slow down, easy to use.

Only tcpip could screw up such a good deal. Start running high-speed access,
and you can kiss your good-running network goodbye.

--

73 DE Charles Brabham, N5PVL
N5PVL @ N5PVL.#NTX.TX.USA.NOAM
http://www.texoma.net/~n5pvl



>.

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

Date: Sun, 19 Sep 1999 12:11:07 -0500
From: "George T. Baker" <w5yr@swbell.net>
Subject: Ham tcpip network = pipedream

Charles, I want to congratulate you on a well-thoughtout and very well
written piece and to thank you for sharing it on the Net for those of  us
who do not have the amateur network facilities that  you do.

I strongly suggest that  you submit this piece to ARRL for inclusion in
QST as an op-ed feature.

You raise interesting and intriguing questions about amateur usage of
radio in the analog areas as opposed to the digital data areas. Although
I have been "around" this business of digital operations for about 15
years now, I had never stopped to realize what a dichotomy existed in the
transmission and distribution systems for the two data classes. While I
now almost exclusively operate CW (analog) and PSK31 and RTTY (digital),
100% of my output is put into radio waves! But, a significant amount of
my discourse with the rest of the ham community also takes place on this
and other newsgroups, as well as several reflectors and listservers.

It is curious that almost all dxpeditions these days that have any
backing at all - and that is 99% of them - are fully equipped with fax,
Internet, email, and even satellite voice communications, as well as the
best of radios, antennas, and supporting equipment. DX contact logs are
"netted" back to QSL managers daily and appear on Web sites almost as
soon as the contacts are made. Some of the DXers claim that a dxpedition
could not be successful today without the infrastructure support behind
it. And almost all Dxers today absolutely *rely* on the DXCluster on two


To be continued in digest: hd_99_236D




Read previous mail | Read next mail


 23.06.2026 21:23:11lGo back Go up