CQ

[Grant Taylor]

Hi,

Is there anyone lurking in the packet radio newsgroups any more?

I'm looking for someone to chat with about AX.25 / Net/ROM, particularly
on Linux.



--
Grant. . . .
unix || die

[Bill Gunshannon]

On 1/7/21 12:55 PM, Grant Taylor wrote:
> Hi,
>
> Is there anyone lurking in the packet radio newsgroups any more?
>
> I'm looking for someone to chat with about AX.25 / Net/ROM, particularly
> on Linux.
>
>
>

Well, I still hang out here but I am not every active. To the best
of my knowledge there is no AX.25 activity anywhere around me. (Heck,
I can't even find an active 2 meter repeater within my range.) I miss
the days when I ran digipeaters on mountaintops and saw massive amounts
of traffic.I had a lot of stuff I thought would be interesting with
AX.25 but it seems everyone else got bored of it and with the advent
of the Internet all but gave up. And don't get me started on the strong
NIH syndrome that infected it. At least around where I was.

bill
KB3YV
FN21hj

[Andy Valencia]

Grant Taylor <gta...@tnetconsulting.net> writes:
> Hi,
>
> Is there anyone lurking in the packet radio newsgroups any more?
>
> I'm looking for someone to chat with about AX.25 / Net/ROM, particularly
> on Linux.

Hi, Grant.

First over on UUCP, now here!

I have a background project, fiddling with a protocol for packet
radio which scales. Everything is a multicast group (helps with roaming,
as well as the usual benefits) and a CDN protocol with idempotent
semantics so nodes can opportunistically glean/cache content as it goes
by on the air.

Wrote an air/terrain emulator, and was originally
going to use standard AX.25 TNC operations to put packets on the
air. But the emulator showed that the collision and hidden transmitter
problems are just horrible in any but the lightest use. So I've been
most recently working on an explicit TDM layer in place of what a TNC
would do. So standard TNC's are out, but I hope to come up with a
protocol which would work pretty well in, say, a disaster net.

73's,
Andy Valencia K6AJV
Home page: https://www.vsta.org/andy/
To contact me: https://www.vsta.org/contact/andy.html

[Bill Gunshannon]

On 1/7/21 5:16 PM, Andy Valencia wrote:
> Grant Taylor <gta...@tnetconsulting.net> writes:
>> Hi,
>>
>> Is there anyone lurking in the packet radio newsgroups any more?
>>
>> I'm looking for someone to chat with about AX.25 / Net/ROM, particularly
>> on Linux.
>
> Hi, Grant.
>
> First over on UUCP, now here!
>

Did you know that UUCP works fine over AX.25. :-)

bill
KB3YV

[Grant Taylor]

On 1/7/21 11:22 AM, Bill Gunshannon wrote:
> Well, I still hang out here but I am not every active.

I've been subscribed to the newsgroup for quite a while. But my message
was the first one in my servers 2+ year history in the
alt.ham-radio.packet and free.packet.radio newsgroups.

> To the best of my knowledge there is no AX.25 activity anywhere
> around me. (Heck, I can't even find an active 2 meter repeater within
> my range.)

I'm sort of surprised that there isn't a 2m repeater in range.

I'm also a little surprised that there isn't any APRS activity.

> I miss the days when I ran digipeaters on mountaintops and saw massive
> amounts of traffic.

I know of digipeaters. Though I'm evaluating Net/ROM vs ROSE for
something I'm thinking about doing.

I think that Net/ROM might be nicer in that it has automatic routing vs
ROSE which is completely manual routing. Though I like the fact that
ROSE is actually X.25 implemented on top of AX.25. At least, as best as
I can tell.

I'd sort of like a private X.25 cloud.

> I had a lot of stuff I thought would be interesting with AX.25 but
> it seems everyone else got bored of it and with the advent of the
> Internet all but gave up.

*nod*

One of the reasons that I got into ham radio was the communications
ability that didn't depend on the Internet.

> And don't get me started on the strong NIH syndrome that infected it.
> At least around where I was.

I don't get the Not Invented Here mentality. I've long been a fan of
standing on the shoulders of giants.

[Grant Taylor]

On 1/7/21 3:16 PM, Andy Valencia wrote:
> Hi, Grant.

Hi Andy,

> First over on UUCP, now here!

Yep. I lurk in about 349 newsgroups (wc -l ... newsrc...). I'm active
in 20-50 any given week.

> I have a background project, fiddling with a protocol for packet
> radio which scales. Everything is a multicast group (helps with roaming,
> as well as the usual benefits) and a CDN protocol with idempotent
> semantics so nodes can opportunistically glean/cache content as it goes
> by on the air.

Interesting.

I'd like to get an AX.25 network running between some machines here at
home. I'm thinking VERY seriously about using Linux's BPQ capability to
do AX.25 across Ethernet. My moonshot goal is to get OpenSSH running
over AX.25, sans TCP/IP. I'd really like some level of routing, hence
looking at Net/ROM and ROSE.

Why AX.25? Well, I want a protocol barrier for both IPv4 and IPv6.

> Wrote an air/terrain emulator, and was originally
> going to use standard AX.25 TNC operations to put packets on the
> air. But the emulator showed that the collision and hidden transmitter
> problems are just horrible in any but the lightest use. So I've been
> most recently working on an explicit TDM layer in place of what a TNC
> would do. So standard TNC's are out, but I hope to come up with a
> protocol which would work pretty well in, say, a disaster net.

I wouldn't know where to start if you were trying to avoid TNC
functionality.

> 73's,

73

[Grant Taylor]

On 1/7/21 4:23 PM, Bill Gunshannon wrote:
> Did you know that UUCP works fine over AX.25.  :-)

I would expect that it would.

I can sort of see how to do it with raw AX.25 as well as with Net/ROM or
ROSE.

Different UUCP protocols might actually be advantagious to AX.25.
Though I suspect that AX.25's error detection and correction would
provide a fairly clean link.

I wonder if there would be any way to leverage AX.25's broadcast nature
to have UUCP send data to multiple nodes, a la. Usenet data feed.

[Bill Gunshannon]

Usenet feeds do not go to multiple sites in a single stream. Connection
is made to each peer and news transferred.

bill

[Bill Gunshannon]

On 1/7/21 8:05 PM, Grant Taylor wrote:
> On 1/7/21 11:22 AM, Bill Gunshannon wrote:
>> Well, I still hang out here but I am not every active.
>
> I've been subscribed to the newsgroup for quite a while.  But my message
> was the first one in my servers 2+ year history in the
> alt.ham-radio.packet and free.packet.radio newsgroups.

Prior to this the only traffic I have seen in any of the ham radio
groups has been garbage telling people (repeatedly ad nauseum) to
visit a web site to read about what they posted as a topic. Worse
than the last packet I saw which was DX Cluster Broadcasts. (which,
technically, should be illegal as they are broadcasts!)

