From nhofmeyr at sysmocom.de  Wed Jun  1 11:51:38 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 1 Jun 2016 13:51:38 +0200
Subject: [PATCH] gtp/queue/queue_seqdel(): fix element check which always
 was true
In-Reply-To: <20160531124238.29585-1-lynxis@fe80.eu>
References: <20160531124238.29585-1-lynxis@fe80.eu>
Message-ID: <20160601115138.GC1888@dub6>

On Tue, May 31, 2016 at 02:42:38PM +0200, Alexander Couzens wrote:
> Iterate over all member until the correct member found, remove it
> and rearrange the seqnext pointer

Not sure why you put this ^ in the commit log?
Sounds like an in-code comment instead. The commit is only about what you wrote
in the subject.

> ---
>  gtp/queue.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/gtp/queue.c b/gtp/queue.c
> index 5b4d849..fbfa1ec 100644
> --- a/gtp/queue.c
> +++ b/gtp/queue.c
> @@ -105,8 +105,7 @@ static int queue_seqdel(struct queue_t *queue, struct qmsg_t *qmsg)
>  		printf("Begin queue_seqdel seq = %d\n", (int)qmsg->seq);
>  
>  	for (qmsg2 = queue->hashseq[hash]; qmsg2; qmsg2 = qmsg2->seqnext) {
> -		/* FIXME: this is always true !?! */
> -		if (qmsg == qmsg) {
> +		if (qmsg == qmsg2) {

Wow, this is really bad.

This fix looks really obvious and I'm tempted to merge right away. Still, have
you tested whether it works?  We should definitely have unit tests for these
functions!

Let's understand how openggsn can work when the function that removes an item
from a queue is fundamentally broken.

queue_seqdel() always removes the first item from the queue and returns 0.
Maybe, most of the time, the first item is coincidentally the one that openggsn
intends to remove?

queue_seqdel() is used by queue_freemsg() and in turn queue_freemsg_seq().

queue_freemsg() is supposed to delete a specific item from the queue. Its only
caller (besides queue_freemsg_seq()) is gtp_retrans(). All of the invocations
of queue_freemsg() are preceded by queue_getfirst().  Always the first item!

queue_freemsg_seq() finds a queue item for a *given peer* and pops it from the
queue (IMHO function name fail). So here it seems if we have only one peer, the
first queue item would always be correct, and hence queue_seqdel() would
correctly pop the first item from the queue. But also, the seq is used to look
up the item to be removed, so I guess most of the time the next seq is
coincidentally the first item, or the packets would be retransmitted
out-of-sequence. Anyway, openggsn should break badly as soon as we have more
than one peer (that's an SGSN I presume). How would it break?
queue_freemsg_seq()'s only caller is gtp_conf(), which apparently does: "Remove
signalling packet from retransmission queue. return 0 on success, EOF if packet
was not found"  (IMHO again function name fail). So it seems when there are
retransmissions pending for more than one peer, openggsn would potentially
transmit a given peer's queued messages to another, wrong peer.

Let's have unit tests!

@Harald: any preferences on who should spend time on it when? Just merge the
fix (without testing) and carry on with our other tasks?

Added http://osmocom.org/issues/1740

~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/20160601/fdddd7f6/attachment.bin>

From nhofmeyr at sysmocom.de  Wed Jun  1 11:54:56 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 1 Jun 2016 13:54:56 +0200
Subject: Status of GEA issues in OsmoSGSN
In-Reply-To: <574D8AC6.8020501@sysmocom.de>
References: <20160531125441.GB30831@nataraja>
 <574D8AC6.8020501@sysmocom.de>
Message-ID: <20160601115456.GD1888@dub6>

On Tue, May 31, 2016 at 02:59:50PM +0200, Max wrote:
> > Using uint64_t as the type for Kc in the GEA libraries is not a good choice
> 
> This has already been fixed in libosmocore.

Does this relate to https://gerrit.osmocom.org/128 ? If yes, how?
Max, would you mind to resolve this, i.e. take over the patch (attempt) from me?

Thanks,

~Neels

-------------- 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/20160601/f564a9ba/attachment.bin>

From msuraev at sysmocom.de  Wed Jun  1 12:35:23 2016
From: msuraev at sysmocom.de (Max)
Date: Wed, 1 Jun 2016 14:35:23 +0200
Subject: Status of GEA issues in OsmoSGSN
In-Reply-To: <20160601115456.GD1888@dub6>
References: <20160531125441.GB30831@nataraja> <574D8AC6.8020501@sysmocom.de>
 <20160601115456.GD1888@dub6>
Message-ID: <574ED68B.5040901@sysmocom.de>

Yes, it's related. I've commented in gerrit. I don't mind working on it
but related ticket (if I guessed it correctly) is already assigned so
chances are fix is already available, just have not been pushed for
review yet.

On 06/01/2016 01:54 PM, Neels Hofmeyr wrote:
> On Tue, May 31, 2016 at 02:59:50PM +0200, Max wrote:
>>> Using uint64_t as the type for Kc in the GEA libraries is not a good choice
>> This has already been fixed in libosmocore.
> Does this relate to https://gerrit.osmocom.org/128 ? If yes, how?
> Max, would you mind to resolve this, i.e. take over the patch (attempt) from me?
>
> Thanks,
>
> ~Neels
>

-- 
Max Suraev <msuraev 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 
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte 



From laforge at gnumonks.org  Thu Jun  2 12:19:31 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 2 Jun 2016 14:19:31 +0200
Subject: [PATCH] ggsn/cmdline: remove unused variable check_required
In-Reply-To: <574D8E72.8080509@sysmocom.de>
References: <20160531124754.3107-1-lynxis@fe80.eu>
 <574D8E72.8080509@sysmocom.de>
Message-ID: <20160602121931.GO23339@nataraja>

On Tue, May 31, 2016 at 03:15:30PM +0200, Max wrote:
> I think we should drop ggsn/cmdline.* from git and add compile-time
> dependency on gengetopt. It's available everywhere anyway and this would
> match the way we deal with generated code in libosmocore.

fine with me.  Will somebody work on a patch?

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From laforge at gnumonks.org  Thu Jun  2 12:22:42 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 2 Jun 2016 14:22:42 +0200
Subject: [PATCH] gtp/queue/queue_seqdel(): fix element check which always
 was true
In-Reply-To: <20160601115138.GC1888@dub6>
References: <20160531124238.29585-1-lynxis@fe80.eu>
 <20160601115138.GC1888@dub6>
Message-ID: <20160602122242.GP23339@nataraja>

Hi Neels,

On Wed, Jun 01, 2016 at 01:51:38PM +0200, Neels Hofmeyr wrote:
> Let's have unit tests!

Agreed, but I would really hope we can put new efforts into a different
(cleaner, more osmocom style) GTP implementation, rather than
implementing comprehensive unit tests for OpenGGSN's libgtp.

> @Harald: any preferences on who should spend time on it when? Just merge the
> fix (without testing) and carry on with our other tasks?

I think at the moment we (at sysmocom) unfortunately have lots of higher
priority items to work on, some of them are already delayed by almost 6
months. So we really cannot afford to spend time on other topics until
we make more progress.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From nhofmeyr at sysmocom.de  Sun Jun  5 22:54:05 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 6 Jun 2016 00:54:05 +0200
Subject: [MERGED] gtp/queue/queue_seqdel(): fix element check which always
 was true
In-Reply-To: <20160602122242.GP23339@nataraja>
References: <20160531124238.29585-1-lynxis@fe80.eu>
 <20160601115138.GC1888@dub6> <20160602122242.GP23339@nataraja>
Message-ID: <20160605225405.GB1351@dub6>

On Thu, Jun 02, 2016 at 02:22:42PM +0200, Harald Welte wrote:
> Hi Neels,
> 
> On Wed, Jun 01, 2016 at 01:51:38PM +0200, Neels Hofmeyr wrote:
> > Let's have unit tests!
> 
> Agreed, but I would really hope we can put new efforts into a different
> (cleaner, more osmocom style) GTP implementation, rather than
> implementing comprehensive unit tests for OpenGGSN's libgtp.

Hah, nice: that was my feeling exactly, but so far I assumed that a choice had
been made to use openggsn instead (for other reasons than available time).

> I think at the moment we (at sysmocom) unfortunately have lots of higher
> priority items to work on[...]

Ok; after my analysis of the surrounding code I actually feel more or less
comfortable to merge the obvious fix without insisting on tests.

Merged to openggsn master, with a commit message tweak containing a link to
this message thread.

~Neels

-------------- 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/20160606/afb32909/attachment.bin>

From Arvind.Sirsikar at radisys.com  Wed Jun  8 09:49:07 2016
From: Arvind.Sirsikar at radisys.com (Aravind Sirsikar)
Date: Wed, 8 Jun 2016 09:49:07 +0000
Subject: [EGPRS] Radisys planned activities for EGPRS
Message-ID: <BN3PR08MB117346E0B8A0CF1DA6B93848F05E0@BN3PR08MB1173.namprd08.prod.outlook.com>

Hello All,

We at Radisys have started working on EGPRS performance analysis and stability testing on NuRAN LiteCell 1.0. Below are the High level Items we have planned.


1)     EGPRS Performance benchmarking analysis and optimization

2)     CPU and Memory benchmarking and analysis

3)     EGPRS multi user tests, Stability, Stress and Soak testing

We will keep sharing the relevant patches as well as bench marking report to the mailing list for seeking inputs and suggestion.

Thanks,
Aravind Sirsikar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160608/fc478654/attachment.htm>

From Prasad.Kaup at radisys.com  Wed Jun  8 10:36:32 2016
From: Prasad.Kaup at radisys.com (Prasad Kaup)
Date: Wed, 8 Jun 2016 10:36:32 +0000
Subject: Profiling data of decoding  EPDAN compressed bitmap
Message-ID: <BN3PR08MB1237F939D3371A7233BD850AE65E0@BN3PR08MB1237.namprd08.prod.outlook.com>

Hello All,
             We have executed  profiling test  of two versions of algorithm for decoding  compressed bitmap of EPDAN.
>From the results , we see that performance is better in Tree based decoding (Version2 as given below )
Version 1: Bitmap based decoding   as present in current master branch ( Function name osmo_t4_decode )
Version 2: Tree based decoding  ( Function name decompress_crbb , as proposed in patch "Decompress the CRBB bitmap using tree based approach"<http://lists.osmocom.org/pipermail/osmocom-net-gprs/2016-March/000525.html> )

A sample bitmap taken from a real mobile log is used for  the test.
Host execution: Time taken to decode (micro seconds)
Version 1: (Bitmap  based decoding) : MIN -17  MAX -19   AVERAGE -17.9
Version 2 (tree based decoding): MIN -4   MAX -13  AVERAGE - 5.2

Target  execution: Time taken to decode (micro seconds)
Version 1: (Bitmap  based decoding) : MIN -277  MAX -583   AVERAGE - 353
Version 2 (tree based decoding): MIN -67   MAX -86  AVERAGE - 69.8

Regards
Prasad







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160608/dac8f760/attachment.htm>

From holger at freyther.de  Wed Jun  8 11:40:06 2016
From: holger at freyther.de (Holger Freyther)
Date: Wed, 8 Jun 2016 13:40:06 +0200
Subject: Profiling data of decoding  EPDAN compressed bitmap
In-Reply-To: <BN3PR08MB1237F939D3371A7233BD850AE65E0@BN3PR08MB1237.namprd08.prod.outlook.com>
References: <BN3PR08MB1237F939D3371A7233BD850AE65E0@BN3PR08MB1237.namprd08.prod.outlook.com>
Message-ID: <0E9A040D-A440-4B2C-8C89-E77B879E749B@freyther.de>


> On 08 Jun 2016, at 12:36, Prasad Kaup <Prasad.Kaup at radisys.com> wrote:
> 
> Hello All,

Hi!


>              We have executed  profiling test  of two versions of algorithm for decoding  compressed bitmap of EPDAN.
> From the results , we see that performance is better in Tree based decoding (Version2 as given below )
> Version 1: Bitmap based decoding   as present in current master branch ( Function name osmo_t4_decode )
> Version 2: Tree based decoding  ( Function name decompress_crbb , as proposed in patch ?Decompress the CRBB bitmap using tree based approach? )
>  
> A sample bitmap taken from a real mobile log is used for  the test.
> Host execution: Time taken to decode (micro seconds)
> Version 1: (Bitmap  based decoding) : MIN -17  MAX -19   AVERAGE -17.9
> Version 2 (tree based decoding): MIN -4   MAX -13  AVERAGE - 5.2
>  
> Target  execution: Time taken to decode (micro seconds)
> Version 1: (Bitmap  based decoding) : MIN -277  MAX -583   AVERAGE - 353
> Version 2 (tree based decoding): MIN -67   MAX -86  AVERAGE ? 69.8

please release the benchmark and the test data so one can re-measure and see where time is spent.

thank you
	holger



From laforge at gnumonks.org  Wed Jun  8 12:18:53 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 8 Jun 2016 14:18:53 +0200
Subject: [EGPRS] Radisys planned activities for EGPRS
In-Reply-To: <BN3PR08MB117346E0B8A0CF1DA6B93848F05E0@BN3PR08MB1173.namprd08.prod.outlook.com>
References: <BN3PR08MB117346E0B8A0CF1DA6B93848F05E0@BN3PR08MB1173.namprd08.prod.outlook.com>
Message-ID: <20160608121853.GC1439@nataraja>

Hi Aravind,

On Wed, Jun 08, 2016 at 09:49:07AM +0000, Aravind Sirsikar wrote:
> We at Radisys have started working on EGPRS performance analysis and stability
> testing on NuRAN LiteCell 1.0. Below are the High level Items we have planned.

thanks for the update.  We're looking forard to the related
results/patches.

It makes sense to work withe the concept of 'topic brnaches' in git,
i.e. for eahc of your (thre or more) logically separate topic, all
related patches should be kept in that branch.  Each series of patches
in such a topic branch can then be pushed to gerrit for review + merge.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From Prasad.Kaup at radisys.com  Thu Jun  9 14:01:49 2016
From: Prasad.Kaup at radisys.com (Prasad Kaup)
Date: Thu, 9 Jun 2016 14:01:49 +0000
Subject: Profiling data of decoding  EPDAN compressed bitmap
In-Reply-To: <0E9A040D-A440-4B2C-8C89-E77B879E749B@freyther.de>
References: <BN3PR08MB1237F939D3371A7233BD850AE65E0@BN3PR08MB1237.namprd08.prod.outlook.com>
 <0E9A040D-A440-4B2C-8C89-E77B879E749B@freyther.de>
Message-ID: <BN3PR08MB1237F49E46B13BF9CC60CC28E65F0@BN3PR08MB1237.namprd08.prod.outlook.com>

Hello,
> please release the benchmark and the test data so one can re-measure and
> see where time is spent.
Test data is  " 0x40,0x20,0x0a,0x7f,0x79,0x61,0x00,0x49,0x2b,0x4c,0x00,0xe1,0xf2,0xe9,0xfe,0xae,0x7a,0x00,0xf0,0x30,0x3b,0x2b,0x2b"

Timing  is collected  using  gettimeofday  call. Below is the data in microseconds.

Bitmap based decoder					Tree based decoder
Host	             Target				             Host		           Target
17		312					4			86
18		317					4			67
19		289					5			68
18		317					13			68
18		553					5			69
17		294					5			67
18		311					4			68
18		277					4			68
18		278					4			68
18		583					4			69

Regards
Prasad

From holger at freyther.de  Thu Jun  9 14:20:14 2016
From: holger at freyther.de (Holger Freyther)
Date: Thu, 9 Jun 2016 16:20:14 +0200
Subject: Profiling data of decoding  EPDAN compressed bitmap
In-Reply-To: <BN3PR08MB1237F49E46B13BF9CC60CC28E65F0@BN3PR08MB1237.namprd08.prod.outlook.com>
References: <BN3PR08MB1237F939D3371A7233BD850AE65E0@BN3PR08MB1237.namprd08.prod.outlook.com>
 <0E9A040D-A440-4B2C-8C89-E77B879E749B@freyther.de>
 <BN3PR08MB1237F49E46B13BF9CC60CC28E65F0@BN3PR08MB1237.namprd08.prod.outlook.com>
Message-ID: <CAAE0023-F7BD-45D4-8F4F-955C7BB02895@freyther.de>


> On 09 Jun 2016, at 16:01, Prasad Kaup <Prasad.Kaup at radisys.com> wrote:
> 
> Hello,
>> please release the benchmark and the test data so one can re-measure and
>> see where time is spent.
> Test data is  " 0x40,0x20,0x0a,0x7f,0x79,0x61,0x00,0x49,0x2b,0x4c,0x00,0xe1,0xf2,0xe9,0xfe,0xae,0x7a,0x00,0xf0,0x30,0x3b,0x2b,0x2b"

now only the benchmark (sourcecode) is missing. E.g. you can put it into the contrib folder of the pcu and push it to a branch in the radisyst repository?

holger



From Prasad.Kaup at radisys.com  Fri Jun 10 15:36:13 2016
From: Prasad.Kaup at radisys.com (Prasad Kaup)
Date: Fri, 10 Jun 2016 15:36:13 +0000
Subject: Profiling data of decoding  EPDAN compressed bitmap
In-Reply-To: <CAAE0023-F7BD-45D4-8F4F-955C7BB02895@freyther.de>
References: <BN3PR08MB1237F939D3371A7233BD850AE65E0@BN3PR08MB1237.namprd08.prod.outlook.com>
 <0E9A040D-A440-4B2C-8C89-E77B879E749B@freyther.de>
 <BN3PR08MB1237F49E46B13BF9CC60CC28E65F0@BN3PR08MB1237.namprd08.prod.outlook.com>
 <CAAE0023-F7BD-45D4-8F4F-955C7BB02895@freyther.de>
Message-ID: <BLUPR08MB1281A70050CFD85E3E80E451E6500@BLUPR08MB1281.namprd08.prod.outlook.com>

Hello,
> now only the benchmark (sourcecode) is missing. E.g. you can put it into the> contrib folder of the pcu and push it to a branch in the radisyst repository?
I have attached the patches  with latest master baseline.
Regards
Prasad


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Added-Test-case-for-EPDAN-profiling.patch
Type: application/octet-stream
Size: 12010 bytes
Desc: 0001-Added-Test-case-for-EPDAN-profiling.patch
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160610/26de629e/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Tree-based-decoding-of-compressed-bitmap.patch
Type: application/octet-stream
Size: 12899 bytes
Desc: 0002-Tree-based-decoding-of-compressed-bitmap.patch
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160610/26de629e/attachment-0001.obj>

From holger at freyther.de  Fri Jun 10 15:40:02 2016
From: holger at freyther.de (Holger Freyther)
Date: Fri, 10 Jun 2016 17:40:02 +0200
Subject: Profiling data of decoding  EPDAN compressed bitmap
In-Reply-To: <BLUPR08MB1281A70050CFD85E3E80E451E6500@BLUPR08MB1281.namprd08.prod.outlook.com>
References: <BN3PR08MB1237F939D3371A7233BD850AE65E0@BN3PR08MB1237.namprd08.prod.outlook.com>
 <0E9A040D-A440-4B2C-8C89-E77B879E749B@freyther.de>
 <BN3PR08MB1237F49E46B13BF9CC60CC28E65F0@BN3PR08MB1237.namprd08.prod.outlook.com>
 <CAAE0023-F7BD-45D4-8F4F-955C7BB02895@freyther.de>
 <BLUPR08MB1281A70050CFD85E3E80E451E6500@BLUPR08MB1281.namprd08.prod.outlook.com>
Message-ID: <193743E4-12D5-4904-B490-42824E9200BF@freyther.de>


> On 10 Jun 2016, at 17:36, Prasad Kaup <Prasad.Kaup at radisys.com> wrote:
> 
> Hello,

Dear Passad,

>> now only the benchmark (sourcecode) is missing. E.g. you can put it into the> contrib folder of the pcu and push it to a branch in the radisyst repository?
> I have attached the patches  with latest master baseline.


you do not seem to understand my intent. I want to run "perf" on your benchmark and compare the two implementations. To be able to do this, you will need to share the code that executes the two different implementations (and the testdata).

So please put the sourcecode for your test/benchmark application into the contrib/ directory and push it into a branch of your osmo-pcu-radisys git repository.


kind regards
  holger





From Prasad.Kaup at radisys.com  Fri Jun 10 16:36:54 2016
From: Prasad.Kaup at radisys.com (Prasad Kaup)
Date: Fri, 10 Jun 2016 16:36:54 +0000
Subject: Profiling data of decoding  EPDAN compressed bitmap
References: <BN3PR08MB1237F939D3371A7233BD850AE65E0@BN3PR08MB1237.namprd08.prod.outlook.com>
 <0E9A040D-A440-4B2C-8C89-E77B879E749B@freyther.de>
 <BN3PR08MB1237F49E46B13BF9CC60CC28E65F0@BN3PR08MB1237.namprd08.prod.outlook.com>
 <CAAE0023-F7BD-45D4-8F4F-955C7BB02895@freyther.de> 
Message-ID: <BLUPR08MB1281460B0077E551C983AE65E6500@BLUPR08MB1281.namprd08.prod.outlook.com>

Note also that UT environment is cross compiled and TBFTest  is run on target to get the timing data for target.
Regards
Prasad


From holger at freyther.de  Fri Jun 10 17:34:39 2016
From: holger at freyther.de (Holger Freyther)
Date: Fri, 10 Jun 2016 19:34:39 +0200
Subject: Profiling data of decoding  EPDAN compressed bitmap
In-Reply-To: <BLUPR08MB1281460B0077E551C983AE65E6500@BLUPR08MB1281.namprd08.prod.outlook.com>
References: <BN3PR08MB1237F939D3371A7233BD850AE65E0@BN3PR08MB1237.namprd08.prod.outlook.com>
 <0E9A040D-A440-4B2C-8C89-E77B879E749B@freyther.de>
 <BN3PR08MB1237F49E46B13BF9CC60CC28E65F0@BN3PR08MB1237.namprd08.prod.outlook.com>
 <CAAE0023-F7BD-45D4-8F4F-955C7BB02895@freyther.de>
 <BLUPR08MB1281460B0077E551C983AE65E6500@BLUPR08MB1281.namprd08.prod.outlook.com>
Message-ID: <8E22EFFF-C582-40C0-9BE7-B9CB277CDBD0@freyther.de>


> On 10 Jun 2016, at 18:36, Prasad Kaup <Prasad.Kaup at radisys.com> wrote:
> 
> Note also that UT environment is cross compiled and TBFTest  is run on target to get the timing data for target.

Will you provide the source + test data for your benchmark? If not why not? A benchmark (and its result) is only useful if it is perfectly clear of what has been measured and compared with each other. The easiest way to make that clear is to provide the source and data (+ explanation on compiling/execution).

kind regards
	holger



From holger at freyther.de  Fri Jun 10 17:56:47 2016
From: holger at freyther.de (Holger Freyther)
Date: Fri, 10 Jun 2016 19:56:47 +0200
Subject: Profiling data of decoding  EPDAN compressed bitmap
In-Reply-To: <8E22EFFF-C582-40C0-9BE7-B9CB277CDBD0@freyther.de>
References: <BN3PR08MB1237F939D3371A7233BD850AE65E0@BN3PR08MB1237.namprd08.prod.outlook.com>
 <0E9A040D-A440-4B2C-8C89-E77B879E749B@freyther.de>
 <BN3PR08MB1237F49E46B13BF9CC60CC28E65F0@BN3PR08MB1237.namprd08.prod.outlook.com>
 <CAAE0023-F7BD-45D4-8F4F-955C7BB02895@freyther.de>
 <BLUPR08MB1281460B0077E551C983AE65E6500@BLUPR08MB1281.namprd08.prod.outlook.com>
 <8E22EFFF-C582-40C0-9BE7-B9CB277CDBD0@freyther.de>
Message-ID: <22249C3D-1004-49AA-AE77-F12C2B2D063F@freyther.de>


> On 10 Jun 2016, at 19:34, Holger Freyther <holger at freyther.de> wrote:
> 

> Will you provide the source + test data for your benchmark? If not why not? A benchmark (and its result) is only useful if it is perfectly clear of what has been measured and compared with each other. The easiest way to make that clear is to provide the source and data (+ explanation on compiling/execution).

After going through the patch again, I see that you instrument a single call of the decoding code? I don't think that this is a good approach to comparing the decoding code. What I expected (and probably Harald as well) is:

* One collects some typical data (e.g. all data used during routing area update, pdp context activation and then opening a common website, e.g. m.heise.de), alternative you can use other compressed bitmaps if you can say how they represent a public page.

* Ones creates a bench_compressed_window.c with at least two paths:

** Call the existing code
** Call the new tree code


Initialize the code tree in both cases and one can use "time" to compare it. E.g. the non-compiling skeleton like this:


struct test_data {
	const uint8_t *data;
	const size_t len;
	const ... expected_result; // (what is the point if it is more quick if it does not work)
};

static const struct test_data tests[] = {
	TEST_DATA(data, NULL),..
	
};


static void test_old(int rounds, int verify)
{
	while (rounds-- > 0) {
		int i;
		for (i = 0; i < ARRAY_SIZE(tests); ++i) {
			call_old_code();
			if (verify)
				check_result();
		}
	}
}

static void test_new(int rounds, int verify)
{
	while (rounds-- > 0) {
		int i;
		for (i = 0; i < ARRAY_SIZE(tests); ++i) {
			call_new_code();
			if (verify)
				check_result();
		}
	}
}


int main()
{
	initialize_tree();
...
	if (new)
		test_new(10000, 0)
	else
		test_old(10000, 0);
}




From Prasad.Kaup at radisys.com  Mon Jun 13 09:03:09 2016
From: Prasad.Kaup at radisys.com (Prasad Kaup)
Date: Mon, 13 Jun 2016 09:03:09 +0000
Subject: Profiling data of decoding  EPDAN compressed bitmap
In-Reply-To: <22249C3D-1004-49AA-AE77-F12C2B2D063F@freyther.de>
References: <BN3PR08MB1237F939D3371A7233BD850AE65E0@BN3PR08MB1237.namprd08.prod.outlook.com>
 <0E9A040D-A440-4B2C-8C89-E77B879E749B@freyther.de>
 <BN3PR08MB1237F49E46B13BF9CC60CC28E65F0@BN3PR08MB1237.namprd08.prod.outlook.com>
 <CAAE0023-F7BD-45D4-8F4F-955C7BB02895@freyther.de>
 <BLUPR08MB1281460B0077E551C983AE65E6500@BLUPR08MB1281.namprd08.prod.outlook.com>
 <8E22EFFF-C582-40C0-9BE7-B9CB277CDBD0@freyther.de>
 <22249C3D-1004-49AA-AE77-F12C2B2D063F@freyther.de>
Message-ID: <BLUPR08MB1281CEFA3156BB546060D5CEE6530@BLUPR08MB1281.namprd08.prod.outlook.com>

Hello Holger,
> After going through the patch again, I see that you instrument a single call of
> the decoding code? I don't think that this is a good approach to comparing
> the decoding code. 

We will add more test samples for the profiling test as suggested and share the benchmark.

Regards
Prasad



From Arvind.Sirsikar at radisys.com  Wed Jun 15 09:02:24 2016
From: Arvind.Sirsikar at radisys.com (Aravind Sirsikar)
Date: Wed, 15 Jun 2016 09:02:24 +0000
Subject: [EGPRS] Gerrit guidance to address Jenkins Build failure and
 resubmission of patch.
Message-ID: <BN3PR08MB11732A6BB6AC6D5BC24191F7F0550@BN3PR08MB1173.namprd08.prod.outlook.com>

Hi,
Can you guide us to address issues we are currently facing about Gerrit process as listed below
	1) Jenkins Build reports failure. Can you suggest the reason for this.
		Because in our local branch the Unit test and build is successful.
	2) Is there any specific process to  resubmit patch after addressing the
		review comments.

