From andreas at eversberg.eu  Thu Nov  1 08:14:02 2012
From: andreas at eversberg.eu (jolly)
Date: Thu, 01 Nov 2012 09:14:02 +0100
Subject: openbts-p2.8-gprs-exp and pcu issues
In-Reply-To: <CAPPmnBhuEsejc1=BwkiZqQU2ih50b6aO3B-FRxci=m4N7LyMJQ@mail.gmail.com>
References: <CAPPmnBhWy7Yus2vjphmNaYTp3SxfRTP7c3EkQLLtgMcmYoSQfQ@mail.gmail.com>	<508B6DF5.6010609@eversberg.eu>	<CAPPmnBibg=9ePnky2F1Ep7E71neCxxrzamn_cXyrNbp_OV7R=w@mail.gmail.com>	<508F8ECB.8030207@eversberg.eu>	<CAPPmnBgiBpaTwn5voaop3Lw8mAo1H5LtKoCpHt-S2QWS6EWykA@mail.gmail.com>	<5090BE82.70703@eversberg.eu>
	<CAPPmnBhuEsejc1=BwkiZqQU2ih50b6aO3B-FRxci=m4N7LyMJQ@mail.gmail.com>
Message-ID: <50922F4A.3040101@eversberg.eu>

Vladimir Rolbin wrote:
> Hi Andreas and Ivan.
>  
> I've recorded three sessions, every one contains pcu log with print
> fix andreas asked (rlcmac_*.log) and corresponding  GSMTAP and Gb pcap:
>  
> 1)  openBTS pulled from git on 31.10.2012 (with gsmtap support for
> PDCH), UE - Nokia 5000d.
>       I have very bad results with Nokia and SonyEriccsson
> devices with not modified git branch.
>       As I wrote before I guess  they are sensitive to non-standard L2
> pseudo length. Immediate Assignment
>       is already fixed for now but SI13 is not. I sent my
> modifications before.. a great part of them are
>       really debug prints, but the other one fixes the Nokia device
> behaviour ( session 2).
>  
> 2) modified openBTS merged   with openBTS pulled from git on
> 31.10.2012, UE - Nokia 5000d.
>      m.facebook.com <http://m.facebook.com> is successfully opened. No
> scheduler issues. But sometimes it  has..
>      I need to open more pages one after one to see the problem.
>  
> 3) modified openBTS merged   with openBTS pulled from git on
> 31.10.2012 (env is like in session 2).
>      UE - SonyEricsson z750i. A lot of scheduler issues (look for
> "unknown"). I think this UE is more
>      pedantic than others.
>  
>    Regards,
>    Vladimir Rolbin
>
>    
>  
>  
> On Wed, Oct 31, 2012 at 8:00 AM, jolly <andreas at eversberg.eu
> <mailto:andreas at eversberg.eu>> wrote:
>
>     Vladimir Rolbin wrote:
>     > gprs_rlcmac_data.cpp:1532 Polling sheduled in this TS 7
>     hi vladimir,
>
>     i missed something. this debug line above does not show us the frame
>     number. you can change that debug line to:
>
>     LOGP(DRLCMAC, LOGL_DEBUG, "Polling sheduled in this "
>         "TS %d, FN=%d\n", ts, fn);
>
>     regards,
>
>     andreas
>
>

hi vladimir,

ich looked at one situation (see z750i):

<0002> gprs_rlcmac_data.cpp:1532 Polling sheduled in this TS 7, FN=650918
<0002> gprs_rlcmac.cpp:983 Starting DL TBF=0 timer 3191.
<0006> gprs_rlcmac_sched.cpp:260 Received RTS for PDCH: TRX=0 TS=7
FN=650927 block_nr=10 scheduling free USF for polling at FN=650931 of DL
TFI=0
<0002> gprs_rlcmac_data.cpp:270 +++++++++++++++++++++++++ RX : Uplink
Control Block +++++++++++++++++++++++++
<0002> gprs_rlcmac_data.cpp:273 ------------------------- RX : Uplink
Control Block -------------------------
<0002> gprs_rlcmac_data.cpp:376 PACKET DOWNLINK ACK with unknown
FN=650927 TFI=0 (TRX 0 TS 7)

the polling of downlink frame is scheduled at FN 650918 (see no. 775 in
wireshark trace). as you can see, the rlcmac header starts with 0x0f
(first byte of the last 23 bytes of frame). these bits mean:
payload-type=00, rrbp=00, s/p=1, usf=111. the s/p is set, because
polling is requested. the rrbp indicates that the downlink ack message
is polled 13 frames later. but the message is received 9 frames later
(instead of 13), this is one block too early (see no. 781 in wireshark
trace).

i come to the solution, that the block (B8) starting at frame 650918 was
actually sent one block too early (B7) by openBTS at 650914, or the
frame number of the received block (downlink ack message) was set wrong.

regards,

andreas

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

From vrolbin at gmail.com  Thu Nov  1 09:57:48 2012
From: vrolbin at gmail.com (Vladimir Rolbin)
Date: Thu, 1 Nov 2012 11:57:48 +0200
Subject: openbts-p2.8-gprs-exp and pcu issues
In-Reply-To: <CA+QHiD8M0GYbXn3Ls0gwUe+gjwsBPSOgEOa18AUbxqgQo1k7SQ@mail.gmail.com>
References: <CAPPmnBhWy7Yus2vjphmNaYTp3SxfRTP7c3EkQLLtgMcmYoSQfQ@mail.gmail.com>
	<508B6DF5.6010609@eversberg.eu>
	<CAPPmnBibg=9ePnky2F1Ep7E71neCxxrzamn_cXyrNbp_OV7R=w@mail.gmail.com>
	<508F8ECB.8030207@eversberg.eu>
	<CAPPmnBgiBpaTwn5voaop3Lw8mAo1H5LtKoCpHt-S2QWS6EWykA@mail.gmail.com>
	<5090BE82.70703@eversberg.eu>
	<CAPPmnBhuEsejc1=BwkiZqQU2ih50b6aO3B-FRxci=m4N7LyMJQ@mail.gmail.com>
	<CA+QHiD8M0GYbXn3Ls0gwUe+gjwsBPSOgEOa18AUbxqgQo1k7SQ@mail.gmail.com>
Message-ID: <CAPPmnBiPFsUuyfNXUtnY-ZgDSg2+42UohEELEZOA-Wz-z1zzxg@mail.gmail.com>

Ok, actually it's everyone that contains rest octets..
Regards,
Vladimir Rolbin
On Thu, Nov 1, 2012 at 12:03 AM, Ivan Kluchnikov <
Ivan.Kluchnikov at fairwaves.ru> wrote:

> Hi, Vladimir!
>
> Thank you for sending logs and pcap files!
> I fixed L2 pseudo length bug, this problem was not only in SI13, but
> also in SI3.
> Now you can update your OpenBTS repository.
>
> 2012/10/31 Vladimir Rolbin <vrolbin at gmail.com>:
> > Hi Andreas and Ivan.
> >
> > I've recorded three sessions, every one contains pcu log with print fix
> > andreas asked (rlcmac_*.log) and corresponding  GSMTAP and Gb pcap:
> >
> > 1)  openBTS pulled from git on 31.10.2012 (with gsmtap support for
> PDCH), UE
> > - Nokia 5000d.
> >       I have very bad results with Nokia and SonyEriccsson devices with
> not
> > modified git branch.
> >       As I wrote before I guess  they are sensitive to non-standard L2
> > pseudo length. Immediate Assignment
> >       is already fixed for now but SI13 is not. I sent my modifications
> > before.. a great part of them are
> >       really debug prints, but the other one fixes the Nokia device
> > behaviour ( session 2).
> >
> > 2) modified openBTS merged   with openBTS pulled from git on 31.10.2012,
> UE
> > - Nokia 5000d.
> >      m.facebook.com is successfully opened. No scheduler issues. But
> > sometimes it  has..
> >      I need to open more pages one after one to see the problem.
> >
> > 3) modified openBTS merged   with openBTS pulled from git on 31.10.2012
> (env
> > is like in session 2).
> >      UE - SonyEricsson z750i. A lot of scheduler issues (look for
> > "unknown"). I think this UE is more
> >      pedantic than others.
> >
> >    Regards,
> >    Vladimir Rolbin
> >
> >
> >
> >
> > On Wed, Oct 31, 2012 at 8:00 AM, jolly <andreas at eversberg.eu> wrote:
> >>
> >> Vladimir Rolbin wrote:
> >> > gprs_rlcmac_data.cpp:1532 Polling sheduled in this TS 7
> >> hi vladimir,
> >>
> >> i missed something. this debug line above does not show us the frame
> >> number. you can change that debug line to:
> >>
> >> LOGP(DRLCMAC, LOGL_DEBUG, "Polling sheduled in this "
> >>     "TS %d, FN=%d\n", ts, fn);
> >>
> >> regards,
> >>
> >> andreas
> >>
> >
>
>
>
> --
> Regards,
> Ivan Kluchnikov.
> http://fairwaves.ru
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20121101/b6ace34b/attachment.htm>

From vrolbin at gmail.com  Thu Nov  1 16:59:49 2012
From: vrolbin at gmail.com (Vladimir Rolbin)
Date: Thu, 1 Nov 2012 18:59:49 +0200
Subject: openbts-p2.8-gprs-exp and pcu issues
In-Reply-To: <CA+QHiD8M0GYbXn3Ls0gwUe+gjwsBPSOgEOa18AUbxqgQo1k7SQ@mail.gmail.com>
References: <CAPPmnBhWy7Yus2vjphmNaYTp3SxfRTP7c3EkQLLtgMcmYoSQfQ@mail.gmail.com>
	<508B6DF5.6010609@eversberg.eu>
	<CAPPmnBibg=9ePnky2F1Ep7E71neCxxrzamn_cXyrNbp_OV7R=w@mail.gmail.com>
	<508F8ECB.8030207@eversberg.eu>
	<CAPPmnBgiBpaTwn5voaop3Lw8mAo1H5LtKoCpHt-S2QWS6EWykA@mail.gmail.com>
	<5090BE82.70703@eversberg.eu>
	<CAPPmnBhuEsejc1=BwkiZqQU2ih50b6aO3B-FRxci=m4N7LyMJQ@mail.gmail.com>
	<CA+QHiD8M0GYbXn3Ls0gwUe+gjwsBPSOgEOa18AUbxqgQo1k7SQ@mail.gmail.com>
Message-ID: <CAPPmnBgDk3JkYS-2+gVe+3SuRirdXtMXVjgny1xTEuvM1pxeuw@mail.gmail.com>

Hi, Ivan

1) First pls fix the following critical bug, readIndex  is modified by
readField cause delivered by reference, so every not first iteration it'll
have a bad value :

*** ./DCCHDispatch.bug.cpp 2012-11-01 12:33:43.000000000 +0200
--- ./DCCHDispatch.cpp 2012-11-01 16:48:29.000000000 +0200
***************
*** 469,474 ****
--- 469,475 ----
      }
      L3Frame *l3 = new L3Frame(msg->tail(8), UNIT_DATA);
      COUT("RX: [ BTS <- PCU ] AGCH: " << *l3);
+     readIndex = 0; //vr, fix
      l2Len = msg->readField(readIndex, len);
      l3->L2Length(l2Len);
      AGCH->send(l3);


or ( I like it more )

*** ./DCCHDispatch.bug.cpp 2012-11-01 12:33:43.000000000 +0200
--- ./DCCHDispatch.fix0.cpp 2012-11-01 17:58:15.000000000 +0200
***************
*** 431,438 ****

   char buf[MAX_UDP_LENGTH];

-  unsigned len = 6;
-  size_t readIndex = 0;
   size_t l2Len = 0;

   // Send to PCU PhConnectInd primitive.
--- 431,436 ----
***************
*** 469,475 ****
      }
      L3Frame *l3 = new L3Frame(msg->tail(8), UNIT_DATA);
      COUT("RX: [ BTS <- PCU ] AGCH: " << *l3);
!     l2Len = msg->readField(readIndex, len);
      l3->L2Length(l2Len);
      AGCH->send(l3);
      txPhDataIndCnf(*msg, gBTS.time());
--- 467,473 ----
      }
      L3Frame *l3 = new L3Frame(msg->tail(8), UNIT_DATA);
      COUT("RX: [ BTS <- PCU ] AGCH: " << *l3);
!     l2Len = msg->peekField(0, 6);
      l3->L2Length(l2Len);
      AGCH->send(l3);
      txPhDataIndCnf(*msg, gBTS.time());
***************
*** 479,486 ****
      L3Frame *msg1 = new L3Frame(msg->tail(8*4), UNIT_DATA);
      L3Frame *msg2 = new L3Frame(msg->tail(8*4), UNIT_DATA);
      COUT("RX: [ BTS <- PCU ] PCH: " << *msg1);
!     readIndex = 24;
!     l2Len = msg->readField(readIndex, len);
      msg1->L2Length(l2Len);
      msg2->L2Length(l2Len);
      // HACK -- We send every page twice.
--- 477,483 ----
      L3Frame *msg1 = new L3Frame(msg->tail(8*4), UNIT_DATA);
      L3Frame *msg2 = new L3Frame(msg->tail(8*4), UNIT_DATA);
      COUT("RX: [ BTS <- PCU ] PCH: " << *msg1);
!     l2Len = msg->peekField(8*3, 6);
      msg1->L2Length(l2Len);
      msg2->L2Length(l2Len);
      // HACK -- We send every page twice.


I would reccomend also to fix BitVector.cpp known bug:
void BitVector::unpack(const unsigned char* src)
{
 // Assumes MSB-first packing.
 unsigned bytes = size()/8;
 for (unsigned i=0; i<bytes; i++) {
  fillField(i*8,src[i],8);
 }
 unsigned whole = bytes*8;
 unsigned rem = size() - whole;
 if (rem==0) return;
        fillField(whole,src[bytes] >> (8-rem),rem); //here
}

USRPDevice.cpp known bug:
double USRPDevice::setTxGain(double dB) {

   writeLock.lock();
   if (dB > maxTxGain()) dB = maxTxGain();
   if (dB < minTxGain()) dB = minTxGain();
   LOG(NOTICE) << "Setting TX gain to " << dB << " dB.";
   if (!m_dbTx->set_gain(dB)) // here
     LOG(ERR) << "Error setting TX gain";
   writeLock.unlock();

   return dB;
}

BSIC calculation:

prim->u.info_ind.bsic = (gConfig.getNum("GSM.Identity.BSIC.NCC") << 3) |
gConfig.getNum("GSM.Identity.BSIC.BCC");



2) With up to date OpenBTS pulled from git today and critical fix only I've
got the results identical to session 2 and 3 I've recorded yesterday. I
attach the file with problematic scenario. I think you may recreate the
problem with every SonyErricson supporting 3G and GSM (my env is Suse 11.4
or Ubuntu 11.10, libusb_1_0 and libusrp-3.4.2).

Regards,
Vladimir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20121101/b6989bb8/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rlcmac_z750i_1.rar
Type: application/rar
Size: 15858 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20121101/b6989bb8/attachment.bin>