>
>> To the best of my knowledge there is no AX.25 activity anywhere around
>> me. (Heck, I can't even find an active 2 meter repeater within my range.)
>
> I'm sort of surprised that there isn't a 2m repeater in range.

So am I as I live a mere 20 miles from Scranton, PA, a major city.
But it seems most of the repeaters have gone away and many of them
seem to have reduced their coverage area. Even when I hear one
(not often) it is usually not reachable with any of the gear I
have. And I have set up a scanner to cover all the 2 meter packet
freqs and never hear a thing.

>
> I'm also a little surprised that there isn't any APRS activity.

I see local (well, within 10 miles of me) APRS activity if I look
online, but I have yet to figure out just what APRS is supposed
to be doing. Not sure I want everyone to know where I am all
the time.

>
>> I miss the days when I ran digipeaters on mountaintops and saw massive
>> amounts of traffic.
>
> I know of digipeaters.  Though I'm evaluating Net/ROM vs ROSE for
> something I'm thinking about doing.

Played with both. Think ROSE would have been nice but it never
caught on and never saw the activity that would have helped it
develop into something really usable. NETROM is OK but has a
few warts, too. Howie-Code would have been nice, too, but it
got even less attention that ROSE. The only things I ever saw
it running in were my DR-200 digipeaters. I tried a few times
to get the firmware from PACCOmm but, apparently, they lost it.
I contacted Howie Goldstein N2WX a couple times but could never
convince him to release any of his code. Too bad really because
it was a decent idea.Oh yeah, and then there is also TCPIP but
that kinda faded with real TCPIP on the Internet. I assume by
now my address allocations are all gone.

>
> I think that Net/ROM might be nicer in that it has automatic routing vs
> ROSE which is completely manual routing.

If it had a chance it might have developed good routing, after all,
it is using the same concepts as the phone system and that seems to
route connections pretty well. But it died on the vine just like
the rest of Packet Radio.

> Though I like the fact that
> ROSE is actually X.25 implemented on top of AX.25.  At least, as best as
> I can tell.

Implementing AX.25 on top of X.25 seems rather silly as they are the
same basic protocol with differences to meet legal limitations.
ROSE is the OSI Networking concept running on top of AX.25 instead
of X.25. There are lots of good reasons to use OSI but in the industry
TCPIP beat it out.

>
> I'd sort of like a private X.25 cloud.

Not exactly sure what that means, but then I am not a fan of
"The Cloud" so it could be something simple I miss.

>
>> I had a  lot of stuff I thought would be interesting with AX.25 but it
>> seems everyone else got bored of it and with the advent of the
>> Internet all but gave up.
>
> *nod*
>
> One of the reasons that I got into ham radio was the communications
> ability that didn't depend on the Internet.

I saw that as a good idea, too. But even in limited environments
it met a lot of resistance. Back in the days before AX.25 I was
a big RTTY guy. Probably because I did it professionally in the
Army for many years. I was a Class C MARS station in the north
of Germany on my last tour there with the Army (1977-1979). I
spent many nights relaying traffic from other remote MARS Stations
and the Gateway Station in Pirmasens, Germany. When I came back
to the states I didn't continue with MARS. Then after my Army
time ended and I was back home and doing packet including running
digipeaters with connections all over New England my dad, who was
a MARS operator and had seen my packet stuff (I once connected to
a VAX in central NJ from his home in Wilkes-Barre, PA using 1200
baud packet) asked me to come down to the PA MARS Conference at
Carlisle Barracks and talk to them about the capabilities of AX.25
in their environment. I did. I talked about the ability for
MARS, in conjunction with the Corps of Engineers, who have remote
radio sites all over the United States, to set up a functional
data network not reliant on the phone system and that would remain
functional even during disasters. They were impressed and convinced
me to join MARS again. I did. Less t6han a week after I got my
MARS Operating Permit I was contacted by the local (NEPA) MARS
Manager and told he was not interested in any network I had in
mind and he was the boss so I should just drop the iddea completely.
I never joined a net or filed a monthly report and my membership
eventually expired. Remember what I said about NIH? The same
was true when I tried to get TCPIP activity among the local Ham
Community. The had W0RLI BBSes (which actually were nothing but
existing old tech re-invented, badly) and had no interest in
anything more modern that CW.

>
>> And don't get me started on the strong NIH syndrome that infected it.
>> At least around where I was.
>
> I don't get the Not Invented Here mentality.  I've long been a fan of
> standing on the shoulders of giants.

See above. :-)

bill
KB3YV
FN21hj

[Andy Valencia]

Grant Taylor <gta...@tnetconsulting.net> writes:
> I wouldn't know where to start if you were trying to avoid TNC

Both the guts of Direwolf (great SW, BTW) or just soundmodem will give
you lots of raw functionality--FSK coding up through packet assembly.
But then on top of it you run your own queues and logic for when to
key up.

Andy Valencia

[Grant Taylor]

On 1/8/21 5:49 AM, Bill Gunshannon wrote:
> Usenet feeds do not go to multiple sites in a single stream.
> Connection is made to each peer and news transferred.

It depends what type of Usenet feed it is. Traditional UUCP & NNTP
feeds are one-to-one.

However there is multi-cast NNTP. There used to be Usenet via satellite
broadcast.

So ... I'm convinced that Usenet is /capable/ of being one-to-many.

[Grant Taylor]

On 1/8/21 6:31 AM, Bill Gunshannon wrote:
> Prior to this the only traffic I have seen in any of the ham radio
> groups has been garbage telling people (repeatedly ad nauseum)
> to visit a web site to read about what they posted as a topic.

I hate such posts. Just post the content. Even those types of sites
can copy / relay / post the content. But ... let's be honest, they
aren't about the content, they are fishing (if not actually phishing) to
draw people to the site.

> Worse than the last packet I saw which was DX Cluster Broadcasts.
> (which, technically, should be illegal as they are broadcasts!)

I guess it depends what medium they are in. As licensed ham
transmissions (which are in and of themselves a "broadcast") is supposed
to be a bidirectional communications between two or more individuals.

> And I have set up a scanner to cover all the 2 meter packet freqs
> and never hear a thing.

I'm tempted to get out my old Realistic programmable scanner (presuming
it made the cross country move) and start scanning the 2m range.

> I see local (well, within 10 miles of me) APRS activity if I look
> online, but I have yet to figure out just what APRS is supposed to
> be doing. Not sure I want everyone to know where I am all the time.

What is your confusion about APRS?

My limited understanding is that it's supposed to give location --
presumably GPS coordinates -- for the person transmitting.

I don't think I'd want APRS as a norm. But I can see it's value while
hiking, mainly as a safety thing. E.g. Hey Bob, if you don't hear from
me by such and such time, please have someone check on me. I'll be
broadcasting my location via APRS.

But definitely not as a norm.

> Played with both. Think ROSE would have been nice but it never caught
> on and never saw the activity that would have helped it develop into
> something really usable. NETROM is OK but has a few warts, too.
> Howie-Code would have been nice, too, but it got even less attention
> that ROSE.

I don't think I've ever heard of Howie-Code. I'll have to look it up.

> The only things I ever saw it running in were my DR-200 digipeaters.
> I tried a few times to get the firmware from PACCOmm but, apparently,
> they lost it. I contacted Howie Goldstein N2WX a couple times but
> could never convince him to release any of his code. Too bad really
> because it was a decent idea.Oh yeah, and then there is also TCPIP
> but that kinda faded with real TCPIP on the Internet. I assume by
> now my address allocations are all gone.

I never viewed ham radio as a viable alternative to a traditional ISP
connection. I do consider it to be a backup. But there are a number of
limitations. So, anyone that was using packet as an Internet connection
quite likely moved on to something else if they could. That likely just
leaves the people messing with packet that actually want to mess with
/packet/.

> If it had a chance it might have developed good routing, after all,
> it is using the same concepts as the phone system and that seems to
> route connections pretty well. But it died on the vine just like
> the rest of Packet Radio.

My current limited understanding is that NET/ROM used call signs as
addresses. Seeing as how call signs are effectively non-hierarchical, I
don't think that NET/ROM could have scaled that well. Or at least there
would have eventually been a diminishing return. ROSE on the other hand
probably could have been configured in a hierarchical manner.

> Implementing AX.25 on top of X.25 seems rather silly as they are
> the same basic protocol with differences to meet legal limitations.

The other way around. X.25 (routed protocol) on top of AX.25
(non-routed protocol).

> ROSE is the OSI Networking concept running on top of AX.25 instead
> of X.25.

Hum. I need to do some more reading. My current understanding, save
for your comment, is that ROSE is RATS Open Systems Environment, and
that RATS is Radio Amateur Telecommunications Society. And that it was
an interoperable variant of X.25.

At least some of the reading that I've done in the last few days was
explicitly talking about ROSE being switched with X.25. But I can't
readily point to anything specific at the moment.

