|
Mode for Best Throughput?
Hello Everyone,
I'm very new to packet radio/digital communications and am trying to climb up the learning curve too fast. It hurts :-) My question is: What protocol/mode will give me the best data throughput using 9600 baud packet on VHF or UHF? Using standard AX.25 protocol in connected mode I'm able to achieve about 1000 baud throughput. Unconnected I can get about 4000 baud, but of course that is without any error checking or correction. I'd like to get maximum data transfer between two stations...network operations are secondary. I'm guessing using KISS mode would allow me to get better throughput because of the lack of AX.25 overhead, but I'm pretty clueless on how to actually do anything with KISS mode. How do I implement something like TCP/IP over radio? Is that any better than AX.25? Less overhead? I've downloaded JNOS, but I'm not sure what exactly it is or what to do with it. Any suggestions or help would be appreciated. I've searched the web for info on running different protocols in KISS mode, but everything I find seems like it was written for computer scientists in the 1980s. Thanks! Andy KB9JOZ |
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 ************************************************** ** * Ham KH6JF AARS/MARS ABM6JF QCWA WW2 VET WD RADIO * ************************************************** ** |
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 ************************************************** ** * Ham KH6JF AARS/MARS ABM6JF QCWA WW2 VET WD RADIO * ************************************************** ** |
Hi Andy
I started typing this and realised you said "packet" protocol. Thought I'd leave it in (below) anyway! - Assuming you want max throughput on a dedicated channel and dont care about long TX times - Make sure your maxframes is something huge (7 is max) - Get your paclen as long as you can. Although 255 is the normal maximum I did some experiments at 768 some years ago (max for my TNC2 in KISS mode) - Get your TXDelay and TXTail as small as it can go. - Make sure your error rate from low signal/interference/over deviation etc is nil - Compress the data stream (grin) Kiss mode by itself doesnt give you better throughput. It simply makes the TNC a little more "dumb" and allows the host to control it more/better. TCP/IP (I think) over packet adds a little more overhead to the packet length so AX25 "connected" mode is likely to be a little faster. I use to play packet a lot but not for a while. Cant quite remember it all sorry! I havent seen any implementations using KISS try and send raw data (ie not AX25 in some form) but I guess that you could certainly modem out a data stream and have some kind of error correction built into the boxes at each end. You might be able to use the EC in file transfer protocols like ZModem but it may get upset at not having a full duplex connection. Might be an interesting piece of code to write. Sorry for being short on this. Ask if you want more info. Cheers Bob VK2YQA ================================================== =============== Have a look at Wyman1x. http://www.svs.net/wyman/examples/hdsstv It is a one way digital code stream with redundancy/checksums built into the stream. You encode a binary file to a WAV then play it through your radio. The page above looks like a SSTV piece of sowftare but you can send/recxeive any kind of digital data. There are some graphs on throughput etc possible There is code for both Windoze and Linux available I'm very new to packet radio/digital communications and am trying to climb up the learning curve too fast. It hurts :-) My question is: What protocol/mode will give me the best data throughput using 9600 baud packet on VHF or UHF? Using standard AX.25 protocol in connected mode I'm able to achieve about 1000 baud throughput. Unconnected I can get about 4000 baud, but of course that is without any error checking or correction. I'd like to get maximum data transfer between two stations...network operations are secondary. I'm guessing using KISS mode would allow me to get better throughput because of the lack of AX.25 overhead, but I'm pretty clueless on how to actually do anything with KISS mode. How do I implement something like TCP/IP over radio? Is that any better than AX.25? Less overhead? I've downloaded JNOS, but I'm not sure what exactly it is or what to do with it. Any suggestions or help would be appreciated. I've searched the web for info on running different protocols in KISS mode, but everything I find seems like it was written for computer scientists in the 1980s. Thanks! Andy KB9JOZ -- (The reply address is broken. Put bcnoop in front of the at!) |
Hi Andy
I started typing this and realised you said "packet" protocol. Thought I'd leave it in (below) anyway! - Assuming you want max throughput on a dedicated channel and dont care about long TX times - Make sure your maxframes is something huge (7 is max) - Get your paclen as long as you can. Although 255 is the normal maximum I did some experiments at 768 some years ago (max for my TNC2 in KISS mode) - Get your TXDelay and TXTail as small as it can go. - Make sure your error rate from low signal/interference/over deviation etc is nil - Compress the data stream (grin) Kiss mode by itself doesnt give you better throughput. It simply makes the TNC a little more "dumb" and allows the host to control it more/better. TCP/IP (I think) over packet adds a little more overhead to the packet length so AX25 "connected" mode is likely to be a little faster. I use to play packet a lot but not for a while. Cant quite remember it all sorry! I havent seen any implementations using KISS try and send raw data (ie not AX25 in some form) but I guess that you could certainly modem out a data stream and have some kind of error correction built into the boxes at each end. You might be able to use the EC in file transfer protocols like ZModem but it may get upset at not having a full duplex connection. Might be an interesting piece of code to write. Sorry for being short on this. Ask if you want more info. Cheers Bob VK2YQA ================================================== =============== Have a look at Wyman1x. http://www.svs.net/wyman/examples/hdsstv It is a one way digital code stream with redundancy/checksums built into the stream. You encode a binary file to a WAV then play it through your radio. The page above looks like a SSTV piece of sowftare but you can send/recxeive any kind of digital data. There are some graphs on throughput etc possible There is code for both Windoze and Linux available I'm very new to packet radio/digital communications and am trying to climb up the learning curve too fast. It hurts :-) My question is: What protocol/mode will give me the best data throughput using 9600 baud packet on VHF or UHF? Using standard AX.25 protocol in connected mode I'm able to achieve about 1000 baud throughput. Unconnected I can get about 4000 baud, but of course that is without any error checking or correction. I'd like to get maximum data transfer between two stations...network operations are secondary. I'm guessing using KISS mode would allow me to get better throughput because of the lack of AX.25 overhead, but I'm pretty clueless on how to actually do anything with KISS mode. How do I implement something like TCP/IP over radio? Is that any better than AX.25? Less overhead? I've downloaded JNOS, but I'm not sure what exactly it is or what to do with it. Any suggestions or help would be appreciated. I've searched the web for info on running different protocols in KISS mode, but everything I find seems like it was written for computer scientists in the 1980s. Thanks! Andy KB9JOZ -- (The reply address is broken. Put bcnoop in front of the at!) |
Best protocol for scraping up a bit more throughput at 9.6kb? That would be
RadioMirror, the terrestrial multicast protocol. At 1.2kb, RadioMirror can move better than 20 MB of data a day. At 9.6kb, you would do much better than that, of course. Neither AX25 or TCPIP packet can keep up with RadioMirrors' throughput. Additionally, RadioMirror is an unconnected mode, so you can distribute the data to an unlimited number of receiving stations, or just one. That's up to you. To investigate RadioMirror, see the "Tutorial" section at USPN: http://www.uspacket.net and also read the article "Emergency Digital Communications - Another Angle" in USPN's "Library" section. These articles represent the single most comprehensive source of information on setting up and operating this advanced digital mode. RadioMirror may or may not be right for your application, but it is hoped that you will enjoy reading about it, in any case. I have tested RadioMirror at 1.2kb and was astounded at it's ability to move a lot of data quickly. Good luck! Charles Brabham, N5PVL Director: USPacket.Net http://www.uspacket.net "Andy Knitt" wrote in message ... Hello Everyone, I'm very new to packet radio/digital communications and am trying to climb up the learning curve too fast. It hurts :-) My question is: What protocol/mode will give me the best data throughput using 9600 baud packet on VHF or UHF? Using standard AX.25 protocol in connected mode I'm able to achieve about 1000 baud throughput. Unconnected I can get about 4000 baud, but of course that is without any error checking or correction. I'd like to get maximum data transfer between two stations...network operations are secondary. I'm guessing using KISS mode would allow me to get better throughput because of the lack of AX.25 overhead, but I'm pretty clueless on how to actually do anything with KISS mode. How do I implement something like TCP/IP over radio? Is that any better than AX.25? Less overhead? I've downloaded JNOS, but I'm not sure what exactly it is or what to do with it. Any suggestions or help would be appreciated. I've searched the web for info on running different protocols in KISS mode, but everything I find seems like it was written for computer scientists in the 1980s. Thanks! Andy KB9JOZ |
"Andy Knitt" wrote in message ... Hello Everyone, I'm very new to packet radio/digital communications and am trying to climb up the learning curve too fast. It hurts :-) My question is: What protocol/mode will give me the best data throughput using 9600 baud packet on VHF or UHF? Earlier I responded with information about RadioMirror, the multicast protocol for terrestrial packet that offers truly outstanding throughput... - But Andy may prefer a connected protocol. In that case, FlexNet's AX25 stack will give him the best throughput, leaving traditional AX25 and IP systems in the dust. A standard TNC has close to 100 different parameter settings that influence how well the TNC communicates with the computer over the serial link, and how it performs on the air when hooked up to a radio. Even experts are sometimes confused by some of the more esoteric link parameters, so many of these are left at factory default values that are not what you could call "optimum" but rather represent a compromise. FlexNet takes full control of all of those link parameters, adjusting them on a dynamic, minute to minute basis for optimum throughput. With traditional systems, you painstakingly adjust the TNC parameters once (static parameters) and hope that it will not be too inefficient. With FlexNet, the parameters are watched and adjusted on a minute by minute basis (dynamic parameter settings controlled by the software's A.I.) so that at any given minute, your TNC is perfectly adjusted to the conditions it finds with a connection. End result? Significantly better throughput than any other connected mode protocol available to hams. You have to enter your callsign, your data rate and your TXDELAY... All other parameters are controlled by the FlexNet A.I.. (Artificial Intelligence) It's like having a little TNC expert hiding in your computer, who constantly, expertly adjusts your TNC for you as you operate. This type of software is referred to as an "Expert System", and is the only software of this type that is wrtitten for hams. (That I am aware of.) Over a good RF path, FlexNet will send up to seven 256 PACLEN packets at a time. (Per key-up of the Xmitter) which gives it a data stream almost as continuous as RadioMirror! That's nice, but this is even better: When the link conditions deteriorate (static, other traffic, etc. ) then FlexNet will "automagically" back off on its radical TNC parameters until it no longer experiences retries, thereby giving you the maximum possible throughput under ANY operating conditions, good or bad - All the time! When conditions improve again, FlexNet notices within a few minutes and will again open up the TNC parms "like a hose" to give you the very best throughput under whatever operating conditions the software encounters. You can run IP over FlexNet of course, but the increased overhead will slow you down a little. If you don't have a specific need for it, you will be better off without it. To find info about FlexNet, look under "Packet Software" in USPN's "Links" page, and see the Flex32 tutorial in our "Turorial" section. Good Luck! RadioMirror and FlexNet are your two best options for maximum throughput at 9.6kb. Let us know how it goes! Charles Brabham, N5PVL Director: USPacket.Net http://www.uspacket.net |
"Andy Knitt" wrote in message ... Hello Everyone, I'm very new to packet radio/digital communications and am trying to climb up the learning curve too fast. It hurts :-) My question is: What protocol/mode will give me the best data throughput using 9600 baud packet on VHF or UHF? Earlier I responded with information about RadioMirror, the multicast protocol for terrestrial packet that offers truly outstanding throughput... - But Andy may prefer a connected protocol. In that case, FlexNet's AX25 stack will give him the best throughput, leaving traditional AX25 and IP systems in the dust. A standard TNC has close to 100 different parameter settings that influence how well the TNC communicates with the computer over the serial link, and how it performs on the air when hooked up to a radio. Even experts are sometimes confused by some of the more esoteric link parameters, so many of these are left at factory default values that are not what you could call "optimum" but rather represent a compromise. FlexNet takes full control of all of those link parameters, adjusting them on a dynamic, minute to minute basis for optimum throughput. With traditional systems, you painstakingly adjust the TNC parameters once (static parameters) and hope that it will not be too inefficient. With FlexNet, the parameters are watched and adjusted on a minute by minute basis (dynamic parameter settings controlled by the software's A.I.) so that at any given minute, your TNC is perfectly adjusted to the conditions it finds with a connection. End result? Significantly better throughput than any other connected mode protocol available to hams. You have to enter your callsign, your data rate and your TXDELAY... All other parameters are controlled by the FlexNet A.I.. (Artificial Intelligence) It's like having a little TNC expert hiding in your computer, who constantly, expertly adjusts your TNC for you as you operate. This type of software is referred to as an "Expert System", and is the only software of this type that is wrtitten for hams. (That I am aware of.) Over a good RF path, FlexNet will send up to seven 256 PACLEN packets at a time. (Per key-up of the Xmitter) which gives it a data stream almost as continuous as RadioMirror! That's nice, but this is even better: When the link conditions deteriorate (static, other traffic, etc. ) then FlexNet will "automagically" back off on its radical TNC parameters until it no longer experiences retries, thereby giving you the maximum possible throughput under ANY operating conditions, good or bad - All the time! When conditions improve again, FlexNet notices within a few minutes and will again open up the TNC parms "like a hose" to give you the very best throughput under whatever operating conditions the software encounters. You can run IP over FlexNet of course, but the increased overhead will slow you down a little. If you don't have a specific need for it, you will be better off without it. To find info about FlexNet, look under "Packet Software" in USPN's "Links" page, and see the Flex32 tutorial in our "Turorial" section. Good Luck! RadioMirror and FlexNet are your two best options for maximum throughput at 9.6kb. Let us know how it goes! Charles Brabham, N5PVL Director: USPacket.Net http://www.uspacket.net |
"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 |
"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 |
"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 |
"charlesb" wrote
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. You're the one calling everyone a LID if they don't fit into your narrow definition of what a "ham" is. Don't try to foist that off on others. |
"charlesb" wrote
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. You're the one calling everyone a LID if they don't fit into your narrow definition of what a "ham" is. Don't try to foist that off on others. |
| All times are GMT +1. The time now is 01:38 PM. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
RadioBanter.com