From Ivan.Kluchnikov at fairwaves.ru  Thu Nov  1 20:55:11 2012
From: Ivan.Kluchnikov at fairwaves.ru (Ivan Kluchnikov)
Date: Thu, 1 Nov 2012 23:55:11 +0300
Subject: openbts-p2.8-gprs-exp and pcu issues
In-Reply-To: <CAPPmnBgDk3JkYS-2+gVe+3SuRirdXtMXVjgny1xTEuvM1pxeuw@mail.gmail.com>
References: <CAPPmnBhWy7Yus2vjphmNaYTp3SxfRTP7c3EkQLLtgMcmYoSQfQ@mail.gmail.com>
	<508B6DF5.6010609@eversberg.eu>
	<CAPPmnBibg=9ePnky2F1Ep7E71neCxxrzamn_cXyrNbp_OV7R=w@mail.gmail.com>
	<508F8ECB.8030207@eversberg.eu>
	<CAPPmnBgiBpaTwn5voaop3Lw8mAo1H5LtKoCpHt-S2QWS6EWykA@mail.gmail.com>
	<5090BE82.70703@eversberg.eu>
	<CAPPmnBhuEsejc1=BwkiZqQU2ih50b6aO3B-FRxci=m4N7LyMJQ@mail.gmail.com>
	<CA+QHiD8M0GYbXn3Ls0gwUe+gjwsBPSOgEOa18AUbxqgQo1k7SQ@mail.gmail.com>
	<CAPPmnBgDk3JkYS-2+gVe+3SuRirdXtMXVjgny1xTEuvM1pxeuw@mail.gmail.com>
Message-ID: <CA+QHiD-GAoH-Y1LU2di4YvT5z-vXAdJE+6z7RqSpUj-f+ghaQw@mail.gmail.com>

Hi, Vladimir!

Thank you for your fixes, I will check and apply them tomorrow!
In attachment you can find patch for osmo-pcu.
I guess, that this patch should fix problem of receiving PACKET
DOWNLINK ACK messages with unknown FN.
Please, check it with your phones and notify me about results.

2012/11/1 Vladimir Rolbin <vrolbin at gmail.com>:
> Hi, Ivan
>
> 1) First pls fix the following critical bug, readIndex  is modified by
> readField cause delivered by reference, so every not first iteration it'll
> have a bad value :
>
> *** ./DCCHDispatch.bug.cpp 2012-11-01 12:33:43.000000000 +0200
> --- ./DCCHDispatch.cpp 2012-11-01 16:48:29.000000000 +0200
> ***************
> *** 469,474 ****
> --- 469,475 ----
>       }
>       L3Frame *l3 = new L3Frame(msg->tail(8), UNIT_DATA);
>       COUT("RX: [ BTS <- PCU ] AGCH: " << *l3);
> +     readIndex = 0; //vr, fix
>       l2Len = msg->readField(readIndex, len);
>       l3->L2Length(l2Len);
>       AGCH->send(l3);
>
>
> or ( I like it more )
>
> *** ./DCCHDispatch.bug.cpp 2012-11-01 12:33:43.000000000 +0200
> --- ./DCCHDispatch.fix0.cpp 2012-11-01 17:58:15.000000000 +0200
> ***************
> *** 431,438 ****
>
>    char buf[MAX_UDP_LENGTH];
>
> -  unsigned len = 6;
> -  size_t readIndex = 0;
>    size_t l2Len = 0;
>
>    // Send to PCU PhConnectInd primitive.
> --- 431,436 ----
> ***************
> *** 469,475 ****
>       }
>       L3Frame *l3 = new L3Frame(msg->tail(8), UNIT_DATA);
>       COUT("RX: [ BTS <- PCU ] AGCH: " << *l3);
> !     l2Len = msg->readField(readIndex, len);
>       l3->L2Length(l2Len);
>       AGCH->send(l3);
>       txPhDataIndCnf(*msg, gBTS.time());
> --- 467,473 ----
>       }
>       L3Frame *l3 = new L3Frame(msg->tail(8), UNIT_DATA);
>       COUT("RX: [ BTS <- PCU ] AGCH: " << *l3);
> !     l2Len = msg->peekField(0, 6);
>       l3->L2Length(l2Len);
>       AGCH->send(l3);
>       txPhDataIndCnf(*msg, gBTS.time());
> ***************
> *** 479,486 ****
>       L3Frame *msg1 = new L3Frame(msg->tail(8*4), UNIT_DATA);
>       L3Frame *msg2 = new L3Frame(msg->tail(8*4), UNIT_DATA);
>       COUT("RX: [ BTS <- PCU ] PCH: " << *msg1);
> !     readIndex = 24;
> !     l2Len = msg->readField(readIndex, len);
>       msg1->L2Length(l2Len);
>       msg2->L2Length(l2Len);
>       // HACK -- We send every page twice.
> --- 477,483 ----
>       L3Frame *msg1 = new L3Frame(msg->tail(8*4), UNIT_DATA);
>       L3Frame *msg2 = new L3Frame(msg->tail(8*4), UNIT_DATA);
>       COUT("RX: [ BTS <- PCU ] PCH: " << *msg1);
> !     l2Len = msg->peekField(8*3, 6);
>       msg1->L2Length(l2Len);
>       msg2->L2Length(l2Len);
>       // HACK -- We send every page twice.
>
>
> I would reccomend also to fix BitVector.cpp known bug:
> void BitVector::unpack(const unsigned char* src)
> {
>  // Assumes MSB-first packing.
>  unsigned bytes = size()/8;
>  for (unsigned i=0; i<bytes; i++) {
>   fillField(i*8,src[i],8);
>  }
>  unsigned whole = bytes*8;
>  unsigned rem = size() - whole;
>  if (rem==0) return;
>         fillField(whole,src[bytes] >> (8-rem),rem); //here
> }
>
> USRPDevice.cpp known bug:
> double USRPDevice::setTxGain(double dB) {
>
>    writeLock.lock();
>    if (dB > maxTxGain()) dB = maxTxGain();
>    if (dB < minTxGain()) dB = minTxGain();
>    LOG(NOTICE) << "Setting TX gain to " << dB << " dB.";
>    if (!m_dbTx->set_gain(dB)) // here
>      LOG(ERR) << "Error setting TX gain";
>    writeLock.unlock();
>
>    return dB;
> }
>
> BSIC calculation:
>
> prim->u.info_ind.bsic = (gConfig.getNum("GSM.Identity.BSIC.NCC") << 3) |
> gConfig.getNum("GSM.Identity.BSIC.BCC");
>
>
>
> 2) With up to date OpenBTS pulled from git today and critical fix only I've
> got the results identical to session 2 and 3 I've recorded yesterday. I
> attach the file with problematic scenario. I think you may recreate the
> problem with every SonyErricson supporting 3G and GSM (my env is Suse 11.4
> or Ubuntu 11.10, libusb_1_0 and libusrp-3.4.2).
>
> Regards,
> Vladimir
>



-- 
Regards,
Ivan Kluchnikov.
http://fairwaves.ru
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pcu.patch
Type: application/octet-stream
Size: 2771 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20121101/0157241a/attachment.obj>

