This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Tom Tsou tom at tsou.ccOn Wed, Oct 12, 2016 at 10:51 AM, Vadim Yanitskiy <axilirator at gmail.com> wrote: >> I think the puncturing code should be part of the library (otherwise >> every user will have to reimplement the same thing again and again). > > I am agree with you. We recently discussed this question with Tom Tsou. > He said, that there was some performance related reasons to perform > puncturing inside both gsm0503_pdtch_encode() / gsm0503_pdtch_decode(). >From an API standpoint, it makes no difference and makes sense to move the puncturing into the library. Regarding the implementation, there is a significant difference. Puncturing and convolutional coding are inherently discrete steps. It is possible, as in the library, to reconstruct the non-punctured bit vector while feeding into the Viterbi at same time, but the downside of this approach is reduced optimization (or potential optimization). The reason is that the Viterbi always runs at the full non-punctured rate and can be implemented with well known trellis coding optimizations. Puncturing is a completely separate algorithm from the Viterbi, and integrating them together provides no performance benefit at best and degradation at worst. That said, the one advantage to puncturing inside the Viterbi is for handling continuous non-fixed length codes. But, those codes are not used by GSM or 3GPP in general, so they are not relevant here. In summary, my concern is about the implementation and not the API. Perhaps we could pull the puncturing into the library as Max suggests. Then, separately, consider performance changes to the internal puncturing and Viterbi implementations. -TT