Proposal for new structure definition for compression algorithm

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/osmocom-net-gprs@lists.osmocom.org/.

Neels Hofmeyr nhofmeyr at sysmocom.de
Tue Mar 22 16:00:13 UTC 2016


Hi Sangamesh,

I should probably also read all of the code involved, properly, which I
must admit I haven't, but based on general knowledge, my replies are:

On Tue, Mar 22, 2016 at 10:22:59AM +0000, Sangamesh Sajjan wrote:
> The proposed structures are being used in following scenario.
>     1.	System Init (i.e. During system bootup) 
> 	*	Array of strings are used to form a tree, it is used only once during system bootup , hence it should not impact the performance. Let me know your opinion on this ?

Ok, for once-upon-boot a string approach sounds fair enough.

>     2.	Decoding of EGPRS packet downlink Ack/Nack
> 	*	While decoding there is no string comparison involved, we read every bit from the bitmap and traverse tree generated in init, hence only bit operation involved in decoding.

sounds good

>     3.	Encoding of packet uplink Ack/Nack
> 	*	 While encoding, first find the number of one's/zero's (i.e. run length of one's or zero's) consecutively and  find the corresponding code word by referring to the code word list
> 	*	This involves string comparison to find the code word,

Ick! :)

>      but based on your feedback we are planning to avoid string operations 
> 		and adopt existing (i.e. master ) approach to find the code word by using respective tables.

Sounds much better, yes.

> In current master code for decoding,  the function t4_rle_term is used to find the run length for each received code word, 
> There could be multiple code words in the received bitmap and each require multiple iterations(i.e. maximum of 64 iterations) to find run length.
> Instead if tree based approach is used multiple iterations can be avoided to find run length. 

Is this a separate suggestion to introduce a binary tree search? Beware of
too heavy / premature optimizations, but your trajectory sounds way better
now.

Anyway, looking forward to the patches, and I hope to read the patch
context properly, then. Thanks!

~Neels


-- 
- Neels Hofmeyr <nhofmeyr at 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
* Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160322/77874e4a/attachment.bin>


More information about the osmocom-net-gprs mailing list