From vrolbin at gmail.com  Thu Nov  1 23:11:20 2012
From: vrolbin at gmail.com (Vladimir Rolbin)
Date: Fri, 2 Nov 2012 01:11:20 +0200
Subject: openbts-p2.8-gprs-exp and pcu issues
In-Reply-To: <CA+QHiD-GAoH-Y1LU2di4YvT5z-vXAdJE+6z7RqSpUj-f+ghaQw@mail.gmail.com>
References: <CAPPmnBhWy7Yus2vjphmNaYTp3SxfRTP7c3EkQLLtgMcmYoSQfQ@mail.gmail.com>
	<508B6DF5.6010609@eversberg.eu>
	<CAPPmnBibg=9ePnky2F1Ep7E71neCxxrzamn_cXyrNbp_OV7R=w@mail.gmail.com>
	<508F8ECB.8030207@eversberg.eu>
	<CAPPmnBgiBpaTwn5voaop3Lw8mAo1H5LtKoCpHt-S2QWS6EWykA@mail.gmail.com>
	<5090BE82.70703@eversberg.eu>
	<CAPPmnBhuEsejc1=BwkiZqQU2ih50b6aO3B-FRxci=m4N7LyMJQ@mail.gmail.com>
	<CA+QHiD8M0GYbXn3Ls0gwUe+gjwsBPSOgEOa18AUbxqgQo1k7SQ@mail.gmail.com>
	<CAPPmnBgDk3JkYS-2+gVe+3SuRirdXtMXVjgny1xTEuvM1pxeuw@mail.gmail.com>
	<CA+QHiD-GAoH-Y1LU2di4YvT5z-vXAdJE+6z7RqSpUj-f+ghaQw@mail.gmail.com>
Message-ID: <CAPPmnBi-6bNUsBYEDm5oeEMW0PVCjbT4qa-oBBs5YO-D0nHgUg@mail.gmail.com>

Ok, thanks for patch. I will be able to ckeck ot only on Sunday ..

Regards,
Vladimir


On Thu, Nov 1, 2012 at 10:55 PM, Ivan Kluchnikov <
Ivan.Kluchnikov at fairwaves.ru> wrote:

> Hi, Vladimir!
>
> Thank you for your fixes, I will check and apply them tomorrow!
> In attachment you can find patch for osmo-pcu.
> I guess, that this patch should fix problem of receiving PACKET
> DOWNLINK ACK messages with unknown FN.
> Please, check it with your phones and notify me about results.
>
> 2012/11/1 Vladimir Rolbin <vrolbin at gmail.com>:
> > Hi, Ivan
> >
> > 1) First pls fix the following critical bug, readIndex  is modified by
> > readField cause delivered by reference, so every not first iteration
> it'll
> > have a bad value :
> >
> > *** ./DCCHDispatch.bug.cpp 2012-11-01 12:33:43.000000000 +0200
> > --- ./DCCHDispatch.cpp 2012-11-01 16:48:29.000000000 +0200
> > ***************
> > *** 469,474 ****
> > --- 469,475 ----
> >       }
> >       L3Frame *l3 = new L3Frame(msg->tail(8), UNIT_DATA);
> >       COUT("RX: [ BTS <- PCU ] AGCH: " << *l3);
> > +     readIndex = 0; //vr, fix
> >       l2Len = msg->readField(readIndex, len);
> >       l3->L2Length(l2Len);
> >       AGCH->send(l3);
> >
> >
> > or ( I like it more )
> >
> > *** ./DCCHDispatch.bug.cpp 2012-11-01 12:33:43.000000000 +0200
> > --- ./DCCHDispatch.fix0.cpp 2012-11-01 17:58:15.000000000 +0200
> > ***************
> > *** 431,438 ****
> >
> >    char buf[MAX_UDP_LENGTH];
> >
> > -  unsigned len = 6;
> > -  size_t readIndex = 0;
> >    size_t l2Len = 0;
> >
> >    // Send to PCU PhConnectInd primitive.
> > --- 431,436 ----
> > ***************
> > *** 469,475 ****
> >       }
> >       L3Frame *l3 = new L3Frame(msg->tail(8), UNIT_DATA);
> >       COUT("RX: [ BTS <- PCU ] AGCH: " << *l3);
> > !     l2Len = msg->readField(readIndex, len);
> >       l3->L2Length(l2Len);
> >       AGCH->send(l3);
> >       txPhDataIndCnf(*msg, gBTS.time());
> > --- 467,473 ----
> >       }
> >       L3Frame *l3 = new L3Frame(msg->tail(8), UNIT_DATA);
> >       COUT("RX: [ BTS <- PCU ] AGCH: " << *l3);
> > !     l2Len = msg->peekField(0, 6);
> >       l3->L2Length(l2Len);
> >       AGCH->send(l3);
> >       txPhDataIndCnf(*msg, gBTS.time());
> > ***************
> > *** 479,486 ****
> >       L3Frame *msg1 = new L3Frame(msg->tail(8*4), UNIT_DATA);
> >       L3Frame *msg2 = new L3Frame(msg->tail(8*4), UNIT_DATA);
> >       COUT("RX: [ BTS <- PCU ] PCH: " << *msg1);
> > !     readIndex = 24;
> > !     l2Len = msg->readField(readIndex, len);
> >       msg1->L2Length(l2Len);
> >       msg2->L2Length(l2Len);
> >       // HACK -- We send every page twice.
> > --- 477,483 ----
> >       L3Frame *msg1 = new L3Frame(msg->tail(8*4), UNIT_DATA);
> >       L3Frame *msg2 = new L3Frame(msg->tail(8*4), UNIT_DATA);
> >       COUT("RX: [ BTS <- PCU ] PCH: " << *msg1);
> > !     l2Len = msg->peekField(8*3, 6);
> >       msg1->L2Length(l2Len);
> >       msg2->L2Length(l2Len);
> >       // HACK -- We send every page twice.
> >
> >
> > I would reccomend also to fix BitVector.cpp known bug:
> > void BitVector::unpack(const unsigned char* src)
> > {
> >  // Assumes MSB-first packing.
> >  unsigned bytes = size()/8;
> >  for (unsigned i=0; i<bytes; i++) {
> >   fillField(i*8,src[i],8);
> >  }
> >  unsigned whole = bytes*8;
> >  unsigned rem = size() - whole;
> >  if (rem==0) return;
> >         fillField(whole,src[bytes] >> (8-rem),rem); //here
> > }
> >
> > USRPDevice.cpp known bug:
> > double USRPDevice::setTxGain(double dB) {
> >
> >    writeLock.lock();
> >    if (dB > maxTxGain()) dB = maxTxGain();
> >    if (dB < minTxGain()) dB = minTxGain();
> >    LOG(NOTICE) << "Setting TX gain to " << dB << " dB.";
> >    if (!m_dbTx->set_gain(dB)) // here
> >      LOG(ERR) << "Error setting TX gain";
> >    writeLock.unlock();
> >
> >    return dB;
> > }
> >
> > BSIC calculation:
> >
> > prim->u.info_ind.bsic = (gConfig.getNum("GSM.Identity.BSIC.NCC") << 3) |
> > gConfig.getNum("GSM.Identity.BSIC.BCC");
> >
> >
> >
> > 2) With up to date OpenBTS pulled from git today and critical fix only
> I've
> > got the results identical to session 2 and 3 I've recorded yesterday. I
> > attach the file with problematic scenario. I think you may recreate the
> > problem with every SonyErricson supporting 3G and GSM (my env is Suse
> 11.4
> > or Ubuntu 11.10, libusb_1_0 and libusrp-3.4.2).
> >
> > Regards,
> > Vladimir
> >
>
>
>
> --
> Regards,
> Ivan Kluchnikov.
> http://fairwaves.ru
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20121102/3118f66d/attachment.htm>

From andreas at eversberg.eu  Sun Nov  4 06:58:39 2012
From: andreas at eversberg.eu (jolly)
Date: Sun, 04 Nov 2012 07:58:39 +0100
Subject: openbts-p2.8-gprs-exp and pcu issues
In-Reply-To: <CA+QHiD-GAoH-Y1LU2di4YvT5z-vXAdJE+6z7RqSpUj-f+ghaQw@mail.gmail.com>
References: <CAPPmnBhWy7Yus2vjphmNaYTp3SxfRTP7c3EkQLLtgMcmYoSQfQ@mail.gmail.com>	<508B6DF5.6010609@eversberg.eu>	<CAPPmnBibg=9ePnky2F1Ep7E71neCxxrzamn_cXyrNbp_OV7R=w@mail.gmail.com>	<508F8ECB.8030207@eversberg.eu>	<CAPPmnBgiBpaTwn5voaop3Lw8mAo1H5LtKoCpHt-S2QWS6EWykA@mail.gmail.com>	<5090BE82.70703@eversberg.eu>	<CAPPmnBhuEsejc1=BwkiZqQU2ih50b6aO3B-FRxci=m4N7LyMJQ@mail.gmail.com>	<CA+QHiD8M0GYbXn3Ls0gwUe+gjwsBPSOgEOa18AUbxqgQo1k7SQ@mail.gmail.com>	<CAPPmnBgDk3JkYS-2+gVe+3SuRirdXtMXVjgny1xTEuvM1pxeuw@mail.gmail.com>
	<CA+QHiD-GAoH-Y1LU2di4YvT5z-vXAdJE+6z7RqSpUj-f+ghaQw@mail.gmail.com>
Message-ID: <5096121F.1080004@eversberg.eu>

Ivan Kluchnikov wrote:
> In attachment you can find patch for osmo-pcu.
>   

hi ivan,

i looked at you patch. it primarily removes the ability to re-assign an
existing downlink TBF on PACCH:

-       if (old_tbf) {
+       if (old_tbf&&(old_tbf->direction == GPRS_RLCMAC_UL_TBF)) {

a downlink TBF will, after polling the final ack, start T3193 and exist
until T3193 times out.  the value for that timer is set by BTS. on the
phone T3192 is running, which is a little shorter. the phone will stay
on PDCH and listens for re-assignment on PACCH until T3192 times out.
T3192 is set by system information message. what settings do you have
for these two timers?

there are three cases where assignment on PACCH is performed:

1. at gprs_rlcmac_downlink_ack() the
gprs_rlcmac_trigger_downlink_assignment() is called, if the dowlink TBF
has just finished, but more frames already arrived from SGSN. (T3193 not
started yet, but MS will have T3192 running.)
2. at gprs_bssgp_pcu_rx_dl_ud() the
gprs_rlcmac_trigger_downlink_assignment() is called, if the dowlink TBF
still exists because a frame has arrived from SGSN. (T3193 running, and
so T3192 on the MS.)
3. at gprs_bssgp_pcu_rx_dl_ud() the
gprs_rlcmac_trigger_downlink_assignment() is called, if an uplink TBF
exists because a frame has arrived from SGSN.

in your patch you changed the condition for triggering downlink
assignment on PACCH to uplink TBF only. This would break the case where
T3193 is still pending and the re-use of downlink TBF.

the case where a downlink TBF still exists would result in a PCH/AGCH
assignment, which causes problems, especially when multislot allocation
is used. this is because the selected (multiple) slots at
gprs_bssgp_pcu_rx_dl_ud() cannot be assigned on PCH/AGCH, just only one.

i cannot see what your decision for your patch was. i guess that SI 13
uses a low or no T3192 timer value.

regards,

andreas




From vrolbin at gmail.com  Sun Nov  4 09:59:57 2012
From: vrolbin at gmail.com (Vladimir Rolbin)
Date: Sun, 4 Nov 2012 11:59:57 +0200
Subject: openbts-p2.8-gprs-exp and pcu issues
In-Reply-To: <5096121F.1080004@eversberg.eu>
References: <CAPPmnBhWy7Yus2vjphmNaYTp3SxfRTP7c3EkQLLtgMcmYoSQfQ@mail.gmail.com>
	<508B6DF5.6010609@eversberg.eu>
	<CAPPmnBibg=9ePnky2F1Ep7E71neCxxrzamn_cXyrNbp_OV7R=w@mail.gmail.com>
	<508F8ECB.8030207@eversberg.eu>
	<CAPPmnBgiBpaTwn5voaop3Lw8mAo1H5LtKoCpHt-S2QWS6EWykA@mail.gmail.com>
	<5090BE82.70703@eversberg.eu>
	<CAPPmnBhuEsejc1=BwkiZqQU2ih50b6aO3B-FRxci=m4N7LyMJQ@mail.gmail.com>
	<CA+QHiD8M0GYbXn3Ls0gwUe+gjwsBPSOgEOa18AUbxqgQo1k7SQ@mail.gmail.com>
	<CAPPmnBgDk3JkYS-2+gVe+3SuRirdXtMXVjgny1xTEuvM1pxeuw@mail.gmail.com>
	<CA+QHiD-GAoH-Y1LU2di4YvT5z-vXAdJE+6z7RqSpUj-f+ghaQw@mail.gmail.com>
	<5096121F.1080004@eversberg.eu>
Message-ID: <CAPPmnBh7n-CgEQ+F+msOKp5gavC8T7iHXCC+=ypcpjCYg37YTQ@mail.gmail.com>

hi,

T3192 is 500 ms for my env set..

Regards,
Vladimir


On Sun, Nov 4, 2012 at 8:58 AM, jolly <andreas at eversberg.eu> wrote:

> Ivan Kluchnikov wrote:
> > In attachment you can find patch for osmo-pcu.
> >
>
> hi ivan,
>
> i looked at you patch. it primarily removes the ability to re-assign an
> existing downlink TBF on PACCH:
>
> -       if (old_tbf) {
> +       if (old_tbf&&(old_tbf->direction == GPRS_RLCMAC_UL_TBF)) {
>
> a downlink TBF will, after polling the final ack, start T3193 and exist
> until T3193 times out.  the value for that timer is set by BTS. on the
> phone T3192 is running, which is a little shorter. the phone will stay
> on PDCH and listens for re-assignment on PACCH until T3192 times out.
> T3192 is set by system information message. what settings do you have
> for these two timers?
>
> there are three cases where assignment on PACCH is performed:
>
> 1. at gprs_rlcmac_downlink_ack() the
> gprs_rlcmac_trigger_downlink_assignment() is called, if the dowlink TBF
> has just finished, but more frames already arrived from SGSN. (T3193 not
> started yet, but MS will have T3192 running.)
> 2. at gprs_bssgp_pcu_rx_dl_ud() the
> gprs_rlcmac_trigger_downlink_assignment() is called, if the dowlink TBF
> still exists because a frame has arrived from SGSN. (T3193 running, and
> so T3192 on the MS.)
> 3. at gprs_bssgp_pcu_rx_dl_ud() the
> gprs_rlcmac_trigger_downlink_assignment() is called, if an uplink TBF
> exists because a frame has arrived from SGSN.
>
> in your patch you changed the condition for triggering downlink
> assignment on PACCH to uplink TBF only. This would break the case where
> T3193 is still pending and the re-use of downlink TBF.
>
> the case where a downlink TBF still exists would result in a PCH/AGCH
> assignment, which causes problems, especially when multislot allocation
> is used. this is because the selected (multiple) slots at
> gprs_bssgp_pcu_rx_dl_ud() cannot be assigned on PCH/AGCH, just only one.
>
> i cannot see what your decision for your patch was. i guess that SI 13
> uses a low or no T3192 timer value.
>
> regards,
>
> andreas
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20121104/3616fac4/attachment.htm>

From vrolbin at gmail.com  Sun Nov  4 13:13:52 2012
From: vrolbin at gmail.com (Vladimir Rolbin)
Date: Sun, 4 Nov 2012 15:13:52 +0200
Subject: openbts-p2.8-gprs-exp and pcu issues
In-Reply-To: <CA+QHiD-GAoH-Y1LU2di4YvT5z-vXAdJE+6z7RqSpUj-f+ghaQw@mail.gmail.com>
References: <CAPPmnBhWy7Yus2vjphmNaYTp3SxfRTP7c3EkQLLtgMcmYoSQfQ@mail.gmail.com>
	<508B6DF5.6010609@eversberg.eu>
	<CAPPmnBibg=9ePnky2F1Ep7E71neCxxrzamn_cXyrNbp_OV7R=w@mail.gmail.com>
	<508F8ECB.8030207@eversberg.eu>
	<CAPPmnBgiBpaTwn5voaop3Lw8mAo1H5LtKoCpHt-S2QWS6EWykA@mail.gmail.com>
	<5090BE82.70703@eversberg.eu>
	<CAPPmnBhuEsejc1=BwkiZqQU2ih50b6aO3B-FRxci=m4N7LyMJQ@mail.gmail.com>
	<CA+QHiD8M0GYbXn3Ls0gwUe+gjwsBPSOgEOa18AUbxqgQo1k7SQ@mail.gmail.com>
	<CAPPmnBgDk3JkYS-2+gVe+3SuRirdXtMXVjgny1xTEuvM1pxeuw@mail.gmail.com>
	<CA+QHiD-GAoH-Y1LU2di4YvT5z-vXAdJE+6z7RqSpUj-f+ghaQw@mail.gmail.com>
Message-ID: <CAPPmnBixUtfZXrAJypFHqr=XsjJdh361o8Z7mqR+DLTM7TE4_g@mail.gmail.com>

Hi, Ivan.

Unfortunately I don't see any improvement after applying the patch. The
logs are attached..

Regards,
Vladimir


On Thu, Nov 1, 2012 at 10:55 PM, Ivan Kluchnikov <
Ivan.Kluchnikov at fairwaves.ru> wrote:

> Hi, Vladimir!
>
> Thank you for your fixes, I will check and apply them tomorrow!
> In attachment you can find patch for osmo-pcu.
> I guess, that this patch should fix problem of receiving PACKET
> DOWNLINK ACK messages with unknown FN.
> Please, check it with your phones and notify me about results.
>
> 2012/11/1 Vladimir Rolbin <vrolbin at gmail.com>:
> > Hi, Ivan
> >
> > 1) First pls fix the following critical bug, readIndex  is modified by
> > readField cause delivered by reference, so every not first iteration
> it'll
> > have a bad value :
> >
> > *** ./DCCHDispatch.bug.cpp 2012-11-01 12:33:43.000000000 +0200
> > --- ./DCCHDispatch.cpp 2012-11-01 16:48:29.000000000 +0200
> > ***************
> > *** 469,474 ****
> > --- 469,475 ----
> >       }
> >       L3Frame *l3 = new L3Frame(msg->tail(8), UNIT_DATA);
> >       COUT("RX: [ BTS <- PCU ] AGCH: " << *l3);
> > +     readIndex = 0; //vr, fix
> >       l2Len = msg->readField(readIndex, len);
> >       l3->L2Length(l2Len);
> >       AGCH->send(l3);
> >
> >
> > or ( I like it more )
> >
> > *** ./DCCHDispatch.bug.cpp 2012-11-01 12:33:43.000000000 +0200
> > --- ./DCCHDispatch.fix0.cpp 2012-11-01 17:58:15.000000000 +0200
> > ***************
> > *** 431,438 ****
> >
> >    char buf[MAX_UDP_LENGTH];
> >
> > -  unsigned len = 6;
> > -  size_t readIndex = 0;
> >    size_t l2Len = 0;
> >
> >    // Send to PCU PhConnectInd primitive.
> > --- 431,436 ----
> > ***************
> > *** 469,475 ****
> >       }
> >       L3Frame *l3 = new L3Frame(msg->tail(8), UNIT_DATA);
> >       COUT("RX: [ BTS <- PCU ] AGCH: " << *l3);
> > !     l2Len = msg->readField(readIndex, len);
> >       l3->L2Length(l2Len);
> >       AGCH->send(l3);
> >       txPhDataIndCnf(*msg, gBTS.time());
> > --- 467,473 ----
> >       }
> >       L3Frame *l3 = new L3Frame(msg->tail(8), UNIT_DATA);
> >       COUT("RX: [ BTS <- PCU ] AGCH: " << *l3);
> > !     l2Len = msg->peekField(0, 6);
> >       l3->L2Length(l2Len);
> >       AGCH->send(l3);
> >       txPhDataIndCnf(*msg, gBTS.time());
> > ***************
> > *** 479,486 ****
> >       L3Frame *msg1 = new L3Frame(msg->tail(8*4), UNIT_DATA);
> >       L3Frame *msg2 = new L3Frame(msg->tail(8*4), UNIT_DATA);
> >       COUT("RX: [ BTS <- PCU ] PCH: " << *msg1);
> > !     readIndex = 24;
> > !     l2Len = msg->readField(readIndex, len);
> >       msg1->L2Length(l2Len);
> >       msg2->L2Length(l2Len);
> >       // HACK -- We send every page twice.
> > --- 477,483 ----
> >       L3Frame *msg1 = new L3Frame(msg->tail(8*4), UNIT_DATA);
> >       L3Frame *msg2 = new L3Frame(msg->tail(8*4), UNIT_DATA);
> >       COUT("RX: [ BTS <- PCU ] PCH: " << *msg1);
> > !     l2Len = msg->peekField(8*3, 6);
> >       msg1->L2Length(l2Len);
> >       msg2->L2Length(l2Len);
> >       // HACK -- We send every page twice.
> >
> >
> > I would reccomend also to fix BitVector.cpp known bug:
> > void BitVector::unpack(const unsigned char* src)
> > {
> >  // Assumes MSB-first packing.
> >  unsigned bytes = size()/8;
> >  for (unsigned i=0; i<bytes; i++) {
> >   fillField(i*8,src[i],8);
> >  }
> >  unsigned whole = bytes*8;
> >  unsigned rem = size() - whole;
> >  if (rem==0) return;
> >         fillField(whole,src[bytes] >> (8-rem),rem); //here
> > }
> >
> > USRPDevice.cpp known bug:
> > double USRPDevice::setTxGain(double dB) {
> >
> >    writeLock.lock();
> >    if (dB > maxTxGain()) dB = maxTxGain();
> >    if (dB < minTxGain()) dB = minTxGain();
> >    LOG(NOTICE) << "Setting TX gain to " << dB << " dB.";
> >    if (!m_dbTx->set_gain(dB)) // here
> >      LOG(ERR) << "Error setting TX gain";
> >    writeLock.unlock();
> >
> >    return dB;
> > }
> >
> > BSIC calculation:
> >
> > prim->u.info_ind.bsic = (gConfig.getNum("GSM.Identity.BSIC.NCC") << 3) |
> > gConfig.getNum("GSM.Identity.BSIC.BCC");
> >
> >
> >
> > 2) With up to date OpenBTS pulled from git today and critical fix only
> I've
> > got the results identical to session 2 and 3 I've recorded yesterday. I
> > attach the file with problematic scenario. I think you may recreate the
> > problem with every SonyErricson supporting 3G and GSM (my env is Suse
> 11.4
> > or Ubuntu 11.10, libusb_1_0 and libusrp-3.4.2).
> >
> > Regards,
> > Vladimir
> >
>
>
>
> --
> Regards,
> Ivan Kluchnikov.
> http://fairwaves.ru
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20121104/bef5786d/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rlcmac_z750i_2.rar
Type: application/rar
Size: 32711 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20121104/bef5786d/attachment.bin>

