12 Oct
2016
12 Oct
'16
7:51 p.m.
Hi Max,
Unfortunately I could not find any tests for the code
in
question so the only way to test it is by:
I uploaded tests recently. You can find them here:
https://gerrit.osmocom.org/#/c/933/4/tests/coding/coding_test.c
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().
With best regards,
Vadim Yanitskiy.
12 Oct
12 Oct
7:58 p.m.
New subject: OsmoBTS -> libosmogsm code migration
Is there some microbenchmark available? Perhaps we can use it to improve
generated code?
On 10/12/2016 07:51 PM, Vadim Yanitskiy wrote:
Hi Max,
--
Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
Unfortunately I could not find any tests for the
code in
question so the only way to test it is by:
I uploaded tests recently. You can find them here:
https://gerrit.osmocom.org/#/c/933/4/tests/coding/coding_test.c
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().
With best regards,
Vadim Yanitskiy.
8:10 p.m.
New subject: OsmoBTS -> libosmogsm code migration
I don't know. Maybe Tom has one?
Otherwise I can try to write myself.
Tom Tsou wrote:
There was a discussion many years ago about
puncturing
inside or outside of the convolutional coder loops. I preferred
separating puncturing and convolutional coding because of efficiency.
Using discrete implementations allows faster implementations.
With best regards,
Vadim Yanitskiy.
2016-10-13 0:58 GMT+07:00 Max <msuraev(a)sysmocom.de>de>:
Is there some microbenchmark available? Perhaps we can
use it to improve
generated code?
On 10/12/2016 07:51 PM, Vadim Yanitskiy wrote:
Hi Max,
--
Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
Unfortunately I could not find any tests for the
code in
question so the only way to test it is by:
I uploaded tests recently. You can find them here:
https://gerrit.osmocom.org/#/c/933/4/tests/coding/coding_test.c
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().
With best regards,
Vadim Yanitskiy. 
8:54 p.m.
New subject: OsmoBTS -> libosmogsm code migration
On Wed, Oct 12, 2016 at 10:58 AM, Max <msuraev(a)sysmocom.de> wrote:
Is there some microbenchmark available? Perhaps we can
use it to improve
generated code?
Potential Viterbi optimization using SIMD methods is substantial as I
demonstrated many years ago. The implementation does require
separation of puncturing and Viterbi. Unfortunately, the has code
experienced code rot since then. Admittedly, I accept much of that
blame.
=================================================
[+] Testing: GSM TCH/AFS 6.7
[.] Specs: (N=4, K=5, recursive, flushed, punctured)
[.] Input length : ret = 140 exp = 140 -> OK
[.] Output length : ret = 448 exp = 448 -> OK
[.] Performance benchmark:
[..] Encoding / Decoding 800000 bursts on 8 thread(s):
[..] Testing base:
[..] Elapsed time....................... 4.320001 secs
[..] Rate............................... 25.925920 Mbps
[..] Testing SIMD:
[..] Elapsed time....................... 0.458272 secs
[..] Rate............................... 244.396341 Mbps
[..] Speedup............................ 9.426718
http://lists.osmocom.org/pipermail/openbsc/2014-April/007365.html
-TT
14 Oct
14 Oct
12:40 p.m.
New subject: OsmoBTS -> libosmogsm code migration
Hi Tom,
Thank you for explainations!
Potential Viterbi optimization using SIMD methods is
substantial as I
demonstrated many years ago. The implementation does require
separation of puncturing and Viterbi. Unfortunately, the has code
experienced code rot since then. Admittedly, I accept much of that
blame.
I think it would be really good to have/use your Viterbi implementation
inside the libosmocoding. Regarding to some remarks to your code, I am
ready to fix them (such as malloc -> talloc).
Moreover, recently I had a conversation with Alexander Chemeris. He also
mentioned your implementation, which would be better to use in embedded
platforms (such as UmSITE) due to performance reasons.
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.
So, my suggestion is to:
1) Extend your code with encoding capabilities.
2) Merge Viterbi transcoder with the libosmocoding.
3) Merge libosmocoding into libosmocore as a sub-library
or spawn a separate repository.
Any opinions?
With best regards,
Vadim Yanitskiy.
2016-10-13 1:54 GMT+07:00 Tom Tsou <tom(a)tsou.cc>cc>:
> On Wed, Oct 12, 2016 at 10:58 AM, Max <msuraev(a)sysmocom.de> wrote:
> > Is there some microbenchmark available? Perhaps we can use it to improve
> > generated code?
>
Potential Viterbi optimization using SIMD methods is
substantial as I
demonstrated many years ago. The implementation does require
separation of puncturing and Viterbi. Unfortunately, the has code
experienced code rot since then. Admittedly, I accept much of that
blame.
>
> =================================================
> [+] Testing: GSM TCH/AFS 6.7
> [.] Specs: (N=4, K=5, recursive, flushed, punctured)
> [.] Input length : ret = 140 exp = 140 -> OK
> [.] Output length : ret = 448 exp = 448 -> OK
>
> [.] Performance benchmark:
> [..] Encoding / Decoding 800000 bursts on 8 thread(s):
> [..] Testing base:
> [..] Elapsed time....................... 4.320001 secs
> [..] Rate............................... 25.925920 Mbps
> [..] Testing SIMD:
> [..] Elapsed time....................... 0.458272 secs
> [..] Rate............................... 244.396341 Mbps
> [..] Speedup............................ 9.426718
>
> http://lists.osmocom.org/pipermail/openbsc/2014-April/007365.html
>
> -TT
>
12:52 p.m.
New subject: OsmoBTS -> libosmogsm code migration
1) Extend your code with encoding capabilities.
Ah, I just found it inside your repository.
With best regards,
Vadim Yanitskiy.
2016-10-14 17:40 GMT+07:00 Vadim Yanitskiy <axilirator(a)gmail.com>om>:
> Hi Tom,
>
> Thank you for explainations!
>
> > Potential Viterbi optimization using SIMD methods is substantial as I
> > demonstrated many years ago. The implementation does require
> > separation of puncturing and Viterbi. Unfortunately, the has code
> > experienced code rot since then. Admittedly, I accept much of that
> > blame.
>
> I think it would be really good to have/use your Viterbi implementation
> inside the libosmocoding. Regarding to some remarks to your code, I am
> ready to fix them (such as malloc -> talloc).
>
> Moreover, recently I had a conversation with Alexander Chemeris. He also
> mentioned your implementation, which would be better to use in embedded
> platforms (such as UmSITE) due to performance reasons.
>
> > 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.
>
> So, my suggestion is to:
>
1) Extend your code with encoding capabilities.
> 2) Merge Viterbi transcoder with the libosmocoding.
> 3) Merge libosmocoding into libosmocore as a sub-library
> or spawn a separate repository.
>
> Any opinions?
>
>
> With best regards,
> Vadim Yanitskiy.
>
> 2016-10-13 1:54 GMT+07:00 Tom Tsou <tom(a)tsou.cc>cc>:
>
>> On Wed, Oct 12, 2016 at 10:58 AM, Max <msuraev(a)sysmocom.de> wrote:
>> > Is there some microbenchmark available? Perhaps we can use it to improve
>> > generated code?
>>
>> Potential Viterbi optimization using SIMD methods is substantial as I
>> demonstrated many years ago. The implementation does require
>> separation of puncturing and Viterbi. Unfortunately, the has code
>> experienced code rot since then. Admittedly, I accept much of that
>> blame.
>>
>> =================================================
>> [+] Testing: GSM TCH/AFS 6.7
>> [.] Specs: (N=4, K=5, recursive, flushed, punctured)
>> [.] Input length : ret = 140 exp = 140 -> OK
>> [.] Output length : ret = 448 exp = 448 -> OK
>>
>> [.] Performance benchmark:
>> [..] Encoding / Decoding 800000 bursts on 8 thread(s):
>> [..] Testing base:
>> [..] Elapsed time....................... 4.320001 secs
>> [..] Rate............................... 25.925920 Mbps
>> [..] Testing SIMD:
>> [..] Elapsed time....................... 0.458272 secs
>> [..] Rate............................... 244.396341 Mbps
>> [..] Speedup............................ 9.426718
>>
>> http://lists.osmocom.org/pipermail/openbsc/2014-April/007365.html
>>
>> -TT
>>
>
>
12 Oct
12 Oct
8:47 p.m.
New subject: OsmoBTS -> libosmogsm code migration
On Wed, Oct 12, 2016 at 10:51 AM, Vadim Yanitskiy <axilirator(a)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
3173
days inactive
3175
days old
6 comments
3 participants
participants (3)
-
Max -
Tom Tsou -
Vadim Yanitskiy