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.deHi 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>