From andreas at eversberg.eu  Mon Nov  5 09:58:14 2012
From: andreas at eversberg.eu (jolly)
Date: Mon, 05 Nov 2012 10:58:14 +0100
Subject: openbts-p2.8-gprs-exp and pcu issues
In-Reply-To: <CAPPmnBh7n-CgEQ+F+msOKp5gavC8T7iHXCC+=ypcpjCYg37YTQ@mail.gmail.com>
References: <CAPPmnBhWy7Yus2vjphmNaYTp3SxfRTP7c3EkQLLtgMcmYoSQfQ@mail.gmail.com>	<508B6DF5.6010609@eversberg.eu>	<CAPPmnBibg=9ePnky2F1Ep7E71neCxxrzamn_cXyrNbp_OV7R=w@mail.gmail.com>	<508F8ECB.8030207@eversberg.eu>	<CAPPmnBgiBpaTwn5voaop3Lw8mAo1H5LtKoCpHt-S2QWS6EWykA@mail.gmail.com>	<5090BE82.70703@eversberg.eu>	<CAPPmnBhuEsejc1=BwkiZqQU2ih50b6aO3B-FRxci=m4N7LyMJQ@mail.gmail.com>	<CA+QHiD8M0GYbXn3Ls0gwUe+gjwsBPSOgEOa18AUbxqgQo1k7SQ@mail.gmail.com>	<CAPPmnBgDk3JkYS-2+gVe+3SuRirdXtMXVjgny1xTEuvM1pxeuw@mail.gmail.com>	<CA+QHiD-GAoH-Y1LU2di4YvT5z-vXAdJE+6z7RqSpUj-f+ghaQw@mail.gmail.com>	<5096121F.1080004@eversberg.eu>
	<CAPPmnBh7n-CgEQ+F+msOKp5gavC8T7iHXCC+=ypcpjCYg37YTQ@mail.gmail.com>
Message-ID: <50978DB6.7010704@eversberg.eu>

Vladimir Rolbin wrote:
> T3192 is 500 ms for my env set..
hi vladimir,

what is the value for T3193? i suggest to use similar value like 500.
this would be a value of 50, received via pcu socket interface.

in my case i use 1500ms for T3192 and T3193. this way the downlink TBF
will be kept longer.

regards,

andreas




From vrolbin at gmail.com  Mon Nov  5 11:16:20 2012
From: vrolbin at gmail.com (Vladimir Rolbin)
Date: Mon, 5 Nov 2012 13:16:20 +0200
Subject: openbts-p2.8-gprs-exp and pcu issues
In-Reply-To: <50978DB6.7010704@eversberg.eu>
References: <CAPPmnBhWy7Yus2vjphmNaYTp3SxfRTP7c3EkQLLtgMcmYoSQfQ@mail.gmail.com>
	<508B6DF5.6010609@eversberg.eu>
	<CAPPmnBibg=9ePnky2F1Ep7E71neCxxrzamn_cXyrNbp_OV7R=w@mail.gmail.com>
	<508F8ECB.8030207@eversberg.eu>
	<CAPPmnBgiBpaTwn5voaop3Lw8mAo1H5LtKoCpHt-S2QWS6EWykA@mail.gmail.com>
	<5090BE82.70703@eversberg.eu>
	<CAPPmnBhuEsejc1=BwkiZqQU2ih50b6aO3B-FRxci=m4N7LyMJQ@mail.gmail.com>
	<CA+QHiD8M0GYbXn3Ls0gwUe+gjwsBPSOgEOa18AUbxqgQo1k7SQ@mail.gmail.com>
	<CAPPmnBgDk3JkYS-2+gVe+3SuRirdXtMXVjgny1xTEuvM1pxeuw@mail.gmail.com>
	<CA+QHiD-GAoH-Y1LU2di4YvT5z-vXAdJE+6z7RqSpUj-f+ghaQw@mail.gmail.com>
	<5096121F.1080004@eversberg.eu>
	<CAPPmnBh7n-CgEQ+F+msOKp5gavC8T7iHXCC+=ypcpjCYg37YTQ@mail.gmail.com>
	<50978DB6.7010704@eversberg.eu>
Message-ID: <CAPPmnBgJaiV7JqeTbVaOAVVvPMgeaPBUVvE_KOE9xEzYZ8C5sg@mail.gmail.com>

T3193 is 1000 (100 * 10).. U can see it in logs.. I''ll do tests with T3192
= T3193 = 1500 ..

Thanks,
Vladimir


On Mon, Nov 5, 2012 at 11:58 AM, jolly <andreas at eversberg.eu> wrote:

> Vladimir Rolbin wrote:
> > T3192 is 500 ms for my env set..
> hi vladimir,
>
> what is the value for T3193? i suggest to use similar value like 500.
> this would be a value of 50, received via pcu socket interface.
>
> in my case i use 1500ms for T3192 and T3193. this way the downlink TBF
> will be kept longer.
>
> regards,
>
> andreas
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20121105/237c980a/attachment.htm>

From laforge at gnumonks.org  Sat Nov 24 21:55:19 2012
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 24 Nov 2012 22:55:19 +0100
Subject: lack of progress in PCU patch merging / git (ab)use
Message-ID: <20121124215519.GA21201@prithivi.gnumonks.org>

Dear all,

it is a pity to see that since many weeks there has been no progress on
merging any of Andreas' work.  I think everyone involved is to be
blamed to some extent.  Andreas because the provided branches are not
kept clean, Ivan probably for lack of time, and me for not paying more
attention and helping this process along.

The general life-cycle in any project, including osmo-pcu, should be as
follows:

* contributor starts on some improvements, creates private branch
* master advances meanwhile
* contributor rebases (not merges!) his changes on top of more recent
  master
* contributor indicates that his branch is ready for merge
* maintainer merges (some of?) the commits of the contributor branch
* contributor re-bases remaining commits on new master
* contributor requests merge of remaing patches
...

If I open 'gitk' on any of the branches (master / jolly / jolly_dsp) I
get grey hair (to say the least).  One would normally expect:

1) 'jolly' to be based on some (maybe not current) master

2) 'jolly_dsp' to be based on 'jolly'

Neither of the two is the case.  I've tried to
* rebase jolly on top of master
as well as
* rebase jolly_dsp on top of jolly

and both are impossible due to the series of merges and the unclear
ancestry / relationship of the branches.  Or, just for fun, try 'git
diff origin/jolly..origin/jolly_dsp.  It shows you anything else but
what one would expect

Andreas: Please take some time to clean up the mess.  Your 'jolly'
branch should contain a series of clean per-feature commit's on top of
current master, and 'jolly_dsp' should be a set of few patches on top of
'jolly'.

This way there is always a clean queue of changesets that Ivan can merge
(or cherry-pick).  I can understand that if I was in Ivan's place, I
would not really know where to even start merging some of those
contributions.

Thanks for everyone's attention.  Please take some time to get this
resolved.  Let me know if you have some questions.  There are plenty of
people with lots of git experience around (Holger, Pablo, myself) who
can help if something is unclear.

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 Ivan.Kluchnikov at fairwaves.ru  Mon Nov 26 13:02:34 2012
From: Ivan.Kluchnikov at fairwaves.ru (Ivan Kluchnikov)
Date: Mon, 26 Nov 2012 16:02:34 +0300
Subject: lack of progress in PCU patch merging / git (ab)use
In-Reply-To: <20121124215519.GA21201@prithivi.gnumonks.org>
References: <20121124215519.GA21201@prithivi.gnumonks.org>
Message-ID: <CA+QHiD8w96iwu8LvhhsguugEVUoSM7a29+_CSr8vRXN8cfwwqg@mail.gmail.com>

Hi, all!

I absolutely agree with Harald and I am ready to use described life-cycle
model for osmo-pcu.
Before that time I merged  branch 'jolly', when the differences between
master and jolly become critical.
I didn't coordinate merges with Andreas and jolly branch wasn't rebased
before merges. I think, it was my mistake.
Now I am ready to merge jolly branch at any time, when Andreas indicates
that his branch is ready for merge.

