[pskmail] Re: Call for comments on open protocols
- From: "Rud Merriam" <k5rud@xxxxxxxx>
- To: "'Rein Couperus'" <rein@xxxxxxxxxxxx>, "'Walt DuBose'" <dubose@xxxxxxxxx>
- Date: Sat, 24 Feb 2007 11:08:01 -0600
Hi Rein,
My apologies if you were bothered by my use of the term naïve. Taking your
statement on your web site at face value it is misleading. I have seen
similar statements by other hams. Practice with space probes, digital TV,
etc, also show the value of using FEC.
ARQ introduces throughput degradation, also. Is there any information on the
tradeoffs between FEC and AQR?
Just as adaptive techniques are used with ARQ others can be used with FEC.
Getting into DTN touches a key consideration because it approaches the
problem from a different perspective. Packet erasure handling raises other
questions that may lead to different lower level protocol solutions.
Interesting work at
http://planete-bcast.inrialpes.fr/rubrique.php3?id_rubrique=5 uses FEC at
the packet level to reconstruct dropped packets.
Rud Merriam K5RUD
ARES AEC Montgomery County, TX
http://over50.k5rud.us/wiki/
-----Original Message-----
From: Rein Couperus [mailto:rein@xxxxxxxxxxxx]
Sent: Saturday, February 24, 2007 3:16 AM
To: Walt DuBose; Rud Merriam
Cc: linlink@xxxxxxxxxx; pskmail@xxxxxxxxxxxxx
Subject: Re: Call for comments on open protocols
All this is theory.
FEC is going to bring relief in only 1% of practical cases only, viz. in the
extreme case when you are on the borderline between copy and no copy. In
normal practise (and we have gathered some during 2 year's operation of
pskmail servers), you are either fighing the S9+20 pactor station which
comes on your frequency , or 80 dB QSB in multi-path situations, or S9+20
static crashes in case of QRN. Sometimes these 3 effects appear
simultaneously. This is nothing where FEC can help out, maybe only when you
use extreme time diversity. And with extreme I mean at least 5 seconds
apart, equally sending everything twice a priory.
If practise is naive, than this is naive.
The gaps in the stream are not something you can repair with some degree of
FEC, they are just too wide. The only way is a lossless arq mechanism,
where the holes in the stream are detected and filled in afterwards. One
thing we have not yet added to the protocol is memory receive, which
combines the information in the frames to build a valid one in case also the
repeat is damaged. This, combined with a block length which adapts to the
qrm characteristics guarantees an optimum adaptation to the actual situation
on the band.
FEC is only going to slow all this down. We have compared MT63-2k with PSK63
and found no increase in throughput on the band. And if you compare the
bandwidth/throughput efficiency ratio the MT63-2 case looses by a factor of
10. It is just a case of throwing precious spectrum away.
Summing it up, we'd better worry about DTN (delay tolerant network)
technologies which work around qrm and qsb than about scratching the last dB
out of the protocol.
73,
Rein EA/PA0R/P
Other related posts:
