| |
PA2AGA > HDDIG 20.09.00 23:38l 184 Lines 7400 Bytes #999 (0) @ EU
BID : HD_2000_252G
Read: DC1TMA GUEST
Subj: HamDigitalDigest 2000/252G
Path: DB0AAB<DB0RGB<DB0MRW<DB0SON<DB0ERF<DB0BRI<DB0HAG<DB0ACH<PI8JOP<PI8ZAA<
PI8HGL
Sent: 000920/1912Z @:PI8HGL.#ZH1.NLD.EU #:16296 [Den Haag] FBB $:HD_2000_252G
From: PA2AGA@PI8HGL.#ZH1.NLD.EU
To : HDDIG@EU
Date: Sun, 17 Sep 00 16:38:22 MET
Message-Id: <hd_2000_252G>
From: pa2aga@pe1mvx.ampr.org
To: hd_broadcast@pa2aga.ampr.org
X-BBS-Msg-Type: B
>
> And then whine about how we should abandon ham radio because
> it cannot deliver as much data across town as a VW full of DAT tapes.
come on hank, I know you are capable of better reasoning than that
(this is meant as a complement).
at the end of the day, any channel beats no channel hands down. The message
that keeps getting lost is that amateur radio needs to do better and
it can do better. Yes, radio will never beat fiber but that doesn't
mean that we shouldn't try to give copper a run for its money.
the Internet, like it or not, sets the lower bar. Ham radio should be
able to do as good as $100 modem for not more than twice the price.
Hams should be able to cooperate and get the message to where it needs
to go by any route possible. If that means tunneling through the
Internet because there aren't enough hams on the ground, then so be
it.
life is too short for pissing contests.
--- eric
------------------------------
Date: Thu, 14 Sep 2000 16:44:58 -0400
From: "Ed_Woodrick" <Ed_Woodrick@email.msn.com>
Subject: internet repeater linking
Charles,
While your idea is indeed a step above basic forwarding, it has some
implementation problems, especially on HF.
Just to make things clear, I believe that your use of the term multi-cast is
a little different than the generic use of the term. It seems as if your use
of technology is actually a broadcast. The difference is that a broadcast is
to all stations, while multicast is actually multiple routing hubs directly
sending information to individual stations. But semantics aside....
The biggest problem with your multicast solution, especially on HF is that
it does not include error correction. It is very common to have to
retransmit packets on HF multiple times due to static or fades. Without an
adequate error correction method, the chances of all receiving stations
receiving a packet is very low. Multiply this by the number of packets in a
message, then the probability that messages are transferred are nil.
To implement error correction in your solution, a protocol by which each
receiving station would ask for retries would be required. Even with an
error correcting protocol, traffic would come to a halt if one of the
receiving stations was marginal, asking for resends on most or all packets.
The nature of HF makes any multipoint solution a big problem. With the
network path to all stations being very variable, the reliability is just
not there. Think of it this way, what is the probability that three stations
can receive a signal from a fourth, for three seconds without at least one
of the receiving stations missing a bit? Sure you can add FEC, but that
increases the transmission times and still doesn't help the overall problem.
There's also a problem on VHF/UHF, the classic hidden transmitter problem.
While no where as significant as the hf static and fades, it still becomes a
problem. When a broadcast station starts sending its messages, there is
nothing that prevents other stations from transmitting. And since a
broadcast packet would go out as a UI frame, there is no retransmission. And
as in HF, there is no error correction to cause the packet to be
retransmitted.
In either case you have to be careful about network congestion and multiple
stations wanting to transmit at the once. This could be greatly reduced by
scheduling different stations with transmit periods.
The broadcast/multicast solution that you have suggested works fairly well
on networks where the communication paths between stations is very strong,
like an Ethernet. But it has problems with networks with high BER.
No, I'm not shooting my mouth off.
Ed
"Charles Brabham" <n5pvl@swb.net> wrote in message
news:7J6w5.580$e52.9742@nnrp1.sbc.net...
>
>
> I've suggested a way to beat that speed for distribution of "across the
> country" several times, and even did a brief on the air test. I didn't get
> much feedback, and assumed a lack of interest... Are you interested? - Or
> just shooting your mouth off?
>
> http://home.swbell.net/n5pvl/multi.htm
>
> 73 DE Charles Brabham, N5PVL
> n5pvl@swbell.net
> http://home.swbell.net/n5pvl/
>
>
------------------------------
Date: Fri, 15 Sep 2000 00:40:29 GMT
From: "Hank Oredson" <horedson@att.net>
Subject: internet repeater linking
"Ed_Woodrick" <Ed_Woodrick@email.msn.com> wrote in message
news:OOGUMyoHAHA.322@cpmsnbbsa09...
> Charles,
>
> While your idea is indeed a step above basic forwarding, it has some
> implementation problems, especially on HF.
>
> Just to make things clear, I believe that your use of the term multi-cast is
> a little different than the generic use of the term. It seems as if your use
> of technology is actually a broadcast. The difference is that a broadcast is
> to all stations, while multicast is actually multiple routing hubs directly
> sending information to individual stations. But semantics aside....
>
> The biggest problem with your multicast solution, especially on HF is that
> it does not include error correction. It is very common to have to
> retransmit packets on HF multiple times due to static or fades. Without an
> adequate error correction method, the chances of all receiving stations
> receiving a packet is very low. Multiply this by the number of packets in a
> message, then the probability that messages are transferred are nil.
This topic was done to death about 5-6 years ago. Several robust
"request fill" protocols were proposed, none were tested. The regulatory
issues are minor with multi-cast, serious with broadcast (in the US).
A bunch of us code writers might well add such protocols, were there any
interest. 5-6 years ago there was no interest in actually *doing* something.
CLOVER supports the underlying concepts particularly well, PACTOR
has support for them. They could be used with PSK31. They could be used,
in fact, with just about any signaling protocol. In the long distant past
(when
I had a model 104 TTY on air) something similar to this was done for
distribution of some CP/M code (Lynn, WB6UUT, I think?)
What is needed are hams interested in actually *doing* it, instead of
*talking about it*. Anyone home out there?
--
... Hank
http://horedson.home.att.net
------------------------------
Date: Fri, 15 Sep 2000 07:53:12 GMT
From: nomail@rob.knoware.nl (Rob Janssen)
Subject: internet repeater linking
Ed_Woodrick <Ed_Woodrick@email.msn.com> wrote:
>Rob,
>30 messages is an unrealistic expectation. If only 1% of the Amateurs sent
>only one message a day, that would result in over 500 messages per day.
So what you need is a lower rate than that. Not because the network would
not be able to transport it, but because the readers would not be able
to digest it.
A better message category structuring system might have helped (putting
everything in a single list with 6-character destination names sucked from
the day it was invented), but Usenet shows that some people just won't get
the intended purpose of the structure, and crosspost or multipost.
The mailbox software developed and used in Germany uses a groups system,
and indeed both multiposting and posting of links to articles in other
To be continued in digest: hd_2000_252H
Read previous mail | Read next mail
| |
