"Joseph Fenn" wrote in message
va.net...
Well for one simple thing you set your "MAXFRAMES" to 7.
Set PACLEN to 255. That wont change your baud rate but providing
signals are good it will give you the max thruput on msg traffic.
Joe/ABM6JF


Some experiments over an obstructed path on 70 cm,
9600 baud, suggest maxframe 16 - 32 and paclen of
60 -100 give the maximum throughput. Note that this
is an implementation of AX.25 that uses slow-start
and selective reject / out-of-order frame recovery.

Across a "very good" line of sight path, maxframe of
32 and paclen of 1024 did best.

These were point-to-point links, half duplex.
About 10 MB of data were used for the tests.

--

... Hank

Hank: http://horedson.home.att.net
W0RLI: http://w0rli.home.att.net

"Hank Oredson" wrote in message
...

Does Flexnet implement large window / slow-start / selective nak?
If not, it cannot come near the best transfer rate over a poor channel.

I don't have any idea, Hank. It's a proprietary protocol, not open-source
and there is not much discussion of FlexNet's internal workings that I would
be privy to. If I was privy to discussion of it, there's question as to how
much I would understand. It's a freebee, download a copy and see what it
looks like to you. You'd know what you were seeing better than I would. Get
two FlexNets talking to each other, see what they do if you are interested.

Over a good channel most anything will give near max transfer rate.


Most anything *can*, but in most cases with traditional static-parameter
setups, hams tend to play with the bare minimum required to get them on the
air, and leave the rest at default values. Those default values are
compromise settings, optimized for general use-ability under almost any
operating conditions.

FlexNet's AI will optimize your link parameters for you, in fact it does so
continuously, as far as I can tell. If everybody is using FlexNet, then you
don't have to worry about parameters causing problems and everybody is
running at or near optimum all the time, automagically. TXDELAY is really
about the only link parameter that you can maladjust and mess up. There's
not much left to argue about after that, except SSID's I guess.

User-settable parameters include: Mycall/SSIDs, TXDelay, Speed.

Some of the drivers have additional parms such as COM port numbers,
addresses, etc..

Note: There is an option on FlexNet nodes to disallow connects from stations
running too much TXD, sending them a short message about the problem and
disconnecting. It detects TXD, and shuts out stations using more than 100 ms
unnecessary TXD. This is not used much here in the US, but personally I like
it. - If you have too little TXD, you cannot connect. If you have too much,
the node tells to to take a hike. It makes it easy to sneak up on an optimum
setting, and keeps anybody from operating with really bad TXD, slowing
things down for everyone else.

The main thing about a packet net is that it is a social critter. You have
to figure on a small number of experts, not nearly enough to go around and
hold everybody's hand. By using expert system software though, appliance
operators like myself can at least simulate having an expert sitting in at
our packet stations. FlexNet greatly simplifies the setup procedure and at
the same time vastly improves average link performance for individuals, and
by that token for entire networks.

Charles Brabham, N5PVL

"Hank Oredson" wrote in message
...

Does Flexnet implement large window / slow-start / selective nak?
If not, it cannot come near the best transfer rate over a poor channel.

I don't have any idea, Hank. It's a proprietary protocol, not open-source
and there is not much discussion of FlexNet's internal workings that I would
be privy to. If I was privy to discussion of it, there's question as to how
much I would understand. It's a freebee, download a copy and see what it
looks like to you. You'd know what you were seeing better than I would. Get
two FlexNets talking to each other, see what they do if you are interested.

Over a good channel most anything will give near max transfer rate.


Most anything *can*, but in most cases with traditional static-parameter
setups, hams tend to play with the bare minimum required to get them on the
air, and leave the rest at default values. Those default values are
compromise settings, optimized for general use-ability under almost any
operating conditions.

FlexNet's AI will optimize your link parameters for you, in fact it does so
continuously, as far as I can tell. If everybody is using FlexNet, then you
don't have to worry about parameters causing problems and everybody is
running at or near optimum all the time, automagically. TXDELAY is really
about the only link parameter that you can maladjust and mess up. There's
not much left to argue about after that, except SSID's I guess.

User-settable parameters include: Mycall/SSIDs, TXDelay, Speed.

Some of the drivers have additional parms such as COM port numbers,
addresses, etc..