Thanks,
Aravind Sirsikar


From msuraev at sysmocom.de  Wed Jun 15 09:23:23 2016
From: msuraev at sysmocom.de (Max)
Date: Wed, 15 Jun 2016 11:23:23 +0200
Subject: [EGPRS] Gerrit guidance to address Jenkins Build failure and
 resubmission of patch.
In-Reply-To: <BN3PR08MB11732A6BB6AC6D5BC24191F7F0550@BN3PR08MB1173.namprd08.prod.outlook.com>
References: <BN3PR08MB11732A6BB6AC6D5BC24191F7F0550@BN3PR08MB1173.namprd08.prod.outlook.com>
Message-ID: <57611E8B.6080505@sysmocom.de>

Not sure if it's related but in jenkins logs for one of the latest
builds [1] I've noticed following:

Documentation error (missing docs): 
<command id='show asciidoc counters'>
        <param name='asciidoc' doc='(null)' />
        <param name='counters' doc='(null)' />

Documentation error (missing docs): 
<command id='show asciidoc counters'>
        <param name='asciidoc' doc='(null)' />
        <param name='counters' doc='(null)' />

In general, gerrit have link to jenkins for particular build failure. As
for 2nd question - the patch is identified by "Change-Id" in the commit
message so all you've got to do is to re-send the patch with the same
id. Personally I use gerrit extension for magit in emacs to obtain the
patch and git-review for submission. In general - please refer to
http://osmocom.org/projects/cellular-infrastructure/wiki/Gerrit.

