Johnathan Corgan wrote: > Johnathan Corgan wrote: > >> There is an alternative that Eric and I have conceived that would be >> a temporary workaround. It would not solve the original problem but >> would at least allow upper level protocols that do re-transmission to >> recover from the failure. I'll talk about that once I've got it >> coded, tested, and into my developer branch. > > This has been implemented, checked into a developer branch, and > successfully tested. > > A new command-line parameter has been added to both tunnel.py and > benchmark_tx.py, --use-whitener-offset. It defaults to false so existing > behavior is unchanged. > > A new 4-bit field has been added to the existing packet header, above > the 12 bits already used for the length field. This field holds an > integer (range 0-15) that represents an offset value. > > When transmitting, this value (which defaults to zero), determines the > offset into the whitening array which is XORed with the payload data to > form the whitened data for submission to the modulator. > > When the --use-whitener-offset option is set, this offset is > incremented for each transmitted packet, and stored in the new 4 bit > field. Thus, even identical packets, when transmitted successively, > result in completely different "on the air" data. > > The receiver extracts the offset value from the header and uses it to > recover the original data. In the case where the offset option is not > used, the offset is always set to zero, so the receiver behavior is then > unchanged. > > If a received packet fails CRC because of some pattern-specific > synchronization problem, and if the upper protocol layers cause a > retransmission, then the re-transmitted packet will have a different > whitened bit pattern, allowing it to go through. > > While this doesn't solve the underlying problem, whatever that may be, > it does give a workaround for users who have to get past this issue > while we are debugging it. Unfortunately this workaround is only for > people who are using higher level protocols which use retransmission to > recover from link errors. This of course includes TCP, which is the > underlying protocol for the majority of users. > > I've verified that my prior failure test cases now "work", in the sense > that the upper layers just continue as if the bad packets were dropped > due to noise. This includes ssh, scp, ftp, and https, each of which I > could reliably make to fail with the old code and now succeed with the > new workaround. > > The code is in the developer branch: > > http://gnuradio.org/svn/gnuradio/branches/developers/jcorgan/digital > > ...which is based on a snapshot of the trunk as of a couple days ago. > > We haven't decided whether this will make it into the trunk. We'd much > rather make a real fix. > > Johnathan Corgan > Corgan Enterprises LLC > http://corganenterprises.com >
Yay- congratulations- transferred 100MB successfully and all of my 'stumbler' packets- even with UDP. I'm going to continue work on the 8b/10b, because I still think that's the closest 'real' solution to the issue- and the overhead isn't as severe as repeating 1500 byte packets- especially when you consider that ethernet and many other mediums use this specific implementation of 8b/10b. Worst case, it can be an option in the python that most people can leave turned off. FYI: Am achieving nearly 100kb/s with -r 800k on a BasicTX _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