Note: There is an option on FlexNet nodes to disallow connects from stations
running too much TXD, sending them a short message about the problem and
disconnecting. It detects TXD, and shuts out stations using more than 100 ms
unnecessary TXD. This is not used much here in the US, but personally I like
it. - If you have too little TXD, you cannot connect. If you have too much,
the node tells to to take a hike. It makes it easy to sneak up on an optimum
setting, and keeps anybody from operating with really bad TXD, slowing
things down for everyone else.

The main thing about a packet net is that it is a social critter. You have
to figure on a small number of experts, not nearly enough to go around and
hold everybody's hand. By using expert system software though, appliance
operators like myself can at least simulate having an expert sitting in at
our packet stations. FlexNet greatly simplifies the setup procedure and at
the same time vastly improves average link performance for individuals, and
by that token for entire networks.

Charles Brabham, N5PVL

"charlesb" wrote in message
m...

"Hank Oredson" wrote in message
...

Does Flexnet implement large window / slow-start / selective nak?
If not, it cannot come near the best transfer rate over a poor channel.

I don't have any idea, Hank. It's a proprietary protocol, not open-source
and there is not much discussion of FlexNet's internal workings that I would
be privy to.

Oh. Never mind.

I run only code that I write myself, based on open and documented
standards. FlexNet is therefore totally uninteresting. But in any case,
it cannot get more throughput than what I mentioned in my other reply.
Did I mention that the code we run here also has adaptive parameter
settings? This stuff is not rocket science, and one can in fact do as well
as can be done using open protocols. No need to get stuck with a
protocol that is basically unsupported and undocumented.

--

... Hank

Hank: http://horedson.home.att.net
W0RLI: http://w0rli.home.att.net

"charlesb" wrote in message
m...

"Hank Oredson" wrote in message
...

Does Flexnet implement large window / slow-start / selective nak?
If not, it cannot come near the best transfer rate over a poor channel.

I don't have any idea, Hank. It's a proprietary protocol, not open-source
and there is not much discussion of FlexNet's internal workings that I would
be privy to.

Oh. Never mind.

I run only code that I write myself, based on open and documented
standards. FlexNet is therefore totally uninteresting. But in any case,
it cannot get more throughput than what I mentioned in my other reply.
Did I mention that the code we run here also has adaptive parameter
settings? This stuff is not rocket science, and one can in fact do as well
as can be done using open protocols. No need to get stuck with a
protocol that is basically unsupported and undocumented.

--

... Hank

Hank: http://horedson.home.att.net
W0RLI: http://w0rli.home.att.net

"Hank Oredson" wrote in message
...

I run only code that I write myself, based on open and documented
standards. FlexNet is therefore totally uninteresting.

Well, that is your personal preference... You understand of course that with
most hams, the personal preference will run to issues like ease of use,
utility and performance. Most of them are unaware of programming - related
"protocol war" issues. They just want good performing software, easy to set
up and run.

But in any case,
it cannot get more throughput than what I mentioned in my other reply.

I'll have to take your word for that. You generally know what you are
talking about, so it's not like it's a big stretch for me to do so, eh?

Did I mention that the code we run here also has adaptive parameter
settings?

No, I don't remember seeing anything about it, though I do remember reading
somewhere that the adaptive parameter concept has been around for quite a
while. I briefly studied expert system programming in college, many years
ago so that concept can't be called "new" either... Putting the two of them
together in order to make packet radio both simpler and better performing is
a relatively new thing though, brought to us by the folks in the FlexNet
group.

This stuff is not rocket science, and one can in fact do as well
as can be done using open protocols.

In theory, I'm sure it could... So far in the real world; no bananna.

No need to get stuck with a
protocol that is basically unsupported and undocumented.

FlexNet is supported and documented (for users) and there is a FlexNet API
(for programmers)... That's all the support and documentation I have any
need for, and much more than most hams would care about. They just want to
get on the air and operate, and don't put in a lot of time worrying about
whether they can diddle with the code.

For my part, I am glad that FlexNet cannot be diddled with. Just look at the
mess with *NOS and Linux to see why. Too many junior programmers out there,
all full of clever new ways to screw up. I know for sure that if I busted my
hiney for months to produce some good software, I would not want a bunch of
pencil-necked geeks transmogrifying it and putting it out with my name still
on it, upsetting and confusing users with dozens of bogus versions of the
software that might or might not work. That is basically the position of the
authors of FlexNet, and it makes very good sense.

There have been two concentrated efforts to replicate FlexNet's A.I. so far,
with AGW packet engine (proprietary) being a much higher quality, popular
product than X-Net (open-source), which worked out to be too buggy,
disorganized and complicated to gain any popularity. Neither one of these
succeeded in replicating the performance edge you get with FlexNet, though
AGW comes close, from what I understand. So while it may be true that
FlexNet's adaptive parameter system is not "rocket science", apparently
folks have been having a harder time trying to replicate its function than
you seem to expect.

The big drawback with AGW packet engine is the price tag. Why pay extra to
use an imperfect knock-off of higher quality, better performing software
(FlexNet) that you can get for free?

AGW gets a lot of LandLine-Lid types to use his software by making it easy
to set up a gateway with AGW... The FlexNet people on the other hand do not
encourage people to hook FlexNet up to non-ham stuff at all- which makes it
less popular with the "non-ham" types, I suppose. You *can* of course hook
FlexNet up to non-ham stuff but nobody is encouraged to, or given a helpful
"how-to" tips on how to do it by the authors. There are of course
LandLine-Lid FlexNet users, but generally I have found that there are very
few of them. FlexNet is not "PC" among the LLL "non-ham" set so they
generally avoid it, going for AGW instead. Conversely, "non-ham" stuff is
not "PC" within most of the FlexNet community either, so it all works out fo
r the best.

Remember that the question about throughput was put forward by someone who
identified themself as a beginner. He didn't mention anything about wanting
to re-write the code. Currently there are only a two packages that offer
optimised performance coupled with easy, simple setup that would fill that
persons' stated requirements. There's FlexNet, and it's expensive knock-off
AGW... Naturally, I recommended FlexNet to my fellow ham.

Charles Brabham, N5PVL

"Hank Oredson" wrote in message
...

I run only code that I write myself, based on open and documented
standards. FlexNet is therefore totally uninteresting.

Well, that is your personal preference... You understand of course that with
most hams, the personal preference will run to issues like ease of use,
utility and performance. Most of them are unaware of programming - related
"protocol war" issues. They just want good performing software, easy to set
up and run.

But in any case,
it cannot get more throughput than what I mentioned in my other reply.

I'll have to take your word for that. You generally know what you are
talking about, so it's not like it's a big stretch for me to do so, eh?

Did I mention that the code we run here also has adaptive parameter
settings?

No, I don't remember seeing anything about it, though I do remember reading
somewhere that the adaptive parameter concept has been around for quite a
while. I briefly studied expert system programming in college, many years
ago so that concept can't be called "new" either... Putting the two of them
together in order to make packet radio both simpler and better performing is
a relatively new thing though, brought to us by the folks in the FlexNet
group.

This stuff is not rocket science, and one can in fact do as well
as can be done using open protocols.

In theory, I'm sure it could... So far in the real world; no bananna.

No need to get stuck with a
protocol that is basically unsupported and undocumented.

FlexNet is supported and documented (for users) and there is a FlexNet API
(for programmers)... That's all the support and documentation I have any
need for, and much more than most hams would care about. They just want to
get on the air and operate, and don't put in a lot of time worrying about
whether they can diddle with the code.

For my part, I am glad that FlexNet cannot be diddled with. Just look at the
mess with *NOS and Linux to see why. Too many junior programmers out there,
all full of clever new ways to screw up. I know for sure that if I busted my
hiney for months to produce some good software, I would not want a bunch of
pencil-necked geeks transmogrifying it and putting it out with my name still
on it, upsetting and confusing users with dozens of bogus versions of the
software that might or might not work. That is basically the position of the
authors of FlexNet, and it makes very good sense.

There have been two concentrated efforts to replicate FlexNet's A.I. so far,
with AGW packet engine (proprietary) being a much higher quality, popular
product than X-Net (open-source), which worked out to be too buggy,
disorganized and complicated to gain any popularity. Neither one of these
succeeded in replicating the performance edge you get with FlexNet, though
AGW comes close, from what I understand. So while it may be true that
FlexNet's adaptive parameter system is not "rocket science", apparently
folks have been having a harder time trying to replicate its function than
you seem to expect.

The big drawback with AGW packet engine is the price tag. Why pay extra to
use an imperfect knock-off of higher quality, better performing software
(FlexNet) that you can get for free?

AGW gets a lot of LandLine-Lid types to use his software by making it easy
to set up a gateway with AGW... The FlexNet people on the other hand do not
encourage people to hook FlexNet up to non-ham stuff at all- which makes it
less popular with the "non-ham" types, I suppose. You *can* of course hook
FlexNet up to non-ham stuff but nobody is encouraged to, or given a helpful
"how-to" tips on how to do it by the authors. There are of course
LandLine-Lid FlexNet users, but generally I have found that there are very
few of them. FlexNet is not "PC" among the LLL "non-ham" set so they
generally avoid it, going for AGW instead. Conversely, "non-ham" stuff is
not "PC" within most of the FlexNet community either, so it all works out fo
r the best.

