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 _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