On 06/15/2016 11:02 AM, Aravind Sirsikar wrote:
> Hi,
> Can you guide us to address issues we are currently facing about Gerrit process as listed below
> 	1) Jenkins Build reports failure. Can you suggest the reason for this.
> 		Because in our local branch the Unit test and build is successful.
> 	2) Is there any specific process to  resubmit patch after addressing the
> 		review comments.
>
> Thanks,
> Aravind Sirsikar

[1]
http://jenkins.osmocom.org/jenkins/job/osmo-pcu-gerrit/label=linux_amd64_ubuntu_1504,sysmobts=no,sysmodsp=no/72/console

-- 
Max Suraev <msuraev 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 
* Geschaeftsfuehrer / Managing Director: Harald Welte 



From Arvind.Sirsikar at radisys.com  Wed Jun 15 09:28:16 2016
From: Arvind.Sirsikar at radisys.com (Aravind Sirsikar)
Date: Wed, 15 Jun 2016 09:28:16 +0000
Subject: [EGPRS] Gerrit guidance to address Jenkins Build failure and
 resubmission of patch.
In-Reply-To: <57611E8B.6080505@sysmocom.de>
References: <BN3PR08MB11732A6BB6AC6D5BC24191F7F0550@BN3PR08MB1173.namprd08.prod.outlook.com>
 <57611E8B.6080505@sysmocom.de>
Message-ID: <BN3PR08MB1173935B78D15758F0E96F17F0550@BN3PR08MB1173.namprd08.prod.outlook.com>

Hi Max,

>Documentation error (missing docs):
><command id='show asciidoc counters'>
>        <param name='asciidoc' doc='(null)' />
>        <param name='counters' doc='(null)' />
>

This thing we have also noticed. But we don't know  the reason for this error reported by Jenkins. Can you please help us to address this issue for patch resubmission. 

Thanks,
Aravind Sirsikar


From laforge at gnumonks.org  Wed Jun 15 09:52:09 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 15 Jun 2016 11:52:09 +0200
Subject: [EGPRS] Gerrit guidance to address Jenkins Build failure and
 resubmission of patch.
In-Reply-To: <BN3PR08MB1173935B78D15758F0E96F17F0550@BN3PR08MB1173.namprd08.prod.outlook.com>
References: <BN3PR08MB11732A6BB6AC6D5BC24191F7F0550@BN3PR08MB1173.namprd08.prod.outlook.com>
 <57611E8B.6080505@sysmocom.de>
 <BN3PR08MB1173935B78D15758F0E96F17F0550@BN3PR08MB1173.namprd08.prod.outlook.com>
Message-ID: <20160615095209.GI4397@nataraja>

On Wed, Jun 15, 2016 at 09:28:16AM +0000, Aravind Sirsikar wrote:
> This thing we have also noticed. But we don't know  the reason for
> this error reported by Jenkins. Can you please help us to address this
> issue for patch resubmission. 

the issue is that a patch adding the 'show asciidoc counters' vty
command was added to libosmocore (written by Lynxis, approved by me) -
but that patch didn't contain well-formed help syntax for the VTY
command:   https://gerrit.osmocom.org/#/c/70/

Unfortunately I believe this is not tested in libosmocore (as
it jus builds a library), but the error only shows up once you build and
test an application linking the library, such as the PCU.

I pushed a fix and submitted it, see https://gerrit.osmocom.org/#/c/276/

This jenkins failure should thus be resolved now.
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From Arvind.Sirsikar at radisys.com  Wed Jun 15 10:29:39 2016
From: Arvind.Sirsikar at radisys.com (Aravind Sirsikar)
Date: Wed, 15 Jun 2016 10:29:39 +0000
Subject: [EGPRS] Gerrit guidance to address Jenkins Build failure and
 resubmission of patch.
In-Reply-To: <20160615095209.GI4397@nataraja>
References: <BN3PR08MB11732A6BB6AC6D5BC24191F7F0550@BN3PR08MB1173.namprd08.prod.outlook.com>
 <57611E8B.6080505@sysmocom.de>
 <BN3PR08MB1173935B78D15758F0E96F17F0550@BN3PR08MB1173.namprd08.prod.outlook.com>
 <20160615095209.GI4397@nataraja>