Remember that the question about throughput was put forward by someone who
identified themself as a beginner. He didn't mention anything about wanting
to re-write the code. Currently there are only a two packages that offer
optimised performance coupled with easy, simple setup that would fill that
persons' stated requirements. There's FlexNet, and it's expensive knock-off
AGW... Naturally, I recommended FlexNet to my fellow ham.

Charles Brabham, N5PVL

"charlesb" wrote

The big drawback with AGW packet engine is the price tag. Why pay extra to
use an imperfect knock-off of higher quality, better performing software
(FlexNet) that you can get for free?

AGW's price tag is on the order of a six-pack of beer. That's hardly a drawback.
The old free AGW is all anyone needs for 9600 and less speeds. I'm assuming
you're talking about the IP part, and not the new version he's selling.

AGW gets a lot of LandLine-Lid types to use his software by making it easy
to set up a gateway with AGW...

I used AGW to do APRS with a soundcard, and never used the IP part of it.
The IP part isn't very useful past Windows 95, and who runs that anymore? The
non-IP part was fun to program against.

Remember that the question about throughput was put forward by someone who
identified themself as a beginner. He didn't mention anything about wanting
to re-write the code. Currently there are only a two packages that offer
optimised performance coupled with easy, simple setup that would fill that
persons' stated requirements. There's FlexNet, and it's expensive knock-off
AGW... Naturally, I recommended FlexNet to my fellow ham.

The obvious other question, is what data do you have that needs throughput?

When everyone realized that all they were getting on the BBS was out of band
mods and people on soap boxes complaining about whatever they were
complaining about, then it all caved-in on itself, as a worthless endeavor.

Until we hear what the data is, our definition of good throughput may be morse
code at 5 WPM, or it may be a WiFi at 50 Mbps.

"charlesb" wrote

The big drawback with AGW packet engine is the price tag. Why pay extra to
use an imperfect knock-off of higher quality, better performing software
(FlexNet) that you can get for free?

AGW's price tag is on the order of a six-pack of beer. That's hardly a drawback.
The old free AGW is all anyone needs for 9600 and less speeds. I'm assuming
you're talking about the IP part, and not the new version he's selling.

AGW gets a lot of LandLine-Lid types to use his software by making it easy
to set up a gateway with AGW...

I used AGW to do APRS with a soundcard, and never used the IP part of it.
The IP part isn't very useful past Windows 95, and who runs that anymore? The
non-IP part was fun to program against.

Remember that the question about throughput was put forward by someone who
identified themself as a beginner. He didn't mention anything about wanting
to re-write the code. Currently there are only a two packages that offer
optimised performance coupled with easy, simple setup that would fill that
persons' stated requirements. There's FlexNet, and it's expensive knock-off
AGW... Naturally, I recommended FlexNet to my fellow ham.

The obvious other question, is what data do you have that needs throughput?

When everyone realized that all they were getting on the BBS was out of band
mods and people on soap boxes complaining about whatever they were
complaining about, then it all caved-in on itself, as a worthless endeavor.

Until we hear what the data is, our definition of good throughput may be morse
code at 5 WPM, or it may be a WiFi at 50 Mbps.

"Gene Storey" wrote in message
news:N4Aqb.963$643.658@okepread03...
"charlesb" wrote

When everyone realized that all they were getting on the BBS was out of
band
mods and people on soap boxes complaining about whatever they were
complaining about, then it all caved-in on itself, as a worthless
endeavor.

That's not just a lie, but a silly, destructive lie. The content of packet
messages compare very well with - this newsgroup for example - and had
nothing to do with the decline of the US packet network. Some of them are
much more interesting than what I generally find here.

Other parts of the world that were not infected with LandLine Lid stations
did just fine while the infested US packet net steadily declined. The hams
were reading and posting the same bulletins and messages in both networks.
Think it through, and figure it out for yourself.

I'm sorry but this is a matter of historical fact, not opinion. If you want
to smear the hobby with lies, I will slap you down for it. The last thing we
need here is another anti-ham troll.

You can take your anti-ham attitude, Gene, fold it up so that it's all sharp
little corners, and stick it where the sun don't shine. If you do not like
the hobby, get out of it.

Charles Brabham, N5PVL