> There are lots of good reasons to use OSI but in the industry TCPIP
> beat it out.

Good enough vs purportedly perfect. And that's being generous to OSI
and Ethernet.

> Not exactly sure what that means, but then I am not a fan of "The
> Cloud" so it could be something simple I miss.

In this case, the "cloud" is simply a collection of X.25 switches.
Nothing in the 2000 teens sense of the word meaning someone else's ....

Some of the playing I do in my home lab could benefit from a local X.25
switch that does not connect to anything outside of my home lab.

> I saw that as a good idea, too. But even in limited environments
> it met a lot of resistance. Back in the days before AX.25 I was
> a big RTTY guy. Probably because I did it professionally in the
> Army for many years. I was a Class C MARS station in the north of
> Germany on my last tour there with the Army (1977-1979). I spent
> many nights relaying traffic from other remote MARS Stations and
> the Gateway Station in Pirmasens, Germany. When I came back to the
> states I didn't continue with MARS. Then after my Army time ended
> and I was back home and doing packet including running digipeaters
> with connections all over New England my dad, who was a MARS operator
> and had seen my packet stuff (I once connected to a VAX in central
> NJ from his home in Wilkes-Barre, PA using 1200 baud packet) asked me
> to come down to the PA MARS Conference at Carlisle Barracks and talk
> to them about the capabilities of AX.25 in their environment. I did.
> I talked about the ability for MARS, in conjunction with the Corps of
> Engineers, who have remote radio sites all over the United States,
> to set up a functional data network not reliant on the phone system
> and that would remain functional even during disasters.

Yep. I really like the idea that the radio and associated equipment is
relatively portable and can be set up just about anywhere. As long as
you have power to operate and can get a signal out to someone and they
can get a signal back in to you, you're working.

> They were impressed and convinced me to join MARS again. I did.
> Less t6han a week after I got my MARS Operating Permit I was contacted
> by the local (NEPA) MARS Manager and told he was not interested in
> any network I had in mind and he was the boss so I should just drop
> the iddea completely. I never joined a net or filed a monthly report
> and my membership eventually expired.

*sigh*

So it was "join our ranks" and "check your idea(s) at the door". No
thank you.

> Remember what I said about NIH? The same was true when I tried to
> get TCPIP activity among the local Ham Community. The had W0RLI BBSes
> (which actually were nothing but existing old tech re-invented, badly)
> and had no interest in anything more modern that CW.

Ya. There needs to be a perceived /need/ for new things for people to
really adopt them. I'm somewhat guilt of the same. There have been
discussions of NNCP in other newsgroups, including someone prodding me
to mess with it. But, I don't have a /need/ for it. As such, I'm
somewhat reluctant to do so. However, I am aware of it and discuss it
with people.

There really is something to be said about people living in their own
personal box. And what is said is not always good.

> See above. :-)

*nod*

73

[Grant Taylor]

On 1/8/21 7:47 AM, Andy Valencia wrote:
> Both the guts of Direwolf (great SW, BTW) or just soundmodem will give
> you lots of raw functionality--FSK coding up through packet assembly.

I thought that soundmodem was effectively a software TNC relying on the
sound card. So ... even that doesn't avoid the TNC functionality.

Perhaps it's a start, as in prior art, to base new creations from that
themselves function in lieu of a TNC.

> But then on top of it you run your own queues and logic for when to
> key up.

Queuing could mean a lot of different things. Is it messages waiting in
line to go out? Or is it just waiting for clear air time to send a
frame? Or is it something else.? That definitely starts stretching and
changing definitions.

[Bill Gunshannon]

On 1/8/21 11:01 AM, Grant Taylor wrote:
> On 1/8/21 5:49 AM, Bill Gunshannon wrote:
>> Usenet feeds do not go to multiple sites in a single stream.
>> Connection is made to each peer and news transferred.
>
> It depends what type of Usenet feed it is.  Traditional UUCP & NNTP
> feeds are one-to-one.
>
> However there is multi-cast NNTP.  There used to be Usenet via satellite
> broadcast.

I ran a news server at the University I used to work at (frequently
made it into the top 100). Had a satellite feed from Cidera. Was
still really just point to point under the hood. Just asymmetrical
as we connected back to them over the Internet to confirm reception.

>
> So ... I'm convinced that Usenet is /capable/ of being one-to-many.

Theoretically, News could be sent as one way broadcasts but the
amount of data that would need to be sent would increase considerably.

bill

[Grant Taylor]

On 1/8/21 10:35 AM, Bill Gunshannon wrote:
> I ran a news server at the University I used to work at (frequently
> made it into the top 100). Had a satellite feed from Cidera.
> Was still really just point to point under the hood. Just asymmetrical
> as we connected back to them over the Internet to confirm reception.

The fact that each subscriber receives a separate stream in the
satellite broadcast really surprises me.

My understanding is that it was a single encrypted broadcast that
everybody received. People that had a current subscription had what was
necessary to decrypt the single broadcast to extract data and feed it to
their news server.

Duplicating that stream would be massively redundant data and extremely
inefficient.

> Theoretically, News could be sent as one way broadcasts but the amount
> of data that would need to be sent would increase considerably.

Why would sending a single broadcast increase the data?

[Bill Gunshannon]

On 1/8/21 12:44 PM, Grant Taylor wrote:
> On 1/8/21 10:35 AM, Bill Gunshannon wrote:
>> I ran a news server at the University I used to work at (frequently
>> made it into the top 100).  Had a satellite feed from Cidera. Was
>> still really just point to point under the hood.  Just asymmetrical as
>> we connected back to them over the Internet to confirm reception.
>
> The fact that each subscriber receives a separate stream in the
> satellite broadcast really surprises me.
>
> My understanding is that it was a single encrypted broadcast that
> everybody received.  People that had a current subscription had what was
> necessary to decrypt the single broadcast to extract data and feed it to
> their news server.
>
> Duplicating that stream would be massively redundant data and extremely
> inefficient.
>

Considering how trivial the data stream for ASCII text would be I would
think it was nothing compared to the streams coming from other satellite
services. I don't really knoiw a lot about the internals. It was a
black box system. They gave me a dish and a receiver and I had to make
a network connection back to them.Could be multiple people received a
single stream living with what i say down below.

>> Theoretically, News could be sent as one way broadcasts but the amount
>> of data that would need to be sent would increase considerably.
>
> Why would sending a single broadcast increase the data?

Lot's additional data to make it FEC. And then you have all the
requested re-transmissions from subscribers who, for one reason or
another missed an article. The more subscribers the larger the amount
of data needing to be resent.

I think multi-cast works best with data that can live with packet
loss. If you lose one or two packets from a five minute segment of
a movie or a sports event you likely won't notice it. If you lose
one packet from a Usenet feed you have completely lost at least one
article. Maybe more than that depending on how stuff is batched
and sent.

bill

[Andy Valencia]

Grant Taylor <gta...@tnetconsulting.net> writes:
> I thought that soundmodem was effectively a software TNC relying on the
> sound card. So ... even that doesn't avoid the TNC functionality.

I agree. You can call it a TNC function, but it's very different
from the behavior you'd see from an AX.25 TNC.

> Perhaps it's a start, as in prior art, to base new creations from that
> themselves function in lieu of a TNC.

I don't have any new ideas on how to FSK and build a framed packet.
So I'm OK with leveraging the existing code. And I'm OK with using
a sound card, because it's the only HW I have to do this anyway!

> > But then on top of it you run your own queues and logic for when to
> > key up.

> Queuing could mean a lot of different things. Is it messages waiting in
> line to go out? Or is it just waiting for clear air time to send a
> frame? Or is it something else.? That definitely starts stretching and
> changing definitions.

It's built around a formal TDM regime. Each station gets slots, and
that controls when they can transmit.

I purposely built the content level so you can have a packet for a given
chunk, and _while waiting_ for your slot to transmit it, see something
which obviates your need to put it on the air. And then cancel it out
of your queue, thus changing your behavior at your next transmit slot.
Sending a subsequent chunk, or handing back the remainder of your
time allocation.