Message-ID: <BN3PR08MB117328FDA5F346A53DD8693AF0550@BN3PR08MB1173.namprd08.prod.outlook.com>

Hi Harald,

>the issue is that a patch adding the 'show asciidoc counters' vty command was
>added to libosmocore (written by Lynxis, approved by me) - but that patch didn't

As Jenkins has failed the build for all the 5 patches, do I need to resend all the patches again?


Thanks,
Aravind Sirsikar


From msuraev at sysmocom.de  Wed Jun 15 11:24:02 2016
From: msuraev at sysmocom.de (Max)
Date: Wed, 15 Jun 2016 13:24:02 +0200
Subject: [EGPRS] Gerrit guidance to address Jenkins Build failure and
 resubmission of patch.
In-Reply-To: <BN3PR08MB117328FDA5F346A53DD8693AF0550@BN3PR08MB1173.namprd08.prod.outlook.com>
References: <BN3PR08MB11732A6BB6AC6D5BC24191F7F0550@BN3PR08MB1173.namprd08.prod.outlook.com>
 <57611E8B.6080505@sysmocom.de>
 <BN3PR08MB1173935B78D15758F0E96F17F0550@BN3PR08MB1173.namprd08.prod.outlook.com>
 <20160615095209.GI4397@nataraja>
 <BN3PR08MB117328FDA5F346A53DD8693AF0550@BN3PR08MB1173.namprd08.prod.outlook.com>
Message-ID: <57613AD2.3060106@sysmocom.de>

If you have access to jenkins you can manually retrigger corresponding
build but since re-sending the patch series is just single command (git
review) which takes less than 1 minute to execute I think it would be
quicker that way.

On 06/15/2016 12:29 PM, Aravind Sirsikar wrote:
> Hi Harald,
>
>> the issue is that a patch adding the 'show asciidoc counters' vty command was
>> added to libosmocore (written by Lynxis, approved by me) - but that patch didn't
> As Jenkins has failed the build for all the 5 patches, do I need to resend all the patches again?
>
>
> Thanks,
> Aravind Sirsikar

-- 
Max Suraev <msuraev 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 
* Geschaeftsfuehrer / Managing Director: Harald Welte 



From Prasad.Kaup at radisys.com  Wed Jun 15 13:32:41 2016
From: Prasad.Kaup at radisys.com (Prasad Kaup)
Date: Wed, 15 Jun 2016 13:32:41 +0000
Subject: Issue seen in decoding compressed bitmap in EPDAN
Message-ID: <BN3PR08MB1285E555FE71E231AACBC9C8E6550@BN3PR08MB1285.namprd08.prod.outlook.com>

Hello,
                During testing  with latest master osmo-pcu,  we see that there  is an issue  in decoding of compressed bitmap with make-up code in EPDAN
Input to decoding algorithm:
Compressed bitmap array : 0x7a,0x28,0x31,0xe1,0xf1,0xc1,0x6c,0x32,0x87
Starting colour code : 1
Length : 72

Expected output ( Refer  3GPP 44.060 section 9.1.10):
Expected decoded Length: 304
Expected Uncompressed bitmap: dd c1 48 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01

Actual output:
Actual decoded length :292
Actual Uncompressed bitmap:  dd c1 48 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Regards
Prasad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160615/240c1638/attachment.htm>

From msuraev at sysmocom.de  Wed Jun 15 13:35:25 2016
From: msuraev at sysmocom.de (Max)
Date: Wed, 15 Jun 2016 15:35:25 +0200
Subject: Issue seen in decoding compressed bitmap in EPDAN
In-Reply-To: <BN3PR08MB1285E555FE71E231AACBC9C8E6550@BN3PR08MB1285.namprd08.prod.outlook.com>
References: <BN3PR08MB1285E555FE71E231AACBC9C8E6550@BN3PR08MB1285.namprd08.prod.outlook.com>
Message-ID: <5761599D.6020803@sysmocom.de>

Thanks for reporting. Could you make a ticket in
http://projects.osmocom.org/ please? It would make tracking it easier.

On 06/15/2016 03:32 PM, Prasad Kaup wrote:
>
> Hello,
>
>                 During testing  with latest master osmo-pcu,  we see
> that there  is an issue  in decoding of compressed bitmap with make-up
> code in EPDAN
>
> Input to decoding algorithm:
>
> Compressed bitmap array : 0x7a,0x28,0x31,0xe1,0xf1,0xc1,0x6c,0x32,0x87
>
> Starting colour code : 1
>
> Length : 72
>
>  
>
> Expected output ( Refer  3GPP 44.060 section 9.1.10):
>
> Expected decoded Length: 304
>
> Expected Uncompressed bitmap: dd c1 48 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01
>
>  
>
> Actual output:
>
> Actual decoded length :292
>
> Actual Uncompressed bitmap:  dd c1 48 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>
>  
>
> Regards
>
> Prasad
>

-- 
Max Suraev <msuraev 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 
* Geschaeftsfuehrer / Managing Director: Harald Welte 



From nhofmeyr at sysmocom.de  Wed Jun 15 13:53:59 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 15 Jun 2016 15:53:59 +0200
Subject: [EGPRS] Gerrit guidance to address Jenkins Build failure and
 resubmission of patch.
In-Reply-To: <57613AD2.3060106@sysmocom.de>
References: <BN3PR08MB11732A6BB6AC6D5BC24191F7F0550@BN3PR08MB1173.namprd08.prod.outlook.com>
 <57611E8B.6080505@sysmocom.de>
 <BN3PR08MB1173935B78D15758F0E96F17F0550@BN3PR08MB1173.namprd08.prod.outlook.com>
 <20160615095209.GI4397@nataraja>
 <BN3PR08MB117328FDA5F346A53DD8693AF0550@BN3PR08MB1173.namprd08.prod.outlook.com>
 <57613AD2.3060106@sysmocom.de>
Message-ID: <20160615135359.GA4596@dub6>

On Wed, Jun 15, 2016 at 01:24:02PM +0200, Max wrote:
> If you have access to jenkins you can manually retrigger corresponding
> build but since re-sending the patch series is just single command (git
> review) which takes less than 1 minute to execute I think it would be
> quicker that way.

Gerrit will refuse resending identical patches.

We can click 'rebase' on the gerrit website to retrigger a build, once some
other patch (i.e. max's fix) has been pushed to master.

Alternatively radisys can rebase locally onto the updated master and then
re-submit to gerrit.

~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: 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/20160615/316a746c/attachment.bin>

From holger at freyther.de  Wed Jun 15 14:01:10 2016
From: holger at freyther.de (Holger Freyther)
Date: Wed, 15 Jun 2016 16:01:10 +0200
Subject: [EGPRS] Gerrit guidance to address Jenkins Build failure and
 resubmission of patch.
In-Reply-To: <20160615135359.GA4596@dub6>
References: <BN3PR08MB11732A6BB6AC6D5BC24191F7F0550@BN3PR08MB1173.namprd08.prod.outlook.com>
 <57611E8B.6080505@sysmocom.de>
 <BN3PR08MB1173935B78D15758F0E96F17F0550@BN3PR08MB1173.namprd08.prod.outlook.com>
 <20160615095209.GI4397@nataraja>
 <BN3PR08MB117328FDA5F346A53DD8693AF0550@BN3PR08MB1173.namprd08.prod.outlook.com>
 <57613AD2.3060106@sysmocom.de> <20160615135359.GA4596@dub6>
Message-ID: <646DD962-8AD2-4A05-8528-6CCB12A23385@freyther.de>


> On 15 Jun 2016, at 15:53, Neels Hofmeyr <nhofmeyr at sysmocom.de> wrote:
> 
> On Wed, Jun 15, 2016 at 01:24:02PM +0200, Max wrote:
>> If you have access to jenkins you can manually retrigger corresponding
>> build but since re-sending the patch series is just single command (git
>> review) which takes less than 1 minute to execute I think it would be
>> quicker that way.
> 
> Gerrit will refuse resending identical patches.
> 
> We can click 'rebase' on the gerrit website to retrigger a build, once some
> other patch (i.e. max's fix) has been pushed to master.
> 
> Alternatively radisys can rebase locally onto the updated master and then
> re-submit to gerrit.

you can just re-trigger the failed job. I did retrigger for two of them. Which others failed?

holger

From nhofmeyr at sysmocom.de  Thu Jun 16 11:32:38 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 16 Jun 2016 13:32:38 +0200
Subject: [EGPRS] Gerrit guidance to address Jenkins Build failure and
 resubmission of patch.
In-Reply-To: <646DD962-8AD2-4A05-8528-6CCB12A23385@freyther.de>
References: <BN3PR08MB11732A6BB6AC6D5BC24191F7F0550@BN3PR08MB1173.namprd08.prod.outlook.com>
 <57611E8B.6080505@sysmocom.de>
 <BN3PR08MB1173935B78D15758F0E96F17F0550@BN3PR08MB1173.namprd08.prod.outlook.com>
 <20160615095209.GI4397@nataraja>
 <BN3PR08MB117328FDA5F346A53DD8693AF0550@BN3PR08MB1173.namprd08.prod.outlook.com>
 <57613AD2.3060106@sysmocom.de> <20160615135359.GA4596@dub6>
 <646DD962-8AD2-4A05-8528-6CCB12A23385@freyther.de>
Message-ID: <20160616113238.GA2119@dub6>

On Wed, Jun 15, 2016 at 04:01:10PM +0200, Holger Freyther wrote:
> you can just re-trigger the failed job. I did retrigger for two of them. Which others failed?

Can I also retrigger? How?? Not by the "Rebase" button, then?

I'm not sure if a plain retrigger would be sufficient if some other change is
needed first.

~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: 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/20160616/854680f5/attachment.bin>

From Arvind.Sirsikar at radisys.com  Thu Jun 16 11:23:27 2016
From: Arvind.Sirsikar at radisys.com (Aravind Sirsikar)
Date: Thu, 16 Jun 2016 11:23:27 +0000
Subject: [MERGED] osmo-pcu[master]: Add test cases for Header Type 2 in
 EGPRS UL
References: <gerrit.1465911295762.I1dd46010065a6d6da21e8e45af71e6d5f649b0b0@gerrit.osmocom.org>
 <78b6df9a-25a6-4f4e-948a-ca644fd533e8@BN3NAM01FT042.eop-nam01.prod.protection.outlook.com>
Message-ID: <BN3PR08MB1173D9D7DBE3F9DFB79CEA6AF0560@BN3PR08MB1173.namprd08.prod.outlook.com>

Hi Holger,

>  Holger Freyther: Looks good to me, approved

In http://git.osmocom.org/osmo-pcu, one of the 5 patches submitted for Gerrit review(MCS5-MCS9 support in EGPRS UL)has been
merged to master. As this patch is part of series of 5 patches it should be merged in below order.

	1) Remove GMSK only check in EGPRS UL(Change-Id:I567acc012d8ad49681715f0104ba7e91625e1e7a)
	2) Add Header Type2 support in EGPRS UL(Change-Id:Iac2422c8acbdcefe20aafbba6a4eb87c9893e3ba)
	3) Add header type 1 support for EGPRS uplink(Change-Id:I13c250e2e07377982ac3f29745f3cffd4088552a)
	4) Add test cases for Header Type 2 in EGPRS UL(Change-Id:I1dd46010065a6d6da21e8e45af71e6d5f649b0b0)
	5) Add test cases for Header type1 in EGPRS UL(Change-Id:I21811bb126dbe151b0708a964d3143bc2fd52389)