2012/11/25 Harald Welte <laforge at gnumonks.org>

> Dear all,
>
> it is a pity to see that since many weeks there has been no progress on
> merging any of Andreas' work.  I think everyone involved is to be
> blamed to some extent.  Andreas because the provided branches are not
> kept clean, Ivan probably for lack of time, and me for not paying more
> attention and helping this process along.
>
> The general life-cycle in any project, including osmo-pcu, should be as
> follows:
>
> * contributor starts on some improvements, creates private branch
> * master advances meanwhile
> * contributor rebases (not merges!) his changes on top of more recent
>   master
> * contributor indicates that his branch is ready for merge
> * maintainer merges (some of?) the commits of the contributor branch
> * contributor re-bases remaining commits on new master
> * contributor requests merge of remaing patches
> ...
>
> If I open 'gitk' on any of the branches (master / jolly / jolly_dsp) I
> get grey hair (to say the least).  One would normally expect:
>
> 1) 'jolly' to be based on some (maybe not current) master
>
> 2) 'jolly_dsp' to be based on 'jolly'
>
> Neither of the two is the case.  I've tried to
> * rebase jolly on top of master
> as well as
> * rebase jolly_dsp on top of jolly
>
> and both are impossible due to the series of merges and the unclear
> ancestry / relationship of the branches.  Or, just for fun, try 'git
> diff origin/jolly..origin/jolly_dsp.  It shows you anything else but
> what one would expect
>
> Andreas: Please take some time to clean up the mess.  Your 'jolly'
> branch should contain a series of clean per-feature commit's on top of
> current master, and 'jolly_dsp' should be a set of few patches on top of
> 'jolly'.
>
> This way there is always a clean queue of changesets that Ivan can merge
> (or cherry-pick).  I can understand that if I was in Ivan's place, I
> would not really know where to even start merging some of those
> contributions.
>
> Thanks for everyone's attention.  Please take some time to get this
> resolved.  Let me know if you have some questions.  There are plenty of
> people with lots of git experience around (Holger, Pablo, myself) who
> can help if something is unclear.
>
> 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)
>
>


-- 
Regards,
Ivan Kluchnikov.
http://fairwaves.ru
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20121126/22ff9123/attachment.htm>

From alexander.chemeris at gmail.com  Mon Nov 26 14:22:57 2012
From: alexander.chemeris at gmail.com (Alexander Chemeris)
Date: Mon, 26 Nov 2012 18:22:57 +0400
Subject: lack of progress in PCU patch merging / git (ab)use
In-Reply-To: <CA+QHiD8w96iwu8LvhhsguugEVUoSM7a29+_CSr8vRXN8cfwwqg@mail.gmail.com>
References: <20121124215519.GA21201@prithivi.gnumonks.org>
	<CA+QHiD8w96iwu8LvhhsguugEVUoSM7a29+_CSr8vRXN8cfwwqg@mail.gmail.com>
Message-ID: <CABmJbFWs=Wtu5U00nd+PUSri-A7TUEK+F67KeDZSa9YvwQo=7g@mail.gmail.com>

Hi all,


From laforge at gnumonks.org  Mon Nov 26 15:23:03 2012
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 26 Nov 2012 16:23:03 +0100
Subject: lack of progress in PCU patch merging / git (ab)use
In-Reply-To: <CABmJbFWs=Wtu5U00nd+PUSri-A7TUEK+F67KeDZSa9YvwQo=7g@mail.gmail.com>
References: <20121124215519.GA21201@prithivi.gnumonks.org>
	<CA+QHiD8w96iwu8LvhhsguugEVUoSM7a29+_CSr8vRXN8cfwwqg@mail.gmail.com>
	<CABmJbFWs=Wtu5U00nd+PUSri-A7TUEK+F67KeDZSa9YvwQo=7g@mail.gmail.com>
Message-ID: <20121126152303.GN27743@prithivi.gnumonks.org>

Hi Alexander,

On Mon, Nov 26, 2012 at 06:22:57PM +0400, Alexander Chemeris wrote:

> From what I see, all (or almost all) recent commits from Andreas are
> bug fixes. Ideally I'd love to see Andreas developing them on top of
> the current 'master' 

agreed.

> and submitting them to the mailing list as soon as he push them. This
> way Ivan (and everyone else) would be able to review them and merge as
> soon as possible.

We can configure a post-commit hook to automatically send any commit (or
only commits to certain branches) to the osmo-pcu mailing list.  I
think right now they only end up at the generic osmocom.org commitlog
list, whcih probably except Holger and me nobody is really following...

> I hate the situation when fixes are stored in a private branch and are
> not merged into mainline.

agreed.

-- 
- 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 andreas at eversberg.eu  Mon Nov 26 18:09:09 2012
From: andreas at eversberg.eu (Andreas Eversberg)
Date: Mon, 26 Nov 2012 19:09:09 +0100
Subject: lack of progress in PCU patch merging / git (ab)use
In-Reply-To: <20121126152303.GN27743@prithivi.gnumonks.org>
References: <20121124215519.GA21201@prithivi.gnumonks.org>
	<CA+QHiD8w96iwu8LvhhsguugEVUoSM7a29+_CSr8vRXN8cfwwqg@mail.gmail.com>
	<CABmJbFWs=Wtu5U00nd+PUSri-A7TUEK+F67KeDZSa9YvwQo=7g@mail.gmail.com>
	<20121126152303.GN27743@prithivi.gnumonks.org>
Message-ID: <50B3B045.8020109@eversberg.eu>

hi,

because i am not a git expert, i did not start cleanup yet. i will 
hopefully talk to harald on the phone this week. he might give me some 
hints about cleaning up my two branches (jolly and jolly_pcu). as soon 
as it is done, i will inform you on this list.

regards,

andreas




From alexander.chemeris at gmail.com  Mon Nov 26 18:26:19 2012
From: alexander.chemeris at gmail.com (Alexander Chemeris)
Date: Mon, 26 Nov 2012 22:26:19 +0400
Subject: lack of progress in PCU patch merging / git (ab)use
In-Reply-To: <20121126152303.GN27743@prithivi.gnumonks.org>
References: <20121124215519.GA21201@prithivi.gnumonks.org>
	<CA+QHiD8w96iwu8LvhhsguugEVUoSM7a29+_CSr8vRXN8cfwwqg@mail.gmail.com>
	<CABmJbFWs=Wtu5U00nd+PUSri-A7TUEK+F67KeDZSa9YvwQo=7g@mail.gmail.com>
	<20121126152303.GN27743@prithivi.gnumonks.org>
Message-ID: <CABmJbFWcnN9DL48MCX1Hd2Gs2THC=6uO2fFQVT3wsOyf6yxtsQ@mail.gmail.com>

Hi Harald,

On Mon, Nov 26, 2012 at 7:23 PM, Harald Welte <laforge at gnumonks.org> wrote:
> On Mon, Nov 26, 2012 at 06:22:57PM +0400, Alexander Chemeris wrote:
>> and submitting them to the mailing list as soon as he push them. This
>> way Ivan (and everyone else) would be able to review them and merge as
>> soon as possible.
>
> We can configure a post-commit hook to automatically send any commit (or
> only commits to certain branches) to the osmo-pcu mailing list.  I
> think right now they only end up at the generic osmocom.org commitlog
> list, whcih probably except Holger and me nobody is really following...

Well, I'm also following it with filter set to "pcu". :)

I don't think it's useful to have another post-commit hook. My point
is that Andreas (and everyone else) should write to the mailing list
when they think their patches are ready, which may be well after it's
actually committed. I.e. it should be human decision when to post a
patch.

--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ??? ???????
http://fairwaves.ru