Also using TDM, you transmit when your time slot(s) come up, in a regime
where you're guaranteed that--within your network--no other member will
be transmitting simultaneously. So no collisions, not even hidden
transmitter ones. Which, as I noted, my simulations made me aware of
how quickly the AX.25 air transmit algorithm can fail to scale.

You can reduce collisions with custom air collision parameters, but
you're vastly reducing the efficiency of your network--which is a
scaling failure again.

Andy

[Grant Taylor]

On 1/8/21 11:39 AM, Bill Gunshannon wrote:
> Lot's additional data to make it FEC.

I would think this would be a compounding / multiplicative effect for
each additional article stream.

> And then you have all the requested re-transmissions from subscribers
> who, for one reason or another missed an article.

I would expect it to be more along the lines of here it is, catch it or
get it elsewhere.

> The more subscribers the larger the amount of data needing to be
> resent.

I would expect that very little data would be re-sent. Either you got
it when it was originally sent or you didn't. If you didn't get it,
then it's up to you to get it elsewhere.

> I think multi-cast works best with data that can live with packet loss.

I feel like Usenet feeds very much qualify as this. Assuming that the
""packet is a message.

> If you lose one or two packets from a five minute segment of a movie
> or a sports event you likely won't notice it. If you lose one packet
> from a Usenet feed you have completely lost at least one article.

How is this different than a perfectly functional connection to a peer
not offering you an article, perhaps because their filter gobbled it up.

This is why you want to maintain multiple peers, so that you can get
articles from peer #2 that you didn't get from peer A.

> Maybe more than that depending on how stuff is batched and sent.

Yep.

[Grant Taylor]

On 1/8/21 9:10 PM, Andy Valencia wrote:
> I agree. You can call it a TNC function, but it's very different
> from the behavior you'd see from an AX.25 TNC.

Please elaborate.

My working understanding is that soundmodem would be comparable to a TNC
in KISS mode. Meaning that it's doing the modulation & demodulation and
framing.

I can see how soundmodem probably doesn't have more of the features
beyond KISS that a TNC would have, particularly a TNC with the Net ROM
in it.

> I don't have any new ideas on how to FSK and build a framed packet.
> So I'm OK with leveraging the existing code. And I'm OK with using
> a sound card, because it's the only HW I have to do this anyway!

*nod*nod*

> It's built around a formal TDM regime. Each station gets slots,
> and that controls when they can transmit.

I would be afraid that strict time division multiplexing would tend to
end up under utilizing the connection. Especially if you have multiple
stations, each with their TDM slot, that didn't need to transmit anything.

> I purposely built the content level so you can have a packet for a
> given chunk, and _while waiting_ for your slot to transmit it, see
> something which obviates your need to put it on the air. And then
> cancel it out of your queue, thus changing your behavior at your
> next transmit slot. Sending a subsequent chunk, or handing back the
> remainder of your time allocation.

Okay.

> Also using TDM, you transmit when your time slot(s) come up, in a
> regime where you're guaranteed that--within your network--no other
> member will be transmitting simultaneously. So no collisions, not
> even hidden transmitter ones.

I largely agree.

But I do think that there are scaling issues. Or at least issues that
need to be addressed related to physical scaling. At the moment I'm
thinking stations A, B, and C, in a line but far enough away that the
signal propagation time between A and C means that even when A completes
transmitting in it's time slot, it's signal can take long enough to
reach C that it's now into C's time slot. But, I suppose that you can
account for that in your scheduling algorithm.

> Which, as I noted, my simulations made me aware of how quickly the
> AX.25 air transmit algorithm can fail to scale.

I feel like stock AX.25 will have the same scaling problem that old
10Base{5,2,T} Ethernet had. More talkers means more collisions.

> You can reduce collisions with custom air collision parameters, but
> you're vastly reducing the efficiency of your network--which is a
> scaling failure again.

Yep.

[Bill Gunshannon]

On 1/11/21 12:55 AM, Grant Taylor wrote:
> On 1/8/21 11:39 AM, Bill Gunshannon wrote:
>> Lot's additional data to make it FEC.
>
> I would think this would be a compounding / multiplicative effect for
> each additional article stream.

Well, let's see... 5-10% extra bits over having to resend the entire
article because you missed one packet.

>
>> And then you have all the requested re-transmissions from subscribers
>> who, for one reason or another missed an article.
>
> I would expect it to be more along the lines of here it is, catch it or
> get it elsewhere.

If I have to have a more reliable feed to fill in the gaps what is the
advantage of taking the unreliable multi-cast feed?

>
>> The more subscribers the larger the amount of data needing to be resent.
>
> I would expect that very little data would be re-sent.  Either you got
> it when it was originally sent or you didn't.  If you didn't get it,
> then it's up to you to get it elsewhere.

See above. There isn't a system in place to request particular
individual articles. If you miss an article how would you even
know of its existence to request it? And a feed missing multiple
articles is really pretty worthless.

>
>> I think multi-cast works best with data that can live with packet loss.
>
> I feel like Usenet feeds very much qualify as this.  Assuming that the
> ""packet is a message.

But, the packet is not an article. Articles vary in size and consist
of a lot of packets. Packets are individually identifiable. Articles
are not identifiable until they have been received and are known to be
complete.

>
>> If you lose one or two packets from a five minute segment of a movie
>> or a sports event you likely won't notice it.  If you lose one packet
>> from a Usenet feed you have completely lost at least one article.
>
> How is this different than a perfectly functional connection to a peer
> not offering you an article, perhaps because their filter gobbled it up.

That's why most admins have more than one feed. What if the
multi-cast feed filter gobbles up an article? In either case,
what if an upstream site gobbled up the article. There is more
to running a successful Usenet site than most people think. I
did it for a long time. it's a labor of love because you never
really get any credit for the accomplishment. Only complaints
when things go wrong like an article being missing. :-)

>
> This is why you want to maintain multiple peers, so that you can get
> articles from peer #2 that you didn't get from peer A.

And one needs to select reliable peers. I fear the multi-cast
would soon find itself with no subscribers. Especially when
you realize that even if it worked you would still need direct
peer to peer connections to send your traffic out. back when
bandwidth was an issue this might have been of more value (thus
the reason we had our Cidera feed) but today with traffic being
much lower volume and bandwidth being orders of magnitude more
than it was it just isn't of any value.

>
>> Maybe more than that depending on how stuff is batched and sent.
>
> Yep.

bill

[Andy Valencia]

Grant Taylor <gta...@tnetconsulting.net> writes:
> My working understanding is that soundmodem would be comparable to a TNC
> in KISS mode. Meaning that it's doing the modulation & demodulation and
> framing.

KISS still leaves the queues and all decisions on when/how to key up
down in the TNC. If you want a packet to transmit, you have to
push it down to the KISS TNC. When/if it transmits is entirely opaque to
you. If you see a packet which tells you your transmission is redundant,
you have no way to tell if it's still in the queue--or to cancel it.

If you have any sort of higher level regime to guide when to key up,
there's no way to tell the TNC about it.

> I can see how soundmodem probably doesn't have more of the features
> beyond KISS that a TNC would have, particularly a TNC with the Net ROM
> in it.

Because the queues and TX decisions are up on your host, you have full
control over all of the issues.

Hypothetically, you could add lots of protocol to the KISS standard
to address this. But it's much less simple--and almost any modern CPU
doesn't need the offload anyway.

> I would be afraid that strict time division multiplexing would tend to
> end up under utilizing the connection. Especially if you have multiple
> stations, each with their TDM slot, that didn't need to transmit anything.

Yes, you've exactly put your finger on why I spend a LOT of time on
the protocol design! Can I make it not suck? But my simulations
of current TNC air usage tell me that sucks, too, which convinced
me to try my hand at it.