Currently osmo-pcu build is failing since only patch 4 of the list above has been merged. Can you please let me know how to proceed over this?
Going forward it will be helpful for us if you can suggest how to number the patches of a series in Gerrit review.


Thanks,
Aravind Sirsikar

From msuraev at sysmocom.de  Thu Jun 16 14:03:54 2016
From: msuraev at sysmocom.de (Max)
Date: Thu, 16 Jun 2016 16:03:54 +0200
Subject: [MERGED] osmo-pcu[master]: Add test cases for Header Type 2 in
 EGPRS UL
In-Reply-To: <BN3PR08MB1173D9D7DBE3F9DFB79CEA6AF0560@BN3PR08MB1173.namprd08.prod.outlook.com>
References: <gerrit.1465911295762.I1dd46010065a6d6da21e8e45af71e6d5f649b0b0@gerrit.osmocom.org>
 <78b6df9a-25a6-4f4e-948a-ca644fd533e8@BN3NAM01FT042.eop-nam01.prod.protection.outlook.com>
 <BN3PR08MB1173D9D7DBE3F9DFB79CEA6AF0560@BN3PR08MB1173.namprd08.prod.outlook.com>
Message-ID: <5762B1CA.8070307@sysmocom.de>

Curious: "make" works fine but "make check" fails for me too. I'm
puzzled how it have made it through jenkins.

On 06/16/2016 01:23 PM, Aravind Sirsikar wrote:
> Hi Holger,
>
>>  Holger Freyther: Looks good to me, approved
> In http://git.osmocom.org/osmo-pcu, one of the 5 patches submitted for Gerrit review(MCS5-MCS9 support in EGPRS UL)has been
> merged to master. As this patch is part of series of 5 patches it should be merged in below order.
>
> 	1) Remove GMSK only check in EGPRS UL(Change-Id:I567acc012d8ad49681715f0104ba7e91625e1e7a)
> 	2) Add Header Type2 support in EGPRS UL(Change-Id:Iac2422c8acbdcefe20aafbba6a4eb87c9893e3ba)
> 	3) Add header type 1 support for EGPRS uplink(Change-Id:I13c250e2e07377982ac3f29745f3cffd4088552a)
> 	4) Add test cases for Header Type 2 in EGPRS UL(Change-Id:I1dd46010065a6d6da21e8e45af71e6d5f649b0b0)
> 	5) Add test cases for Header type1 in EGPRS UL(Change-Id:I21811bb126dbe151b0708a964d3143bc2fd52389)
>
> Currently osmo-pcu build is failing since only patch 4 of the list above has been merged. Can you please let me know how to proceed over this?
> Going forward it will be helpful for us if you can suggest how to number the patches of a series in Gerrit review.
>
>
> Thanks,
> Aravind Sirsikar

-- 
Max Suraev <msuraev 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 
* Geschaeftsfuehrer / Managing Director: Harald Welte 



From msuraev at sysmocom.de  Thu Jun 16 14:06:25 2016
From: msuraev at sysmocom.de (Max)
Date: Thu, 16 Jun 2016 16:06:25 +0200
Subject: [EGPRS] Gerrit guidance to address Jenkins Build failure and
 resubmission of patch.
In-Reply-To: <20160616113238.GA2119@dub6>
References: <BN3PR08MB11732A6BB6AC6D5BC24191F7F0550@BN3PR08MB1173.namprd08.prod.outlook.com>
 <57611E8B.6080505@sysmocom.de>
 <BN3PR08MB1173935B78D15758F0E96F17F0550@BN3PR08MB1173.namprd08.prod.outlook.com>
 <20160615095209.GI4397@nataraja>
 <BN3PR08MB117328FDA5F346A53DD8693AF0550@BN3PR08MB1173.namprd08.prod.outlook.com>
 <57613AD2.3060106@sysmocom.de> <20160615135359.GA4596@dub6>
 <646DD962-8AD2-4A05-8528-6CCB12A23385@freyther.de>
 <20160616113238.GA2119@dub6>
Message-ID: <5762B261.8000107@sysmocom.de>

When jenkins build fails there's a link to particular build - if you
follow it you can click "retrigger" in the left menu for particular
build in jenkins (provided you have account).

On 06/16/2016 01:32 PM, Neels Hofmeyr wrote:
> On Wed, Jun 15, 2016 at 04:01:10PM +0200, Holger Freyther wrote:
>> you can just re-trigger the failed job. I did retrigger for two of them. Which others failed?
> Can I also retrigger? How?? Not by the "Rebase" button, then?
>
> I'm not sure if a plain retrigger would be sufficient if some other change is
> needed first.
>
> ~Neels
>
>

-- 
Max Suraev <msuraev 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 
* Geschaeftsfuehrer / Managing Director: Harald Welte 



From holger at freyther.de  Thu Jun 16 14:09:55 2016
From: holger at freyther.de (Holger Freyther)
Date: Thu, 16 Jun 2016 16:09:55 +0200
Subject: [MERGED] osmo-pcu[master]: Add test cases for Header Type 2 in
 EGPRS UL
In-Reply-To: <5762B1CA.8070307@sysmocom.de>
References: <gerrit.1465911295762.I1dd46010065a6d6da21e8e45af71e6d5f649b0b0@gerrit.osmocom.org>
 <78b6df9a-25a6-4f4e-948a-ca644fd533e8@BN3NAM01FT042.eop-nam01.prod.protection.outlook.com>
 <BN3PR08MB1173D9D7DBE3F9DFB79CEA6AF0560@BN3PR08MB1173.namprd08.prod.outlook.com>
 <5762B1CA.8070307@sysmocom.de>
Message-ID: <D9D370BC-9C2B-4CA7-8A2C-7E9E056D51A6@freyther.de>


> On 16 Jun 2016, at 16:03, Max <msuraev at sysmocom.de> wrote:
> 
> Curious: "make" works fine but "make check" fails for me too. I'm
> puzzled how it have made it through jenkins.

Jenkins makes "git checkout SHA1" so it picks the right parent. It looked like the first patch o the series. :)

From laforge at gnumonks.org  Thu Jun 16 14:41:17 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 16 Jun 2016 16:41:17 +0200
Subject: [MERGED] osmo-pcu[master]: Add test cases for Header Type 2 in
 EGPRS UL
In-Reply-To: <BN3PR08MB1173D9D7DBE3F9DFB79CEA6AF0560@BN3PR08MB1173.namprd08.prod.outlook.com>
References: <gerrit.1465911295762.I1dd46010065a6d6da21e8e45af71e6d5f649b0b0@gerrit.osmocom.org>
 <78b6df9a-25a6-4f4e-948a-ca644fd533e8@BN3NAM01FT042.eop-nam01.prod.protection.outlook.com>
 <BN3PR08MB1173D9D7DBE3F9DFB79CEA6AF0560@BN3PR08MB1173.namprd08.prod.outlook.com>
Message-ID: <20160616144117.GC4397@nataraja>

Hi Aravind,

to resolve the current issue, I have merged the remaining patches from
those listed in your mail.

> Going forward it will be helpful for us if you can suggest how to
> number the patches of a series in Gerrit review.

For this more generic question on how to submit certain batches of
patches relating to one topic, I would like to defer the question to
Neels who has gained most experience in this context.

Can you please also explain how you solved the WAIT_ASSIGN problem as
indicated in https://gerrit.osmocom.org/#/c/218/ ?  Do you have a
specific fix against the bug introduced by the introduction of the
WAIT_ASSIGN state?

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From Arvind.Sirsikar at radisys.com  Fri Jun 17 05:54:39 2016
From: Arvind.Sirsikar at radisys.com (Aravind Sirsikar)
Date: Fri, 17 Jun 2016 05:54:39 +0000
Subject: [MERGED] osmo-pcu[master]: Add test cases for Header Type 2 in
 EGPRS UL
In-Reply-To: <20160616144117.GC4397@nataraja>
References: <gerrit.1465911295762.I1dd46010065a6d6da21e8e45af71e6d5f649b0b0@gerrit.osmocom.org>
 <78b6df9a-25a6-4f4e-948a-ca644fd533e8@BN3NAM01FT042.eop-nam01.prod.protection.outlook.com>
 <BN3PR08MB1173D9D7DBE3F9DFB79CEA6AF0560@BN3PR08MB1173.namprd08.prod.outlook.com>
 <20160616144117.GC4397@nataraja>
Message-ID: <BN3PR08MB117331A225B83651357C64E4F0570@BN3PR08MB1173.namprd08.prod.outlook.com>

Hi Harald,

>to resolve the current issue, I have merged the remaining patches from those
>listed in your mail.

I see you have missed last patch related to "MCS5-MCS9 support for EGPRS UL" with change Id 
I21811bb126dbe151b0708a964d3143bc2fd52389. Can you please merge it also so that I can start 
submitting patches related to next feature.

Thanks,
Aravind Sirsikar


From Arvind.Sirsikar at radisys.com  Fri Jun 17 07:27:23 2016
From: Arvind.Sirsikar at radisys.com (Aravind Sirsikar)
Date: Fri, 17 Jun 2016 07:27:23 +0000
Subject: [MERGED] osmo-pcu[master]: Add test cases for Header Type 2 in
 EGPRS UL
In-Reply-To: <20160616144117.GC4397@nataraja>
References: <gerrit.1465911295762.I1dd46010065a6d6da21e8e45af71e6d5f649b0b0@gerrit.osmocom.org>
 <78b6df9a-25a6-4f4e-948a-ca644fd533e8@BN3NAM01FT042.eop-nam01.prod.protection.outlook.com>
 <BN3PR08MB1173D9D7DBE3F9DFB79CEA6AF0560@BN3PR08MB1173.namprd08.prod.outlook.com>
 <20160616144117.GC4397@nataraja>
Message-ID: <BN3PR08MB1173DAD75569B9DDDF77313FF0570@BN3PR08MB1173.namprd08.prod.outlook.com>

Hi Harald,

>Can you please also explain how you solved the WAIT_ASSIGN problem as
>indicated in https://gerrit.osmocom.org/#/c/218/ ?  Do you have a specific fix
>against the bug introduced by the introduction of the WAIT_ASSIGN state?

We have earlier informed in mailing list as well that GPRS issue is likely in one phase access. Hence to avoid this we made a work around by enabling two-phase-access in osmo-pcu.cfg. This work around helps in establishing GPRS call successfully. Due to our current work priorities we have not further investigated root cause of the GPRS one phase access failure.

Thanks,
Aravind Sirsikar


From Arvind.Sirsikar at radisys.com  Fri Jun 17 09:29:58 2016
From: Arvind.Sirsikar at radisys.com (Aravind Sirsikar)
Date: Fri, 17 Jun 2016 09:29:58 +0000
Subject: [EGPRS] Gerrit guidance to address Jenkins Build failure and
 resubmission of patch.
