[Date Prev][Date Next][Thread Prev][Thread Next] - [Date Index][Thread Index][Author Index]

Re: Re: [sarex] BBS's versus DIGIPEATERS in space

> I believe the problem is the 280 disconnects you listed below, caused by
> poor operators not monitoring the downlink, and not waiting for the
> connected station to disconnect.  

While I agree with what I think your point was ( ie that is that 
there is a place for both digipeaters and BBS's , and if people 
operated with consideration of others, both could coexist), and 
I agree that the large number of disconnects is indeed 
indicative of the real problem,  I wouldn't blame all the 
disconnects on  "poor operators".  Obviously disconnects 
during the middle of a connection are hopeless waste of 
bandwidth, but I've seen flurries of more than 15 disconnects 
coming from one of the "expert" controllers on a single MIR 
transmission.  Ie although it would be ideal if people would 
wait for the connected station to sign off, everyone, including 
the experts realize that if they wait, their odds of getting in are 
greatly reduced.  People are guessing when the other station 
will disconnect, then send out flurries of multiple connect 
requests one after the other without waiting for a response, in 
hopes that one will be heard above the noise.  When the 
experts do this, it's not surprising that the poor operators copy 
the technique.   The real problem is that there are just a lot of 
people trying to do the same thing, and that the TNC's seem 
to reward poor operating techniques in that they will accept a 
connect request after it decides that it has disconnected, but 
before it has sent the notification.  I'd estimate that 90% of the 
time new connections occur prior to the time that final 
disconnect message comes down, if it comes at all.  
   But again, the problem is not the mode, but number of 
people.  The only reason that UI digipeating "seems" to work 
better is that you've got 90% of the people sending out 
connect requests.  If those people were all sending out  UI 
packets rather than connect requests,  there would be a hard 
time getting those through too.  The only reason we see so 
many connect requests is that they are so short that they can 
sneak in, but if everyone starts sending packets with 
information, the system could be even more clogged.  Of 
course, you can squeeze a lot of info into a short APRS style 
UI packet, but many question whether this is real 
communication (I mean compared to sending complete 
sentences via either UI or connected states).  I prefer the UI 
digipeat approach myself (with a few words of communication) 
, but I think there is a place for both approaches, and both can 

  Two other comments.  The statistics Bob quotes are only 
indicative of the packets that have gotten through.  They 
ignore the fact that it may have taken 200 tries to get those 2 
packets through.  Ie no way would I call ANY mode 100% 
efficient. Connect requests are easy to get through because 
they are short.  For a realistic comparison, you have to 
compare equal strength stations trying to use the various 
modes, and look at the amount of bandwidth used to get the 
info accross.  You can't just look at the 2 packets that get 
through and say you have 100% efficiency. 
  The other thing is that if your information can fit into one 
packet, then UI is a good technique, but if you have multiple 
lines of info, the connected state is MUCH more efficient.  It is 
naive to think that UI techniques could be used for lengthy 
exchanges with the crew. Particularly since you would never 
know if the packets went through unless you send acks back, 
and then you are right back where we started.  Bottom line is 
that a STRONG station can use either technique very 
efficiently, and that weak stations will have trouble with both 
techniques.  A weak station will probably have MORE 
success using UI, but only because he will send out many 
many packets before he sees a bounce, adding to the overall 

| Bill Jones, N3JLQ,Sweden, Maine  |
| wejones@megalink.net             |
| http://www.megalink.net/~wejones |

Via the amsat-bb mailing list at AMSAT.ORG courtesy of AMSAT-NA.
To unsubscribe, send "unsubscribe amsat-bb" to Majordomo@amsat.org