> But I do think that there are scaling issues. Or at least issues that
> need to be addressed related to physical scaling. At the moment I'm
> thinking stations A, B, and C, in a line but far enough away that the
> signal propagation time between A and C means that even when A completes
> transmitting in it's time slot, it's signal can take long enough to
> reach C that it's now into C's time slot. But, I suppose that you can
> account for that in your scheduling algorithm.

Yes, you're exactly thinking into the design space along my lines.

> > Which, as I noted, my simulations made me aware of how quickly the
> > AX.25 air transmit algorithm can fail to scale.

> I feel like stock AX.25 will have the same scaling problem that old
> 10Base{5,2,T} Ethernet had. More talkers means more collisions.

Although CSMA/CD at least had the *CD* part to much more efficiently
back off. There were some studies done which showed that old ethernet
was quite non-intuitively efficient even on a heavily used wire. Like
into ninety-something percentile utilization.

> Yep.
> Grant. . . .

Thanks for your comments, much appreciated (and motivating).

[Grant Taylor]

On 1/11/21 6:37 AM, Bill Gunshannon wrote:
> Well, let's see... 5-10% extra bits over having to resend the entire
> article because you missed one packet.

I think that we are talking past each other.

My understanding of (the germane portion of) your statement was about
multiple subscribers having independent feeds vs re-using a common feed.

I agree that adding 5-10% extra bits (per feed) to provide some
redundancy to avoid loosing part of the feed is a good idea.

I think this applies to any and all feeds, be it one shared feed or
multiple non-shared feeds.

> If I have to have a more reliable feed to fill in the gaps what is
> the advantage of taking the unreliable multi-cast feed?

You touched on it below. Bulk inexpensive (faster) feed for (hopefully)
80% (or more) of the traffic. Reducing the demand on the (slower) more
expensive feed.

> See above. There isn't a system in place to request particular
> individual articles. If you miss an article how would you even know
> of its existence to request it?

You quite likely wouldn't.

> And a feed missing multiple articles is really pretty worthless.

I disagree.

> But, the packet is not an article. Articles vary in size and
> consist of a lot of packets. Packets are individually identifiable.
> Articles are not identifiable until they have been received and are
> known to be complete.

I agree that there are technical differences. However, the packet
effectively becomes an article.

It really didn't matter if an individual identifiable packet was
corrupted. Chances are quite good that it would result in the loss of
an article. Given the historic one-way nature of satellite
transmission, you couldn't effectively ask for retransmission of the
packet anyway. Thus you still lost the article.

> That's why most admins have more than one feed.

Yep.

Get 80% (or more) of the bulk traffic via the inexpensive and possibly
somewhat unreliable feed so that you only need to get 20% (or less) more
expensive and more reliable feed.

> What if the multi-cast feed filter gobbles up an article? In either
> case, what if an upstream site gobbled up the article.

As you say, that's (one of the reasons) why you want multiple feeds.

> There is more to running a successful Usenet site than most people
> think.

Yep.

> I did it for a long time. it's a labor of love because you never
> really get any credit for the accomplishment.

How is this any different than running a DNS / email / web / ... server?
;-)

> Only complaints when things go wrong like an article being missing.
> :-)

Isn't that the truth.

> And one needs to select reliable peers. I fear the multi-cast
> would soon find itself with no subscribers. Especially when you
> realize that even if it worked you would still need direct peer to peer
> connections to send your traffic out. back when bandwidth was an issue
> this might have been of more value (thus the reason we had our Cidera
> feed) but today with traffic being much lower volume and bandwidth
> being orders of magnitude more than it was it just isn't of any value.

Yep.

One reason to use something like this today would be if the satellite
feed got articles to you sooner than other peers. Possibly because of
fewer hops (peers) for the articles to pass through.

Another reason might be if the satellite feed was full Usenet feed,
including binary, when other peers were not full feeds.

[Grant Taylor]

On 1/11/21 7:29 AM, Andy Valencia wrote:
> If you have any sort of higher level regime to guide when to key up,
> there's no way to tell the TNC about it.

I wonder if one could hack soundmodem (et al.) to allow the computer to
physically control the keying via another port, be it serial or GPIO
with appropriate support circuitry.

I could see a hat for a Pi that connected to microphone in port on a
radio and had another port to hook the microphone to. Thus the Pi could
control keying via GPIO and still function as passthrough for normal mic
usage.

> Because the queues and TX decisions are up on your host, you have
> full control over all of the issues.

*nod*

> Hypothetically, you could add lots of protocol to the KISS standard
> to address this. But it's much less simple--and almost any modern
> CPU doesn't need the offload anyway.

I wonder if 6PACK alters this any.

> Yes, you've exactly put your finger on why I spend a LOT of time on
> the protocol design! Can I make it not suck? But my simulations of
> current TNC air usage tell me that sucks, too, which convinced me to
> try my hand at it.

*nod*

I recently watched a video on ALOHAnet and I suspect it's worth 11
minutes of your time. I believe it specifically talked to utilizing
unused bandwidth in traditional TDM schemes. I don't recall the
particulars, but I do recall thinking it was novel.

Link - ALOHAnet: Grandfather of All Computer Networks - Computerphile
- https://www.youtube.com/watch?v=oKrUGRVwFBI

> Yes, you're exactly thinking into the design space along my lines.
>

> Although CSMA/CD at least had the *CD* part to much more efficiently
> back off. There were some studies done which showed that old ethernet
> was quite non-intuitively efficient even on a heavily used wire.
> Like into ninety-something percentile utilization.

I think that Ethernet's big problem started to arise from larger numbers
of users vs fewer (2) users nearly saturating the link.

> Thanks for your comments, much appreciated (and motivating).

You're welcome. This has been an interesting conversation.

[Bill Gunshannon]

On 1/11/21 2:40 PM, Grant Taylor wrote:
> On 1/11/21 6:37 AM, Bill Gunshannon wrote:
>> Well, let's see...  5-10% extra bits over having to resend the entire
>> article because you missed one packet.
>
> I think that we are talking past each other.
>
> My understanding of (the germane portion of) your statement was about
> multiple subscribers having independent feeds vs re-using a common feed.
>
> I agree that adding 5-10% extra bits (per feed) to provide some
> redundancy to avoid loosing part of the feed is a good idea.
>
> I think this applies to any and all feeds, be it one shared feed or
> multiple non-shared feeds.

Well, I think the actual problem is better explained by a comparison.
Think of your multi-cast idea a UDP. You send I receive. If I miss
one you don't know and I don't know. The data would be lost. Typical
NNTP Peering is like TCP. You connect, handshake and you then proceed
to send me sequenced data. if I miss one I can identify it and ask
for it to be resent so I have the complete stream. Every Article you
send is identified and acknowledged. No chance of data being missed
in transmission.

With the broadcast system you have no idea if I have received anything
and I have no idea whether or not you actually sent me anything.

>
>> If I have to have a more reliable feed to fill in the gaps what is the
>> advantage of taking the unreliable multi-cast feed?
>
> You touched on it below.  Bulk inexpensive (faster) feed for (hopefully)
> 80% (or more) of the traffic.  Reducing the demand on the (slower) more
> expensive feed.

Slower? My home internet connection is faster than and broader than
what the whole University had and that is including NNTP prior to the
Cidera feed. Times have changed.

>
>> See above.  There isn't a system in place to request particular
>> individual articles. If you miss an article how would you even know of
>> its existence to request it?
>
> You quite likely wouldn't.

You realize that would pretty much make Usenet useless. What good are
discussions with missing pieces?

>
>> And a feed missing multiple articles is really pretty worthless.
> I disagree.

See above. What if you had not received my last reply? You would
likely assume I had opted out of the conversation. Which would not
have been true.

>
>> But, the packet is not an article.  Articles vary in  size and consist
>> of a lot of packets.  Packets are individually identifiable. Articles
>> are not identifiable until they have been received and are known to be
>> complete.
>
> I agree that there are technical differences.  However, the packet
> effectively becomes an article.