In-Reply-To: <5762B261.8000107@sysmocom.de>
References: <BN3PR08MB11732A6BB6AC6D5BC24191F7F0550@BN3PR08MB1173.namprd08.prod.outlook.com>
 <57611E8B.6080505@sysmocom.de>
 <BN3PR08MB1173935B78D15758F0E96F17F0550@BN3PR08MB1173.namprd08.prod.outlook.com>
 <20160615095209.GI4397@nataraja>
 <BN3PR08MB117328FDA5F346A53DD8693AF0550@BN3PR08MB1173.namprd08.prod.outlook.com>
 <57613AD2.3060106@sysmocom.de> <20160615135359.GA4596@dub6>
 <646DD962-8AD2-4A05-8528-6CCB12A23385@freyther.de>
 <20160616113238.GA2119@dub6> <5762B261.8000107@sysmocom.de>
Message-ID: <BN3PR08MB11735AAF45F7A433E399C521F0570@BN3PR08MB1173.namprd08.prod.outlook.com>

Hi Max,

>When jenkins build fails there's a link to particular build - if you follow it you can
>click "retrigger" in the left menu for particular build in jenkins (provided you have
>account).

I followed the link mentioned in Gerrit for the failed build http://jenkins.osmocom.org/jenkins/job/osmo-pcu-gerrit/81/ 
but I am not able to locate the "retrigger" button. Can you please help?

Thanks,
Aravind Sirsikar


From Arvind.Sirsikar at radisys.com  Fri Jun 17 10:25:07 2016
From: Arvind.Sirsikar at radisys.com (Aravind Sirsikar)
Date: Fri, 17 Jun 2016 10:25:07 +0000
Subject: [EGPRS] Gerrit guidance to address Jenkins Build failure and
 resubmission of patch.
References: <BN3PR08MB11732A6BB6AC6D5BC24191F7F0550@BN3PR08MB1173.namprd08.prod.outlook.com>
 <57611E8B.6080505@sysmocom.de>
 <BN3PR08MB1173935B78D15758F0E96F17F0550@BN3PR08MB1173.namprd08.prod.outlook.com>
 <20160615095209.GI4397@nataraja>
 <BN3PR08MB117328FDA5F346A53DD8693AF0550@BN3PR08MB1173.namprd08.prod.outlook.com>
 <57613AD2.3060106@sysmocom.de> <20160615135359.GA4596@dub6>
 <646DD962-8AD2-4A05-8528-6CCB12A23385@freyther.de>
 <20160616113238.GA2119@dub6> <5762B261.8000107@sysmocom.de> 
Message-ID: <BN3PR08MB1173BD2ADE22372DC346D241F0570@BN3PR08MB1173.namprd08.prod.outlook.com>

Hi Holger,

>I followed the link mentioned in Gerrit for the failed build
>http://jenkins.osmocom.org/jenkins/job/osmo-pcu-gerrit/81/
>but I am not able to locate the "retrigger" button. Can you please help?

I am able to resolve the Jenkins failure after attempting rebase. Jenkins Build has now succeeded. Can you please merge the same to master.

Thanks,
Aravind Sirsikar


From nhofmeyr at sysmocom.de  Fri Jun 17 17:10:07 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Fri, 17 Jun 2016 19:10:07 +0200
Subject: [EGPRS] Gerrit guidance to address Jenkins Build failure and
 resubmission of patch.
In-Reply-To: <BN3PR08MB11735AAF45F7A433E399C521F0570@BN3PR08MB1173.namprd08.prod.outlook.com>
References: <57611E8B.6080505@sysmocom.de>
 <BN3PR08MB1173935B78D15758F0E96F17F0550@BN3PR08MB1173.namprd08.prod.outlook.com>
 <20160615095209.GI4397@nataraja>
 <BN3PR08MB117328FDA5F346A53DD8693AF0550@BN3PR08MB1173.namprd08.prod.outlook.com>
 <57613AD2.3060106@sysmocom.de> <20160615135359.GA4596@dub6>
 <646DD962-8AD2-4A05-8528-6CCB12A23385@freyther.de>
 <20160616113238.GA2119@dub6> <5762B261.8000107@sysmocom.de>
 <BN3PR08MB11735AAF45F7A433E399C521F0570@BN3PR08MB1173.namprd08.prod.outlook.com>
Message-ID: <20160617171007.GA16677@dub6>

On Fri, Jun 17, 2016 at 09:29:58AM +0000, Aravind Sirsikar wrote:
> Hi Max,
> 
> >When jenkins build fails there's a link to particular build - if you follow it you can
> >click "retrigger" in the left menu for particular build in jenkins (provided you have
> >account).
> 
> I followed the link mentioned in Gerrit for the failed build http://jenkins.osmocom.org/jenkins/job/osmo-pcu-gerrit/81/ 
> but I am not able to locate the "retrigger" button. Can you please help?

I also overlooked this minor detail: you need to be logged in on jenkins to see
the retrigger button (i.e. "Sign in" on the top right). You may have to create
an account first, not sure if it will have permissions to retrigger though.

The "rebase" button remains a workaround, which works as soon as another patch
was merged to master (which usually should be the case if you were waiting for
someone else's fix).

~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: 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/20160617/fa9aa497/attachment.bin>

From nhofmeyr at sysmocom.de  Fri Jun 17 17:47:20 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Fri, 17 Jun 2016 19:47:20 +0200
Subject: gerrit and branches
Message-ID: <20160617174720.GB16677@dub6>

Today I've taken another close look at branches and gerrit, and have written
down my conclusions here:

http://osmocom.org/projects/cellular-infrastructure/wiki/Gerrit#Submitting-Branches

In summary:

* Branch re-submission needs the workaround of tweaking the first commit.
  It would be nice to fix gerrit to not need this, but for the time being the
  effort of cosmetically changing the first commit log is acceptable.

* It *is* possible to have private branches in the gerrit repos and still be
  able to submit them to master, with the proper project config.

I have thus switched all our gerrit projects' configs to rebase-if-necessary
with the flags as described on the wiki page.
(Except for osmo-pcap, where we still disallow content merges.)

I will now go back to pushing my "private" developments to the public
repository (gerrit) under the neels/ or sysmocom/ namespaces.

~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: 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/20160617/72e3ff34/attachment.bin>

From nhofmeyr at sysmocom.de  Fri Jun 17 17:53:14 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Fri, 17 Jun 2016 19:53:14 +0200
Subject: [MERGED] osmo-pcu[master]: Add test cases for Header Type 2 in
 EGPRS UL
In-Reply-To: <20160616144117.GC4397@nataraja>
References: <gerrit.1465911295762.I1dd46010065a6d6da21e8e45af71e6d5f649b0b0@gerrit.osmocom.org>
 <78b6df9a-25a6-4f4e-948a-ca644fd533e8@BN3NAM01FT042.eop-nam01.prod.protection.outlook.com>
 <BN3PR08MB1173D9D7DBE3F9DFB79CEA6AF0560@BN3PR08MB1173.namprd08.prod.outlook.com>
 <20160616144117.GC4397@nataraja>
Message-ID: <20160617175314.GC16677@dub6>

On Thu, Jun 16, 2016 at 04:41:17PM +0200, Harald Welte wrote:
> Hi Aravind,
> 
> to resolve the current issue, I have merged the remaining patches from
> those listed in your mail.
> 
> > Going forward it will be helpful for us if you can suggest how to
> > number the patches of a series in Gerrit review.

osmo-pcu's gerrit was still in the "cherry pick" strategy until today. Now that
it is changed to "rebase if necessary", you will be able to submit patches in
sequence by simply pushing a branch HEAD to submit all branch commits for
review. Gerrit should keep the right sequence now. Do take note of this quirk:
http://osmocom.org/projects/cellular-infrastructure/wiki/Gerrit#Re-submit-a-Branch-with-Amended-Commits

~Neels

-------------- 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/20160617/11d29cea/attachment.bin>

From holger at freyther.de  Fri Jun 17 18:18:30 2016
From: holger at freyther.de (Holger Freyther)
Date: Fri, 17 Jun 2016 20:18:30 +0200
Subject: gerrit and branches
In-Reply-To: <20160617174720.GB16677@dub6>
References: <20160617174720.GB16677@dub6>
Message-ID: <69D401D8-B989-4B4A-BE74-52D7AA9CAB51@freyther.de>


> On 17 Jun 2016, at 19:47, Neels Hofmeyr <nhofmeyr at sysmocom.de> wrote:
> 

Hi!


> * Branch re-submission needs the workaround of tweaking the first commit.
>  It would be nice to fix gerrit to not need this, but for the time being the
>  effort of cosmetically changing the first commit log is acceptable.

did you file a bug report for it? It looks like there is also a better fix for the rebase if necessary change. So maybe it is fixing that issue too?


https://bugs.chromium.org/p/gerrit/issues/detail?id=2167&colspec=ID%20Type%20Stars%20Milestone%20Status%20Priority%20Owner%20Summary

https://gerrit-review.googlesource.com/#/c/54550/


> I will now go back to pushing my "private" developments to the public
> repository (gerrit) under the neels/ or sysmocom/ namespaces.

cool. thank you for your investigation.


holger



From Arvind.Sirsikar at radisys.com  Mon Jun 20 09:05:30 2016
From: Arvind.Sirsikar at radisys.com (Aravind Sirsikar)
Date: Mon, 20 Jun 2016 09:05:30 +0000
Subject: [EGPRS PCU] ARQ-2 support for EGPRS DL Retransmission
Message-ID: <BN3PR08MB11733CB7FFD9CC40DF172F9DF02A0@BN3PR08MB1173.namprd08.prod.outlook.com>

Hi,

I have pushed series of patches related to ARQ-2 support for EGPRS DL Retransmission. This patches have been reviewed earlier and
comments have been Addressed. These patches are tested and validated with NuRAN 1.0 hardware.

Below are the links to Gerrit review of each patches along with patch description.


1)  https://gerrit.osmocom.org/#/c/332/ ==>Add data structure for ARQ-II in EGPRS DL.

2)  https://gerrit.osmocom.org/#/c/333/ ==>Add Accessor functions for ARQ-II in EGPRS DL.

3)  https://gerrit.osmocom.org/#/c/334/ ==>Modify DL tbf flow for ARQ-II in EGPRS DL Retx.

4)  https://gerrit.osmocom.org/#/c/335/ ==>Add test cases to support ARQ-II for EGPRS DL Retx.


Above patches must be merged to master in the same order as mentioned above.

Thanks,
Aravind Sirsikar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160620/8fbb8b98/attachment.htm>

From nhofmeyr at sysmocom.de  Mon Jun 20 15:55:00 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 20 Jun 2016 17:55:00 +0200
Subject: testing gerrit, might be down shortly
Message-ID: <20160620155500.GA25075@ass40.sysmocom.de>

I'm testing things related to our gerrit bug report, if it's not working
for you right now it may be because I'm restarting gerrit to test with/out
our fix.

I'll repost when I'm done.

~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: 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/20160620/37a04384/attachment.bin>

From nhofmeyr at sysmocom.de  Mon Jun 20 18:21:01 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 20 Jun 2016 20:21:01 +0200
Subject: gerrit and branches
In-Reply-To: <69D401D8-B989-4B4A-BE74-52D7AA9CAB51@freyther.de>
References: <20160617174720.GB16677@dub6>
 <69D401D8-B989-4B4A-BE74-52D7AA9CAB51@freyther.de>
Message-ID: <20160620182101.GB25075@ass40.sysmocom.de>