No, the packet size is set by TCP/IP. A 5 meg article (yes, there
have been articles that big) is broken into smaller pieces using
TCP/IP. Even if we assume the sequence number can be determined
(I really have never looked in depth at multicast as Nothing I have
ever done used it) it is one way communications and I can't ask for
it to be retransmitted. Packet is lost, Article is lost. Feed has
a hole in it. Your users are very unhappy.

>
> It really didn't matter if an individual identifiable packet was
> corrupted.  Chances are quite good that it would result in the loss of
> an article.  Given the historic one-way nature of satellite
> transmission, you couldn't effectively ask for retransmission of the
> packet anyway.  Thus you still lost the article.

Which is why no site ever relied strictly on satellite for feed. You
still need old fashioned NNTP Peers.

>
>> That's why most admins have more than one feed.
>
> Yep.
>
> Get 80% (or more) of the bulk traffic via the inexpensive and possibly
> somewhat unreliable feed so that you only need to get 20% (or less) more
> expensive and more reliable feed.

20 years ago, maybe, but there is no "more expensive" feed today. A
satellite feed would cost more than even a cable modem connection
today and not even come close to the bandwidth. And a multicast
feed over the internet would cost the same as peer to peer sites.

>
>> What if the multi-cast feed filter gobbles up an article?  In either
>> case, what if an upstream site gobbled up the article.
>
> As you say, that's (one of the reasons) why you want multiple feeds.
>
>> There is more to running a successful Usenet site than most people think.
>
> Yep.
>
>> I did it for a long time.  it's a labor of love because you never
>> really get any credit for the accomplishment.
>
> How is this any different than running a DNS / email / web / ... server?
>  ;-)

email, DNS are requirements for pretty much any operation today. Some
would argue the same for a web server. Few if any would argue the same
for usenet.

>
>> Only complaints when things go wrong like an article being missing. :-)
>
> Isn't that the truth.
>
>> And one needs to select reliable peers.  I fear the multi-cast would
>> soon find itself with  no  subscribers.  Especially when you realize
>> that even if it worked you would still need direct peer to peer
>> connections to send your traffic out.  back when bandwidth was an
>> issue this might have been of more value (thus the reason we had our
>> Cidera feed) but today with traffic being much lower volume and
>> bandwidth being orders of magnitude more than it was it just isn't of
>> any value.
>
> Yep.
>
> One reason to use something like this today would be if the satellite
> feed got articles to you sooner than other peers.  Possibly because of
> fewer hops (peers) for the articles to pass through.

Even 20 years ago the satellite didn't get them there sooner. And,
today, there are no hops. Your peers connect directly to you. If
you pick good peers the satellite could end out sending a lot of
articles you already have. Depends on who they peer with.

>
> Another reason might be if the satellite feed was full Usenet feed,
> including binary, when other peers were not full feeds.

To be honest, I am not sure there even are satellite feed any more.
But I thought you were arguing for multicast which is not really the
same as satellite. multicast would still come in over your internet
connection. So, what would be the point?

bill

[Grant Taylor]

On 1/11/21 6:09 PM, Bill Gunshannon wrote:
> Well, I think the actual problem is better explained by a comparison.
> Think of your multi-cast idea a UDP. You send I receive. If I
> miss one you don't know and I don't know. The data would be lost.

Yes.

That's where having other peers comes into play.

> Typical NNTP Peering is like TCP.

My understanding is that the satellite based Usenet service was using
UUCP between the local receiver and the local news server. Though I
suppose it could be NNTP. I don't think it really matters.

> You connect, handshake and you then proceed to send me sequenced
> data. if I miss one I can identify it and ask for it to be resent
> so I have the complete stream. Every Article you send is identified
> and acknowledged. No chance of data being missed in transmission.

Ah, but there is a chance of data being missed in transmission.
Specifically "rain fade".

This is even more germane if the UUCP / NNTP is from the local receiver
and not from something across the satellite link. The UUCP / NNTP
stream would be perfectly fine. It's just that nothing would be sent
across it during rain fade. And you would not detect anything wrong.

> With the broadcast system you have no idea if I have received anything
> and I have no idea whether or not you actually sent me anything.

Correct.

> Slower? My home internet connection is faster than and broader than
> what the whole University had and that is including NNTP prior to
> the Cidera feed. Times have changed.

Yes. Now. 25-30 years ago, I highly doubt that was the case.

> You realize that would pretty much make Usenet useless. What good
> are discussions with missing pieces?

Nonsense. That's what having other peers is for.

Bulk throughput of 80-90 percent of the traffic directly from the
satellite service which gets to you before articles from other peers.

Then when the articles do get to you from other peers, they offer them
to you and your server politely declines the articles that it
successfully received from the satellite while still accepting the few
articles that didn't make it because of rain fade. Ultimately your end
users have no idea that different articles in a thread took different
paths and different amounts of time to get to the news server.

I think the phrase would be "eventually consistent" in today's parlance.

> See above. What if you had not received my last reply? You would
> likely assume I had opted out of the conversation. Which would not
> have been true.

See above. ;-)

> No, the packet size is set by TCP/IP. A 5 meg article (yes, there
> have been articles that big) is broken into smaller pieces using
> TCP/IP. Even if we assume the sequence number can be determined
> (I really have never looked in depth at multicast as Nothing I have
> ever done used it) it is one way communications and I can't ask for
> it to be retransmitted. Packet is lost, Article is lost.

I was making an analogy.

I maintain that a second peer back filling the small percentage of
articles that don't come via the first peer is acceptable.

> Feed has a hole in it. Your users are very unhappy.

See above. Your other, slower, peer filled the hole.

> Which is why no site ever relied strictly on satellite for feed.
> You still need old fashioned NNTP Peers.

I agree that you still need other peers. Be they NNTP or UUCP.

I still believe that any site really should have more than one peer.
There are still possibilities that articles could fail to come from one
peer for various different reasons. Be it rain fade, hardware failure,
or other problems.

> 20 years ago, maybe, but there is no "more expensive" feed today.

Ah, but there is.

There are free feeds and non-free feeds. Thus a directly "more
expensive" feed, even today.

> A satellite feed would cost more than even a cable modem connection
> today and not even come close to the bandwidth.

I agree that a cable modem /today/ probably has more bandwidth than a
satellite feed of /20+/ /years/ /ago/.

However I believe that a satellite feed can push *WAY* *MORE*
*BANDWIDTH* than a cable modem. Think about the number of high
definition movies that are being streamed on all the channels. IM(ns)HO
that /easily/ exceeds even the fastest cable modem today. We just don't
have access to modems that work that way any more.

There is also the difference in a feed that's one or two hops long via a
satellite vs a feed that's 8-12 hops long via other NNTP peers.

> And a multicast feed over the internet would cost the same as peer
> to peer sites.

I don't think that it's likely to get multicast to work across the
Internet for various reasons. However, I know that big news providers
used multicast in their LAN to exchange articles between servers. In
such cases, multicast is actually considerably better than multiple
individual peer-to-peer connections in that you only need to send the
multicast copy once vs one time for each peer-to-peeer connection.

> email, DNS are requirements for pretty much any operation today.
> Some would argue the same for a web server. Few if any would argue
> the same for usenet.

Fair.

> Even 20 years ago the satellite didn't get them there sooner.
> And, today, there are no hops. Your peers connect directly to you.

There most definitely are hops. Take a look at the Path: header. Each
additional hop in the path is a measurable delay.

> If you pick good peers the satellite could end out sending a lot of
> articles you already have. Depends on who they peer with.

True.

That's why I most often heard of satellite being used by people that
were many hops away from core hubs. Get a large bulk of traffic across
satellite and then get the rest over the 56 kbps / 1.544 Mbps links.

> To be honest, I am not sure there even are satellite feed any more.

There were not when I looked a few years ago.

> But I thought you were arguing for multicast which is not really the
> same as satellite. multicast would still come in over your internet
> connection. So, what would be the point?

No, I'm not arguing for multicast. I don't even think that multicast is
viable on the current Internet.

[Andy Valencia]

Grant Taylor <gta...@tnetconsulting.net> writes:
> > If you have any sort of higher level regime to guide when to key up,
> > there's no way to tell the TNC about it.

> I wonder if one could hack soundmodem (et al.) to allow the computer to
> physically control the keying via another port, be it serial or GPIO
> with appropriate support circuitry.

soundmodem is entirely software, so the computer has _always_ had
control of the TX line. These days I expect Raspberry Pi-ish devices
will dominate, which generally give you plenty of GPIO lines.

In any mobile client, you also need a notion of S/N from your decoder,
so you know when to initate a transition to a new connection point.
Neither soundmodem nor Direwolf provides this (and KISS has no place
to include such a metric), but I've spotted the code points where this
could be gleaned.

> I could see a hat for a Pi that connected to microphone in port on a
> radio and had another port to hook the microphone to. Thus the Pi could
> control keying via GPIO and still function as passthrough for normal mic
> usage.

I'm still curious how well these:

http://www.dorji.com/docs/data/DRA818V.pdf

might work in practice. My interest is towards fully integrated
solutions, not treating packet like a fringe Frankenstein mode.
I have some stuff breadboarded, but then turned my attention to the
protocol side. My first ideas didn't pass the laugh test under
simulation, which sent me back to add on an entire TDM layer.

Which means you can't use TNC's, nor KISS. A pity, but it doesn't
matter how easy it is to use something which doesn't work.

> I recently watched a video on ALOHAnet and I suspect it's worth 11
> minutes of your time. I believe it specifically talked to utilizing
> unused bandwidth in traditional TDM schemes. I don't recall the
> particulars, but I do recall thinking it was novel.

Oh yes, as an old networking guy, I read their papers when they first
came out. They were brilliant for pioneering in this space, and then
writing very approachable papers on the issues they found.

But, honestly, I don't recall them doing formal TDM allocations. I'll
swing back through the articles.

Thanks,
Andy

[Grant Taylor]

On 1/12/21 10:05 AM, Andy Valencia wrote:
> soundmodem is entirely software, so the computer has _always_ had
> control of the TX line.

This is one case where I think that automatic VOX activation is a good
thing.

> These days I expect Raspberry Pi-ish devices will dominate, which
> generally give you plenty of GPIO lines.

I completely agree.

> In any mobile client, you also need a notion of S/N from your decoder,
> so you know when to initate a transition to a new connection point.

Hum. I hadn't thought about that aspect of mobile packet.

Stationary packet would be a lot simpler. Though monitoring SNR can
still be important do to band fade. But, mobile packet would probably
be much worse as the mobile unit moves out of and into different
propagation areas.

> Neither soundmodem nor Direwolf provides this (and KISS has no place
> to include such a metric), but I've spotted the code points where
> this could be gleaned.

I wonder if this is one of the things that 6PACK might be better at.
I've not done any reading on 6PACK.

> I'm still curious how well these:
>
> http://www.dorji.com/docs/data/DRA818V.pdf
>
> might work in practice.

Intriguing.

> My interest is towards fully integrated solutions, not treating packet
> like a fringe Frankenstein mode. I have some stuff breadboarded,
> but then turned my attention to the protocol side. My first ideas
> didn't pass the laugh test under simulation, which sent me back to
> add on an entire TDM layer.
>
> Which means you can't use TNC's, nor KISS. A pity, but it doesn't
> matter how easy it is to use something which doesn't work.

#truth

> Oh yes, as an old networking guy, I read their papers when they
> first came out. They were brilliant for pioneering in this space,
> and then writing very approachable papers on the issues they found.
>
> But, honestly, I don't recall them doing formal TDM allocations.
> I'll swing back through the articles.

I'd have to re-watch the video to find what I was thinking of again.
(Maybe during lunch.) But I distinctly recall comments about how to
have multiple islands efficiently use the band, particularly when other
stations had nothing to transmit.

> Thanks,

You're welcome.

[j01]

On 1/7/2021 12:55 PM, Grant Taylor wrote:
> Hi,
>
> Is there anyone lurking in the packet radio newsgroups any more?
>
> I'm looking for someone to chat with about AX.25 / Net/ROM, particularly
> on Linux.
>
>
>

Aye. Love me some X.25, Amateur-Style :)

[j01]

Aye. Love me some X.25, Amateur Style

[Grant Taylor]

On 1/11/21 2:13 PM, Grant Taylor wrote:
> I recently watched a video on ALOHAnet and I suspect it's worth 11
> minutes of your time.  I believe it specifically talked to utilizing
> unused bandwidth in traditional TDM schemes.  I don't recall the
> particulars, but I do recall thinking it was novel.
>
> Link - ALOHAnet: Grandfather of All Computer Networks - Computerphile
>  - https://www.youtube.com/watch?v=oKrUGRVwFBI

I took a few minutes and re-watched the video. The method they used was
simply collision detection and random back off & retry.

[Andy Valencia]

Grant Taylor <gta...@tnetconsulting.net> writes:
> I took a few minutes and re-watched the video. The method they used was
> simply collision detection and random back off & retry.

Thanks--that matches my memory of what they used.

Actually, I don't think "collision detection" is the right term. They
would listen for a carrier, then key up after some interval of a clear
channel. CD is the technique for _while transmitting_ to detect that
somebody else keyed up too. I'm not aware of any good radio ways for
doing that (on Ethernet it was clever to think of it, but trivial to
implement).

[Grant Taylor]

On 1/13/21 10:09 AM, Andy Valencia wrote:
> Thanks--that matches my memory of what they used.

You're welcome.

> Actually, I don't think "collision detection" is the right term.
> They would listen for a carrier, then key up after some interval of
> a clear channel. CD is the technique for _while transmitting_ to
> detect that somebody else keyed up too. I'm not aware of any good
> radio ways for doing that (on Ethernet it was clever to think of it,
> but trivial to implement).

They were definitely doing (indirect) collision detection of what was
transmitted. It may have been more in conjunction with the central
system not transmitting an ACK because of garbled frames and original
transmitters timing out and re-transmitting.

But the original transmitters were able to deduce that their
transmission didn't make it through.

[Daniel]

Grant Taylor <gta...@tnetconsulting.net> writes:

> Hi,
>
> Is there anyone lurking in the packet radio newsgroups any more?
>
> I'm looking for someone to chat with about AX.25 / Net/ROM,
> particularly on Linux.

I have an interest in getting a HAM license and trying my hand at packet
radio. It's a fascinating subject to me. I will read this thread with
great interest.

--
Daniel
Visit me at: gopher://gcpp.world

[Andy Valencia]

Daniel <m...@sci.fidan.com> writes:
> I have an interest in getting a HAM license and trying my hand at packet
> radio.

Welcome, Daniel! Feel free to post any questions as you prep for the exam.

[Grant Taylor]

Hi Daniel,

On 2/2/21 1:14 AM, Daniel wrote:
> I have an interest in getting a HAM license and trying my hand at
> packet radio. It's a fascinating subject to me. I will read this
> thread with great interest.

I encourage you to get your license.

Feel free to ask -- either here or email -- if you have questions. I'm
happy to (try to) help.

I can highly recommend the ARRL's license manual. -- Since you're just
getting started, you are looking at Technician.

[Daniel]

Thanks guys, appreciate the helpful.

I do intend to do so, yes. One of my best bros suggested the very same
manual. He's been a ham guy since the late 70s and takes pride in his
speed morse skills.

I intend to engage everyone I can to get going. Just yesterday we were
talking about methods of deploying antennas without causing HOA
headaches (for him) and an eyesore (for me on my yard).

I'm thinking about running mine along the top of my fence horizontally.

Now's the time, I think, to get a license.