On Fri, Jun 17, 2016 at 08:18:30PM +0200, Holger Freyther wrote:
> > * Branch re-submission needs the workaround of tweaking the first commit.
> >  It would be nice to fix gerrit to not need this, but for the time being the
> >  effort of cosmetically changing the first commit log is acceptable.
> 
> did you file a bug report for it?

I coined it a feature request...
https://bugs.chromium.org/p/gerrit/issues/detail?id=4210

> It looks like there is also a better fix for the rebase if necessary change. So maybe it is fixing that issue too?

The fix in question was already in our gerrit version.

I found our issue is entirely different.  I have no idea why your patch
helped...  I suspect we had some confusion with the "Create a new change
for every commit not in the target branch" config item.

But the NullPointer you fixed has since been fixed by someone else on
stable-2.12 :) so that was an actual bug.

I commented in abundant detail...

https://bugs.chromium.org/p/gerrit/issues/detail?id=4158

~Neels

-------------- 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/20160620/50703507/attachment.bin>

From holger at freyther.de  Mon Jun 20 18:22:42 2016
From: holger at freyther.de (Holger Freyther)
Date: Mon, 20 Jun 2016 20:22:42 +0200
Subject: gerrit and branches
In-Reply-To: <20160620182101.GB25075@ass40.sysmocom.de>
References: <20160617174720.GB16677@dub6>
 <69D401D8-B989-4B4A-BE74-52D7AA9CAB51@freyther.de>
 <20160620182101.GB25075@ass40.sysmocom.de>
Message-ID: <2DB2281C-FBA1-4481-A028-25004B8EEC85@freyther.de>


> On 20 Jun 2016, at 20:21, Neels Hofmeyr <nhofmeyr at sysmocom.de> wrote:
> 

Hi!


> I found our issue is entirely different.  I have no idea why your patch
> helped...  I suspect we had some confusion with the "Create a new change
> for every commit not in the target branch" config item.
> 
> But the NullPointer you fixed has since been fixed by someone else on
> stable-2.12 :) so that was an actual bug.

I have two fixes, one to rebase if necessary and the other the NPE.


> 
> I commented in abundant detail...
> 
> https://bugs.chromium.org/p/gerrit/issues/detail?id=4158




From nhofmeyr at sysmocom.de  Mon Jun 20 18:29:21 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 20 Jun 2016 20:29:21 +0200
Subject: [EGPRS PCU] ARQ-2 support for EGPRS DL Retransmission
In-Reply-To: <BN3PR08MB11733CB7FFD9CC40DF172F9DF02A0@BN3PR08MB1173.namprd08.prod.outlook.com>
References: <BN3PR08MB11733CB7FFD9CC40DF172F9DF02A0@BN3PR08MB1173.namprd08.prod.outlook.com>
Message-ID: <20160620182921.GC25075@ass40.sysmocom.de>

On Mon, Jun 20, 2016 at 09:05:30AM +0000, Aravind Sirsikar wrote:
> 1)  https://gerrit.osmocom.org/#/c/332/ ==>Add data structure for ARQ-II in EGPRS DL.
> 
> 2)  https://gerrit.osmocom.org/#/c/333/ ==>Add Accessor functions for ARQ-II in EGPRS DL.
> 
> 3)  https://gerrit.osmocom.org/#/c/334/ ==>Modify DL tbf flow for ARQ-II in EGPRS DL Retx.
> 
> 4)  https://gerrit.osmocom.org/#/c/335/ ==>Add test cases to support ARQ-II for EGPRS DL Retx.
> 
> 
> Above patches must be merged to master in the same order as mentioned above.

As mentioned before, we're now on the Rebase-If-Necessary strategy in
gerrit, which ensures the correct ordering. You will notice here
https://gerrit.osmocom.org/#/c/335/1
that on the right, there is a list of "Submitted Together", which shows me
that you have committed as expected, from a branch all at once.

It would have sufficed to just link to the last submission (335), or
actually, there is no need to comment at all. Next time you can just
submit to gerrit and you're done :)

(Strangely enough, the "submitted together" list always shows only the
preceding commits in a series, while the "related changes" always shows
all of them.)

~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: 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/20160620/39d1ae12/attachment.bin>

From nhofmeyr at sysmocom.de  Mon Jun 20 18:46:15 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 20 Jun 2016 20:46:15 +0200
Subject: DONE -- was: testing gerrit, might be down shortly
In-Reply-To: <20160620155500.GA25075@ass40.sysmocom.de>
References: <20160620155500.GA25075@ass40.sysmocom.de>
Message-ID: <20160620184615.GA3343@ass40.sysmocom.de>

I'm done testing.

At first I tested a bit on openbsc.git, so apologies for those gerrit
mails. I've then added the sandbox repository, so most of the testing mail
flood has been spared; and there will be no more testing mails now :)

Thank you for your patience.

~Neels

-------------- 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/20160620/d688dd5e/attachment.bin>

From nhofmeyr at sysmocom.de  Mon Jun 20 18:58:39 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 20 Jun 2016 20:58:39 +0200
Subject: gerrit and branches
In-Reply-To: <2DB2281C-FBA1-4481-A028-25004B8EEC85@freyther.de>
References: <20160617174720.GB16677@dub6>
 <69D401D8-B989-4B4A-BE74-52D7AA9CAB51@freyther.de>
 <20160620182101.GB25075@ass40.sysmocom.de>
 <2DB2281C-FBA1-4481-A028-25004B8EEC85@freyther.de>
Message-ID: <20160620185838.GB3343@ass40.sysmocom.de>

On Mon, Jun 20, 2016 at 08:22:42PM +0200, Holger Freyther wrote:
> I have two fixes, one to rebase if necessary and the other the NPE.

As I said, someone else fixed the NPE slightly differently since:
https://gerrit.googlesource.com/gerrit/+/929f7bb7a9c566210d5e1ba54ecc423aa27f5ff8%5E!/#F0

I couldn't reproduce the rebase-if-necessary fix, the problem as explained
in the issue remained:
https://bugs.chromium.org/p/gerrit/issues/detail?id=4158

~Neels

-------------- 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/20160620/feb9971a/attachment.bin>

From Arvind.Sirsikar at radisys.com  Tue Jun 21 07:58:51 2016
From: Arvind.Sirsikar at radisys.com (Aravind Sirsikar)
Date: Tue, 21 Jun 2016 07:58:51 +0000
Subject: osmo-pcu[master]: Add data structure for ARQ-II in EGPRS DL
In-Reply-To: <37eea556-5ea2-4926-bd00-641de29302c4@SN1NAM01FT009.eop-nam01.prod.protection.outlook.com>
References: <gerrit.1466408227977.I734b1024bb32f2daa43af4adf59f4a17f2294afe@gerrit.osmocom.org>
 <37eea556-5ea2-4926-bd00-641de29302c4@SN1NAM01FT009.eop-nam01.prod.protection.outlook.com>
Message-ID: <BN3PR08MB117335DF5A3EC9A713A1928FF02B0@BN3PR08MB1173.namprd08.prod.outlook.com>

Hi Holger,

>Line 130: 	GprsCodingScheme cs_current_trans;
>I would prefer to cs and cs_current_trans being private here.

The cs_current_trans is made public to align with existing variables like block[RLC_MAX_LEN],  len and others to have consistency. will it make sense to have cs and cs_current_trans as private?.

We can rename cs to cs_last_tx as suggested in review of other patch. But it will have modification in other source files to address compilation errors.

Thanks,
Aravind Sirsikar

From holger at freyther.de  Tue Jun 21 08:40:08 2016
From: holger at freyther.de (Holger Freyther)
Date: Tue, 21 Jun 2016 10:40:08 +0200
Subject: osmo-pcu[master]: Add data structure for ARQ-II in EGPRS DL
In-Reply-To: <BN3PR08MB117335DF5A3EC9A713A1928FF02B0@BN3PR08MB1173.namprd08.prod.outlook.com>
References: <gerrit.1466408227977.I734b1024bb32f2daa43af4adf59f4a17f2294afe@gerrit.osmocom.org>
 <37eea556-5ea2-4926-bd00-641de29302c4@SN1NAM01FT009.eop-nam01.prod.protection.outlook.com>
 <BN3PR08MB117335DF5A3EC9A713A1928FF02B0@BN3PR08MB1173.namprd08.prod.outlook.com>
Message-ID: <2CCEDCDB-96E8-4E35-A0F0-79B46ED83202@freyther.de>


> On 21 Jun 2016, at 09:58, Aravind Sirsikar <Arvind.Sirsikar at radisys.com> wrote:
> 
> Hi Holger,
> 
>> Line 130: 	GprsCodingScheme cs_current_trans;
>> I would prefer to cs and cs_current_trans being private here.
> 
> The cs_current_trans is made public to align with existing variables like block[RLC_MAX_LEN],  len and others to have consistency. will it make sense to have cs and cs_current_trans as private?.
> 
> We can rename cs to cs_last_tx as suggested in review of other patch. But it will have modification in other source files to address compilation errors.

please keep the communication about the modification in gerrit. If in two years we look at the change we will not know that there was communication out-of-band.

If you add this comment to your change I will follow-up in gerrit.

thank you for your consideration

	holger



From nhofmeyr at sysmocom.de  Tue Jun 21 11:24:01 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Tue, 21 Jun 2016 13:24:01 +0200
Subject: conversations in gerrit "lost" here
Message-ID: <20160621112401.GA14455@ass40.sysmocom.de>

I am a bit ambiguous on our use of comments in gerrit.

We do discuss at least some fairly interesting things in the comments on
patches waiting for approval in gerrit.

When these discussions are attempted on openbsc@ or osmocom-net-gprs@, you
tend to block off and redirect the discussion back to the gerrit comments
infrastructure.

However, we have moved the gerrit mails to a separate and very noisy
mailing list, and these potentially interesting discussions are moved
essentially out of the public focus.

Also, if we in future would like to investigate discussion on some topic,
we need to search both the main ML and the gerrit ML.

IMHO it would make sense to copy the human originated comments to our
"human" mailing lists, so that the automatic jenkins and gerrit
notifications remain on the noisy ML while we see all discussions here.

Is that easy to achieve (filter on originator of comment),
and would you guys agree?

~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: 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/20160621/779fecc8/attachment.bin>

From Pravin.Manoharan at radisys.com  Wed Jun 22 07:44:09 2016
From: Pravin.Manoharan at radisys.com (Pravin Kumaravel Manoharan)
Date: Wed, 22 Jun 2016 07:44:09 +0000
Subject: Profiling data of decoding  EPDAN compressed bitmap
In-Reply-To: <BLUPR08MB1281CEFA3156BB546060D5CEE6530@BLUPR08MB1281.namprd08.prod.outlook.com>
References: <BN3PR08MB1237F939D3371A7233BD850AE65E0@BN3PR08MB1237.namprd08.prod.outlook.com>
 <0E9A040D-A440-4B2C-8C89-E77B879E749B@freyther.de>
 <BN3PR08MB1237F49E46B13BF9CC60CC28E65F0@BN3PR08MB1237.namprd08.prod.outlook.com>
 <CAAE0023-F7BD-45D4-8F4F-955C7BB02895@freyther.de>
 <BLUPR08MB1281460B0077E551C983AE65E6500@BLUPR08MB1281.namprd08.prod.outlook.com>
 <8E22EFFF-C582-40C0-9BE7-B9CB277CDBD0@freyther.de>
 <22249C3D-1004-49AA-AE77-F12C2B2D063F@freyther.de>
 <BLUPR08MB1281CEFA3156BB546060D5CEE6530@BLUPR08MB1281.namprd08.prod.outlook.com>