[OldbieOne]

Grant Taylor wrote in message ...

>Hi,
>
>Is there anyone lurking in the packet radio newsgroups any more?
>
>I'm looking for someone to chat with about AX.25 / Net/ROM, particularly
>on Linux.

Hi Grant,

OG USENET poster/ham radio enthusiast here. Just got back on for the first
time since 2003 when my ISP killed it's NNTP servers.

Never done packet, but it's something I want to try, which is why I'm here.

I will probably use an old laptop runing some flavor of *nix, so I'd love
some thoughts/suggestions/tips.

--
OldbieOne

[Grant Taylor]

On 4/8/21 4:44 PM, OldbieOne wrote:
> Hi Grant,

Hi OldbieOne,

> OG USENET poster/ham radio enthusiast here. Just got back on for the
> first time since 2003 when my ISP killed it's NNTP servers.

My ISP's loss of NNTP service is how I got started hosting NNTP /
Usenet. (The local university they got their service from discontinued
the service.) I've since moved and now run a couple of other Usenet
servers. All because someone else discontinued the service. Go figure.

> Never done packet, but it's something I want to try, which is why
> I'm here.

I've not done anything with packet yet. I'm still doing some reading
and learning.

I have picked up an RTL-SDR BLOG (brand) SDR and gotten it to work on my
contemporary Gentoo Linux box. The various command line utilities and
gqrx (GUI with waterfall) all worked for me. Life got busy and the
equipment is waiting on me to get back to it.

> I will probably use an old laptop runing some flavor of *nix, so I'd
> love some thoughts/suggestions/tips.

I'm *FAR* from being qualified to offer any suggestions. But, see
above, I do have some hints at life and will be trying packet Any Day Now™.

[OldbieOne]

Grant Taylor wrote in message ...

I don't have an SDR yet, but was planning on using Baofeng UV5R. I am more
than a little curious about them though, so will probably pick one up when
they're available again on Amazon. Right now it seems they're out of stock
with no ETA.

I work in the tech world, so should have acquired one years ago! But I gave
up radio as a hobby in my late 20's, came back into it in my 30's restoring
antique radios, and now returning to amateur radio.

Been feeling pretty nostalgic lately, which is why I came back on USENET
after finding a free servie that allows you to post up to 40 messages a day.
No crossposting, and no binaries, but since I'm doing this right now from a
Windows 95/DOS PC I just built for retro-gaming, and am using Outlook
Express 4 to connect to the USENET service, it's a miracle I can even make a
server connection in the days of SSL now!

--
OldbieOne
The Guy Who Tells It Like It Is (TM)

[Grant Taylor]

On 4/8/21 5:55 PM, OldbieOne wrote:
> I don't have an SDR yet, but was planning on using Baofeng UV5R.

Hey, if it works for you, go for it.

I watched a few videos from ModernHam KN4MKB
(https://www.youtube.com/c/ModernHam/videos) who got started with a
Baofeng and did a lot of cool things with it. He might have some tips &
tricks.

I got started in 2m with my Wouxun HT. I'm planing on seeing if I can
decode packet with it too.

> I am more than a little curious about them though, so will probably
> pick one up when they're available again on Amazon. Right now it
> seems they're out of stock with no ETA.

ACK

> I work in the tech world, so should have acquired one years ago! But
> I gave up radio as a hobby in my late 20's, came back into it in my
> 30's restoring antique radios, and now returning to amateur radio.

Eh.... Just because you work in tech doesn't mean that you necessarily
want to recreate in tech too. Maybe you do, maybe you don't.

> Been feeling pretty nostalgic lately, which is why I came back on
> USENET after finding a free servie that allows you to post up to 40
> messages a day. No crossposting, and no binaries, but since I'm doing
> this right now from a Windows 95/DOS PC I just built for retro-gaming,
> and am using Outlook Express 4 to connect to the USENET service, it's
> a miracle I can even make a server connection in the days of SSL now!

:-)

Sounds like AIOE and looking at your Path: header, yep your message came
from AIOE. There are some other options if you ever run into the 40
messages per day. I don't personally know if it's 40 per calendar day
or 24 hour period. If you ever want to know about other options, drop
me an email. I'm more active in the Usenet community than I am in radio
at the moment, including running a pair of Usenet servers.

Yes, SSL ~> TLS is marching on and going to become more of a problem for
older systems. There are some options. Stunnel and a couple other
proxies come to mind. There's always setting up your own server that
doesn't require TLS. }:-)

[OldbieOne]

Grant Taylor wrote in message ...

>On 4/8/21 5:55 PM, OldbieOne wrote:
>> I don't have an SDR yet, but was planning on using Baofeng UV5R.
>
>Hey, if it works for you, go for it.
>
>I watched a few videos from ModernHam KN4MKB
>(https://www.youtube.com/c/ModernHam/videos) who got started with a
>Baofeng and did a lot of cool things with it. He might have some tips &
>tricks.
>
>I got started in 2m with my Wouxun HT. I'm planing on seeing if I can
>decode packet with it too.

Should be able to. The Wouxun isn't far removed from the Baofengs of this
world. They're practically one in the same circuit-wise, I'm led to
understand.

>> I am more than a little curious about them though, so will probably
>> pick one up when they're available again on Amazon. Right now it
>> seems they're out of stock with no ETA.
>
>ACK

Story of my life. I always catch on after the fact, lol!

>> I work in the tech world, so should have acquired one years ago! But
>> I gave up radio as a hobby in my late 20's, came back into it in my
>> 30's restoring antique radios, and now returning to amateur radio.
>
>Eh.... Just because you work in tech doesn't mean that you necessarily
>want to recreate in tech too. Maybe you do, maybe you don't.

I do, but there's always some shiny new thing that comes along that draws me
to it like a magpie, and I keep forgetting everything that's on my "want
one" list.

>> Been feeling pretty nostalgic lately, which is why I came back on
>> USENET after finding a free servie that allows you to post up to 40
>> messages a day. No crossposting, and no binaries, but since I'm doing
>> this right now from a Windows 95/DOS PC I just built for retro-gaming,
>> and am using Outlook Express 4 to connect to the USENET service, it's
>> a miracle I can even make a server connection in the days of SSL now!
>
>:-)
>
>Sounds like AIOE and looking at your Path: header, yep your message came
>from AIOE. There are some other options if you ever run into the 40
>messages per day. I don't personally know if it's 40 per calendar day
>or 24 hour period. If you ever want to know about other options, drop
>me an email. I'm more active in the Usenet community than I am in radio
>at the moment, including running a pair of Usenet servers.

Yup, AIOE. It's better than nothing, but seems most of the groups are empty.
Thanks for the offer, I'll probably take you up on that and send you an
email for advice on what's out there as an alternative to AIOE.

>Yes, SSL ~> TLS is marching on and going to become more of a problem for
>older systems. There are some options. Stunnel and a couple other
>proxies come to mind. There's always setting up your own server that
>doesn't require TLS. }:-)

True. I had a perl based NNTP server I wrote decades ago now, but it was
only capable of hosting private groups. Don't even know where I'd start in
2021!

[Daniel]

Grant Taylor <gta...@tnetconsulting.net> writes:

> Hi,
>
> Is there anyone lurking in the packet radio newsgroups any more?
>
> I'm looking for someone to chat with about AX.25 / Net/ROM,
> particularly on Linux.

I am here, a new one actually. I don't have my ham radio license yet,
but plan on studying for it shortly.

I have a big interest in packet radio and getting started hosting my own
bbs and messaging rig. I know some hobbyists working on adapting some
interesting technologies to improve it.

[OldbieOne]

"Daniel" <m...@sci.fi.dan.com> wrote in message
news:87zgukk...@sci.fi.dan.com...

It's something I plan on getting back into, but I was a child when I last
used packet, and it was someone else's setup, so I'm going to have to learn
the setup, etc as well.

Guess we're all in the same boat here