Message-ID: <DM2PR0801MB6651F6426A8F6AA0C5B3279972C0@DM2PR0801MB665.namprd08.prod.outlook.com>

Hello Holger,
	We have pushed the branch with tree based decoding algorithm and profiling test for comparison of existing method 
in master over the tree based algorithm developed by Radisys.
Branch name: users/pravin/epdan_profiling  at http://git.osmocom.org/radisys/osmo-pcu/

The comments suggested in earlier mail are addressed in the branch.
Following is the profiling results in micro-seconds. Each of 4 inputs is decoded 10000 times for getting the below data
Existing decoding algorithm in Target
Input	Min	Max	Avg
1	165	174	276
2	100	101	168
3	16	26	26
4	185	190	312

Tree based decoding algorithm Target
Input	Min	Max	Avg
1	65	430	110
2	58	59	98
3	3	4	6
4	96	469	162

Moreover, we also tried the same on host machine below are the results.
Existing decoding algorithm in Host
Input	Min	Max	Avg
1	5	6	12
2	3	4	8
3	0	1	0
4	5	7	14

Tree based decoding algorithm in Host
Input	Min	Max	Avg
1	2 	3	7
2	2	3	5
3	0	1	0
4	3	4	9

Regards,
Pravin 




From Pravin.Manoharan at radisys.com  Wed Jun 22 10:23:17 2016
From: Pravin.Manoharan at radisys.com (Pravin Kumaravel Manoharan)
Date: Wed, 22 Jun 2016 10:23:17 +0000
Subject: Profiling data of decoding  EPDAN compressed bitmap
References: <BN3PR08MB1237F939D3371A7233BD850AE65E0@BN3PR08MB1237.namprd08.prod.outlook.com>
 <0E9A040D-A440-4B2C-8C89-E77B879E749B@freyther.de>
 <BN3PR08MB1237F49E46B13BF9CC60CC28E65F0@BN3PR08MB1237.namprd08.prod.outlook.com>
 <CAAE0023-F7BD-45D4-8F4F-955C7BB02895@freyther.de>
 <BLUPR08MB1281460B0077E551C983AE65E6500@BLUPR08MB1281.namprd08.prod.outlook.com>
 <8E22EFFF-C582-40C0-9BE7-B9CB277CDBD0@freyther.de>
 <22249C3D-1004-49AA-AE77-F12C2B2D063F@freyther.de>
 <BLUPR08MB1281CEFA3156BB546060D5CEE6530@BLUPR08MB1281.namprd08.prod.outlook.com>
Message-ID: <DM2PR0801MB665C619FEC5994FEBECAF0D972C0@DM2PR0801MB665.namprd08.prod.outlook.com>

Hello Holger,
	In the submitted patch we see that there a bug in computing max value  we will correct it and resubmit the patch and results.

Regards,
Pravin


From Pravin.Manoharan at radisys.com  Thu Jun 23 14:39:14 2016
From: Pravin.Manoharan at radisys.com (Pravin Kumaravel Manoharan)
Date: Thu, 23 Jun 2016 14:39:14 +0000
Subject: Profiling data of decoding  EPDAN compressed bitmap
References: <BN3PR08MB1237F939D3371A7233BD850AE65E0@BN3PR08MB1237.namprd08.prod.outlook.com>
 <0E9A040D-A440-4B2C-8C89-E77B879E749B@freyther.de>
 <BN3PR08MB1237F49E46B13BF9CC60CC28E65F0@BN3PR08MB1237.namprd08.prod.outlook.com>
 <CAAE0023-F7BD-45D4-8F4F-955C7BB02895@freyther.de>
 <BLUPR08MB1281460B0077E551C983AE65E6500@BLUPR08MB1281.namprd08.prod.outlook.com>
 <8E22EFFF-C582-40C0-9BE7-B9CB277CDBD0@freyther.de>
 <22249C3D-1004-49AA-AE77-F12C2B2D063F@freyther.de>
 <BLUPR08MB1281CEFA3156BB546060D5CEE6530@BLUPR08MB1281.namprd08.prod.outlook.com>
Message-ID: <DM2PR0801MB665E734822F42A2BBFA86D8972D0@DM2PR0801MB665.namprd08.prod.outlook.com>

Hi All,
Following is the profiling results comparison of the decoding algorithms (unit in micro-seconds). Each of the 4 test inputs is decoded 10000 times for getting below data.

Input test                                            In target                                                                               In host
Vector id              Tree based                          Existing                                 Tree based                          Existing
                                Min        Avg                        Min        Avg                        Min        Avg                       Min        Avg
      1                       66           69.6                        164         173.4                     2              6.8                         5              13.3
      2                       59           62.3                        118         124.8                     2              5.5                         3              11.5
      3                       12           13.1                        20           22                           0              0.5                         0              1.3
      4                       96           102.4                     251         264                         3              9.2                          7              19.8

Important summary:
1. For few other identified test vectors existing algorithm fails functionally to decode whereas tree based decoding algorithm succeeds.
2. Details of these test vectors are in the latest patch available in users/pravin/epdan_profiling at http://git.osmocom.org/radisys/osmo-pcu/
3. From the above results it shows that Tree based decoding algorithm is better than existing algorithm for the decoding time consumed.
4. The max value is not included because it is abnormally high which occurs at very low frequency like once in 10000 iterations.


The detailed Profiling data follows,
In target:

Tree based decoding algorithm:
Input test         Min          Avg                        Max
vector Id
1                              66           69.6                        651
2                              59           62.3                        1125
3                              12           13.1                        259
4                              96           102.4                     1418

Existing Algorithm:
Input test             Min       Avg                        Max
vector Id
1                              164         173.4                     1372
2                              118         124.8                     691
3                              20           22                           1376
4                              251         264                         1229

In host:

Tree based decoding algorithm:
Input test         Min          Avg                        Max
Vector id
1                              2              6.8                          16065
2                              2              5.5                          20063
3                              0              0.5                          67
4                              3              9.2                          16219

Existing Algorithm:
Input test         Min          Avg                        Max
Vector id
1                              5              13.3                        12042
2                              3              11.5                        10816
3                              0              1.3                          5227
4                              7              19.8                        12078


Regards,
Pravin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160623/f3fb0ff2/attachment.htm>

From Arvind.Sirsikar at radisys.com  Fri Jun 24 06:30:42 2016
From: Arvind.Sirsikar at radisys.com (Aravind Sirsikar)
Date: Fri, 24 Jun 2016 06:30:42 +0000
Subject: osmo-pcu[master]: Add data structure for ARQ-II in EGPRS DL
In-Reply-To: <2CCEDCDB-96E8-4E35-A0F0-79B46ED83202@freyther.de>
References: <gerrit.1466408227977.I734b1024bb32f2daa43af4adf59f4a17f2294afe@gerrit.osmocom.org>
 <37eea556-5ea2-4926-bd00-641de29302c4@SN1NAM01FT009.eop-nam01.prod.protection.outlook.com>
 <BN3PR08MB117335DF5A3EC9A713A1928FF02B0@BN3PR08MB1173.namprd08.prod.outlook.com>
 <2CCEDCDB-96E8-4E35-A0F0-79B46ED83202@freyther.de>
Message-ID: <BN3PR08MB11739D372669DED0C1462723F02E0@BN3PR08MB1173.namprd08.prod.outlook.com>

Hi Holger,

>please keep the communication about the modification in gerrit

I have updated comment section on Gerrit for reviews related to ARQ-2 in EGPRS DL. Can you please let me know whether you agree on suggested modifications so that I can re-submit the patches?

Thanks,
Aravind Sirsikar


From Arvind.Sirsikar at radisys.com  Wed Jun 29 12:23:34 2016
From: Arvind.Sirsikar at radisys.com (Aravind Sirsikar)
Date: Wed, 29 Jun 2016 12:23:34 +0000
Subject: osmo-pcu[master]: Add data structure for ARQ-II in EGPRS DL
In-Reply-To: <20160624194341.GL14342@nataraja>
References: <gerrit.1466408227977.I734b1024bb32f2daa43af4adf59f4a17f2294afe@gerrit.osmocom.org>
 <37eea556-5ea2-4926-bd00-641de29302c4@SN1NAM01FT009.eop-nam01.prod.protection.outlook.com>
 <BN3PR08MB117335DF5A3EC9A713A1928FF02B0@BN3PR08MB1173.namprd08.prod.outlook.com>
 <2CCEDCDB-96E8-4E35-A0F0-79B46ED83202@freyther.de>
 <BN3PR08MB11739D372669DED0C1462723F02E0@BN3PR08MB1173.namprd08.prod.outlook.com>
 <20160624194341.GL14342@nataraja>
Message-ID: <BN3PR08MB1173CAFE42DDAB9540B9538EF0230@BN3PR08MB1173.namprd08.prod.outlook.com>

Hi Harald/Holger,

Please let me know any further updates on the pending review for ARQ2?. Since it is pending for long time we would like to know how to proceed over this.

Thanks,
Aravind Sirsikar


From laforge at gnumonks.org  Wed Jun 29 12:35:51 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 29 Jun 2016 14:35:51 +0200
Subject: osmo-pcu[master]: Add data structure for ARQ-II in EGPRS DL
In-Reply-To: <BN3PR08MB1173CAFE42DDAB9540B9538EF0230@BN3PR08MB1173.namprd08.prod.outlook.com>
References: <gerrit.1466408227977.I734b1024bb32f2daa43af4adf59f4a17f2294afe@gerrit.osmocom.org>
 <37eea556-5ea2-4926-bd00-641de29302c4@SN1NAM01FT009.eop-nam01.prod.protection.outlook.com>
 <BN3PR08MB117335DF5A3EC9A713A1928FF02B0@BN3PR08MB1173.namprd08.prod.outlook.com>
 <2CCEDCDB-96E8-4E35-A0F0-79B46ED83202@freyther.de>
 <BN3PR08MB11739D372669DED0C1462723F02E0@BN3PR08MB1173.namprd08.prod.outlook.com>
 <20160624194341.GL14342@nataraja>
 <BN3PR08MB1173CAFE42DDAB9540B9538EF0230@BN3PR08MB1173.namprd08.prod.outlook.com>
Message-ID: <62AEF7B6-0AB2-4235-A98D-F13A342761C3@gnumonks.org>

The problem is simply that both Holger and me are not the main authors of the PCU, we both maintain Osmocom only in the very limited spare time we have. All the original authors seem to have disappeared over time, without much care or attention what happens to the project afterwards.

Also Holger has been moving apartments and thus even less time then usual.  

Our work projects and priorities currently don't allow for much PCU work.

Furthermore, we still don't have any automatic regression testing in place, due to resource limitations on building such a system.  In absence e of that, as well as ab absence of users willing to manually test/follow current master, its hard to know if we break things when merging large patches.

All I can say at this  point is that you'll have to continue to be patient. I know its not very satisfactory, but it is the reality of a project that receives way too little attention and has too few active developers and contributors :/
-- 
Sent from a mobile device. Please excuse my brevity.