From andreas at eversberg.eu Tue Jul 3 11:38:10 2012 From: andreas at eversberg.eu (jolly) Date: Tue, 03 Jul 2012 13:38:10 +0200 Subject: TBF acknowledged mode is now working Message-ID: <4FF2D9A2.5040801@eversberg.eu> hi, finally the TBF acknowledge mode works in up- and downlink. i have tested it with attachment/detachment and routing area update. changes are commited to jolly branch. don't be shocked, but there great changes to previous gprs_rlcmac.cpp code. it is split into three sources: - gprs_rlcmac.cpp: general functions to handle TBF instances, hand-hacked codings - gprs_rlcmac_data.cpp: handling of uplink and downlink TBF - gprs_rlcmac_sched.cpp: scheduler to handle ready-to-send requests. during packet idle mode, assignment of up- or downlink TBF is performed using IMMEDIATE ASSIGMENT on AGCH. during TBF uplink, downlink assignment is performed using PACKET DOWNLINK ASSIGNMENT on PACCH. after TBF downlink, further downlink assignment is performed using PACKET DOWNLINK ASSIGNMENT. during TBF downlink, uplink assignment is performed using PACKET UPLINK assignment. this way an attachment / RA update / detach will complete while staying in packet transfer mode, so no further assignment must be done on AGCH. the acknowledged mode keeps states about transmitted and received blocks, so unreceived or unacknowledged block are retransmitted as defined in TS 04.60. downlink RLC/MAC data and control blocks are not queued, but generated at ready-to-send request from layer 1. a scheduler is used to schedule next RLC/MAC block. it uses round-robin scheduling, if more than two flows are active in one direction. in downlink direction, control blocks are prioized. in uplink direction, polling of mobile is priorized. (USF is set to apply uplink ressource to MS.) only one timeslot (first PDCH) is used to share the ressources, currently. there is a short description (tbf.txt) about states and the process of current code. in order to detect missing responses on polling MS, a gprs_rlcmac_poll_timeout() function is called. layer 1 interface must implement detection of missed polled uplink control blocks. there are two ways to perform this: - The received frame is bad (BFI). - The GSM indicates that the block should have been already received. currently pcu_l1_if.c is broken, because none of the detection above is performed. best regards, andreas From andreas at eversberg.eu Tue Jul 3 11:38:10 2012 From: andreas at eversberg.eu (jolly) Date: Tue, 03 Jul 2012 13:38:10 +0200 Subject: TBF acknowledged mode is now working Message-ID: <4FF2D9A2.5040801@eversberg.eu> hi, finally the TBF acknowledge mode works in up- and downlink. i have tested it with attachment/detachment and routing area update. changes are commited to jolly branch. don't be shocked, but there great changes to previous gprs_rlcmac.cpp code. it is split into three sources: - gprs_rlcmac.cpp: general functions to handle TBF instances, hand-hacked codings - gprs_rlcmac_data.cpp: handling of uplink and downlink TBF - gprs_rlcmac_sched.cpp: scheduler to handle ready-to-send requests. during packet idle mode, assignment of up- or downlink TBF is performed using IMMEDIATE ASSIGMENT on AGCH. during TBF uplink, downlink assignment is performed using PACKET DOWNLINK ASSIGNMENT on PACCH. after TBF downlink, further downlink assignment is performed using PACKET DOWNLINK ASSIGNMENT. during TBF downlink, uplink assignment is performed using PACKET UPLINK assignment. this way an attachment / RA update / detach will complete while staying in packet transfer mode, so no further assignment must be done on AGCH. the acknowledged mode keeps states about transmitted and received blocks, so unreceived or unacknowledged block are retransmitted as defined in TS 04.60. downlink RLC/MAC data and control blocks are not queued, but generated at ready-to-send request from layer 1. a scheduler is used to schedule next RLC/MAC block. it uses round-robin scheduling, if more than two flows are active in one direction. in downlink direction, control blocks are prioized. in uplink direction, polling of mobile is priorized. (USF is set to apply uplink ressource to MS.) only one timeslot (first PDCH) is used to share the ressources, currently. there is a short description (tbf.txt) about states and the process of current code. in order to detect missing responses on polling MS, a gprs_rlcmac_poll_timeout() function is called. layer 1 interface must implement detection of missed polled uplink control blocks. there are two ways to perform this: - The received frame is bad (BFI). - The GSM indicates that the block should have been already received. currently pcu_l1_if.c is broken, because none of the detection above is performed. best regards, andreas From andreas at eversberg.eu Tue Jul 3 18:55:50 2012 From: andreas at eversberg.eu (Andreas Eversberg) Date: Tue, 03 Jul 2012 20:55:50 +0200 Subject: bug in common/oml.c of osmo-bts? Message-ID: <4FF34036.3080406@eversberg.eu> hi laforge, just curios about two lines at oml.c: rlcc->parameter[T_DL_TBF_EXT] = *(uint16_t *)cur * 10; rlcc->parameter[T_UL_TBF_EXT] = *(uint16_t *)cur * 10; 1. isnt it * 2 instead of * 10? i just saw a comment at openbsc for 0, 250 which says: 500. 2. did you forget ntoh(*(uint16_t *)cur)? regards, andreas From andreas at eversberg.eu Tue Jul 3 18:55:50 2012 From: andreas at eversberg.eu (Andreas Eversberg) Date: Tue, 03 Jul 2012 20:55:50 +0200 Subject: bug in common/oml.c of osmo-bts? Message-ID: <4FF34036.3080406@eversberg.eu> hi laforge, just curios about two lines at oml.c: rlcc->parameter[T_DL_TBF_EXT] = *(uint16_t *)cur * 10; rlcc->parameter[T_UL_TBF_EXT] = *(uint16_t *)cur * 10; 1. isnt it * 2 instead of * 10? i just saw a comment at openbsc for 0, 250 which says: 500. 2. did you forget ntoh(*(uint16_t *)cur)? regards, andreas From Ivan.Kluchnikov at fairwaves.ru Thu Jul 5 11:56:10 2012 From: Ivan.Kluchnikov at fairwaves.ru (Ivan Kluchnikov) Date: Thu, 5 Jul 2012 15:56:10 +0400 Subject: TBF acknowledged mode is now working In-Reply-To: <4FF2D9A2.5040801@eversberg.eu> References: <4FF2D9A2.5040801@eversberg.eu> Message-ID: Hi, Andreas! I reviewed your implementation of TBF acknowledged mode and it is a great work! I modified implementation of L1 interface for OpenBTS and we have done some tests. Can you explain, what is the reason of using Time Indication message? As I understand, we use only frame number from this message and call gprs_rlcmac_poll_timeout() function. But when we receive Ready To Send message, we also receive frame number, so why we couldn't use that FN for our purpose and call gprs_rlcmac_poll_timeout() in function, which handling ReadyToSend message? I think for maintain compatibility with different BTS implementations, it is better to use only L1 primitives, which specified in 03.64 Chapter 6.5.3 and Time Indication primitive is not described there. Now I think, it makes sense to merge your branch with master, but we should coordinate this process. When it is better to merge it? Do you plan to make some more fixes, modifications and cleaning of the code at this stage? I believe, for better understanding of further development of the project we should coordinate our efforts and discuss, what should be implemented in the next steps. What plans of development do you have now? 2012/7/3 jolly > hi, > > finally the TBF acknowledge mode works in up- and downlink. i have > tested it with attachment/detachment and routing area update. changes > are commited to jolly branch. > > don't be shocked, but there great changes to previous gprs_rlcmac.cpp > code. it is split into three sources: > - gprs_rlcmac.cpp: general functions to handle TBF instances, > hand-hacked codings > - gprs_rlcmac_data.cpp: handling of uplink and downlink TBF > - gprs_rlcmac_sched.cpp: scheduler to handle ready-to-send requests. > > during packet idle mode, assignment of up- or downlink TBF is performed > using IMMEDIATE ASSIGMENT on AGCH. during TBF uplink, downlink > assignment is performed using PACKET DOWNLINK ASSIGNMENT on PACCH. after > TBF downlink, further downlink assignment is performed using PACKET > DOWNLINK ASSIGNMENT. during TBF downlink, uplink assignment is performed > using PACKET UPLINK assignment. this way an attachment / RA update / > detach will complete while staying in packet transfer mode, so no > further assignment must be done on AGCH. > > the acknowledged mode keeps states about transmitted and received > blocks, so unreceived or unacknowledged block are retransmitted as > defined in TS 04.60. downlink RLC/MAC data and control blocks are not > queued, but generated at ready-to-send request from layer 1. > > a scheduler is used to schedule next RLC/MAC block. it uses round-robin > scheduling, if more than two flows are active in one direction. in > downlink direction, control blocks are prioized. in uplink direction, > polling of mobile is priorized. (USF is set to apply uplink ressource to > MS.) only one timeslot (first PDCH) is used to share the ressources, > currently. > > there is a short description (tbf.txt) about states and the process of > current code. > > in order to detect missing responses on polling MS, a > gprs_rlcmac_poll_timeout() function is called. layer 1 interface must > implement detection of missed polled uplink control blocks. there are > two ways to perform this: > - The received frame is bad (BFI). > - The GSM indicates that the block should have been already received. > currently pcu_l1_if.c is broken, because none of the detection above is > performed. > > best regards, > > andreas > > > -- Regards, Ivan Kluchnikov. http://fairwaves.ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.chemeris at gmail.com Thu Jul 5 16:46:55 2012 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Thu, 5 Jul 2012 17:46:55 +0100 Subject: osmo-pcu.git branch jolly updated. f3d060c6310bfa979225b871ba463284d3cda887 In-Reply-To: References: Message-ID: Hi Andreas, I've looked through your commits and looks like you're doing a very quick progress. Your changes are overlapping with Ivan's work and I would recommend to merge them the master as often as possible to avoid duplicated efforts and code divergence. From this quick review I've got impression that code needs clean up before the merge, so it would be good if you share your plans on this. As a general comment, I think we could do merging of your code into master, but it would be much, much easier if you commit in smaller "atomic" chunks. E.g. these two last commits contain more changes then is written in the commit logs and in my opinion should be splitted into several independent commits. Note, that I just want to share my opinion and it's up to you and Ivan to decide how to work together efficiently. On Thu, Jul 5, 2012 at 6:42 AM, git repository hosting wrote: > This is an automated email from the git hooks/post-receive script. It was > generated because a ref change was pushed to the repository containing > the project "UNNAMED PROJECT". > > The branch, jolly has been updated > via f3d060c6310bfa979225b871ba463284d3cda887 (commit) > via 06b195e43e36c0b5100ab03e80fcc87a10db9fc5 (commit) > from e6228b34a75efcb6b0700ac29672d62539860fbf (commit) > > Those revisions listed above that are new to this repository have > not appeared on any other notification email; so we list those > revisions in full, below. > > - Log ----------------------------------------------------------------- > http://cgit.osmocom.org/cgit/osmo-pcu/commit/?id=f3d060c6310bfa979225b871ba463284d3cda887 > > commit f3d060c6310bfa979225b871ba463284d3cda887 > Author: Andreas Eversberg > Date: Thu Jul 5 07:38:49 2012 +0200 > > Fixed pseudo length of IMMEDIATE ASSIGNMENT message. > > The pseudo length may not include the rest-octets, so it stays compatible > to non-GPRS phones. > > At pcu_l1_if.c (OpenBTS) no pseudo length is given, so the frame is > only 22 bytes long. I could not test if it works. > > http://cgit.osmocom.org/cgit/osmo-pcu/commit/?id=06b195e43e36c0b5100ab03e80fcc87a10db9fc5 > > commit 06b195e43e36c0b5100ab03e80fcc87a10db9fc5 > Author: Andreas Eversberg > Date: Thu Jul 5 07:34:29 2012 +0200 > > Use cell informations received from PCU socket interface > > Cell info is received from socket interface. The given parameters are > used to replace the hardcoded values (at least for l1 socket interface). > > ----------------------------------------------------------------------- > > Summary of changes: > configure.ac | 8 ++ > src/Makefile.am | 19 ++---- > src/gprs_bssgp_pcu.cpp | 178 ++++++++++++++++++++++++++++++++++++++++++++-- > src/gprs_bssgp_pcu.h | 24 ++---- > src/gprs_debug.cpp | 2 +- > src/gprs_rlcmac.cpp | 41 ++++++----- > src/gprs_rlcmac.h | 25 ++++--- > src/gprs_rlcmac_data.cpp | 79 +++++++++++++------- > src/pcu_l1_if.cpp | 37 +++++++++- > src/pcu_main.cpp | 123 ++++++++++++++++++-------------- > src/sysmo_l1_if.cpp | 94 ++++++++++++++++++++++--- > 11 files changed, 471 insertions(+), 159 deletions(-) > > > hooks/post-receive > -- > UNNAMED PROJECT > -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From andreas at eversberg.eu Thu Jul 5 18:04:43 2012 From: andreas at eversberg.eu (Andreas Eversberg) Date: Thu, 05 Jul 2012 20:04:43 +0200 Subject: TBF acknowledged mode is now working In-Reply-To: References: <4FF2D9A2.5040801@eversberg.eu> Message-ID: <4FF5D73B.5070604@eversberg.eu> Ivan Kluchnikov wrote: > Can you explain, what is the reason of using Time Indication message? > As I understand, we use only frame number from this message and call > gprs_rlcmac_poll_timeout() function. But when we receive Ready To Send > message, we also receive frame number, so why we couldn't use that FN > for our purpose and call gprs_rlcmac_poll_timeout() in function, which > handling ReadyToSend message? hi ivan, the reason is that i need to find out when an uplink control bock is not received. this is required to handle counters on dropped frames. the problem is, that i did not yet manage to get bad frame indications. in order to have a quick workarround, i use gsm time indications. these indications are sent in advance of about 10 frames. after 20 frames i can be sure that the frame has not been received. using rts message would be possible too, but since i cannot be sure how much earlier they are sent, i cannot define how many frames i have to wait until timeout. if openbts uses an exact definition of how much earlier the rts messages are sent. if you look at gprs_rlcmac_poll_timeout(), you will see that i wait 20 frames. if rts message would be sent 52 frames in advance, then you should use wait something like 60. (add 10 to avoid jitter). > Now I think, it makes sense to merge your branch with master, but we > should coordinate this process. When it is better to merge it? Do you > plan to make some more fixes, modifications and cleaning of the code > at this stage? > I believe, for better understanding of further development of the > project we should coordinate our efforts and discuss, what should be > implemented in the next steps. What plans of development do you have now? yes, i agree that we should coordinate it. my current plans are: - cleanup of debugging levels: (LOGL_DEBUG=full processing, LOGL_INFO=just infos about complete frames, LOGL_NOTICE=abnormal timeouts, invalid data and protocol errors, LOGL_ERROR=local errors, software errors. (i have already done this, but not yet committed.) - replace hand-hacked/wireshark transcoding of control blocks by generated code from encodix. (i will to try this tomorrow.) - changing from c++ back to c. (only possible after replacing the wireshark code.) - multislot support. i also agree with alexander's comment on splitting the commits. (especially the support of cell information from socket interface.) i can do that and provide seperate patches to this list tomorrow. sometimes it is hard to implement new features without doing cleanups at the same time, since i don't know what have to be cleaned in order to make the new feature work. instead i work on the feature and clean at the same time. (like replacing all hardcoded values by the cell information from the socket interface (or maybe from config file, one day).) regards, andreas From andreas at eversberg.eu Fri Jul 6 07:53:47 2012 From: andreas at eversberg.eu (jolly) Date: Fri, 06 Jul 2012 09:53:47 +0200 Subject: TBF acknowledged mode is now working In-Reply-To: <4FF5D73B.5070604@eversberg.eu> References: <4FF2D9A2.5040801@eversberg.eu> <4FF5D73B.5070604@eversberg.eu> Message-ID: <4FF6998B.6090304@eversberg.eu> > i also agree with alexander's comment on splitting the commits. > (especially the support of cell information from socket interface.) i > can do that and provide seperate patches to this list tomorrow. > sometimes it is hard to implement new features without doing cleanups > at the same time, since i don't know what have to be cleaned in order > to make the new feature work. instead i work on the feature and clean > at the same time. (like replacing all hardcoded values by the cell > information from the socket interface (or maybe from config file, one > day).) hi, i splitted the last commit and pushed them in a new branch: jolly_new i hope it is now easier to merge. also i removed my work on using libosmogp, because it was already done by harald in the master branch. regards, andreas commit 1944bd58721920cbd6235c03ff72da1c346e5423 Author: Andreas Eversberg Date: Fri Jul 6 09:32:39 2012 +0200 Minor fix of MCC, MNC options commit 3e372d57ed36e68836b14dd96f6bda595bb6fe9e Author: Andreas Eversberg Date: Fri Jul 6 09:28:15 2012 +0200 Cleanup of BSSGP code. The hack for resetting BSSGP instance is removed and now performed whenever the NS state changes to UNBLOCKED. The BSSGP instance is now created only once, as it should be. Received STATUS messages are ignored as they should be. The creation and destruction of BSSGP/NS instances is now handled by layer 1 interface alone. commit bf5a0f6e2c9d0ae564b171b210f0f97bcbdddbf3 Author: Andreas Eversberg Date: Fri Jul 6 08:58:22 2012 +0200 Move BSSGP/NS instances creation and desctruction to gprs_bssgp_pcu.cpp commit 81e895b6193530ea4b180c2118b9f40bb33de5b7 Author: Andreas Eversberg Date: Fri Jul 6 08:24:53 2012 +0200 Adding MCC/MNC spoof options to pcu_main.cpp The option added is required to change PLMN that is announced to SGSN. This allows BTS to have a different PLMN. (Usefull for roaming in conjunction with simlock.) commit dfa563cd3bba9b6214289bc63c84b00f1f7676cd Author: Andreas Eversberg Date: Fri Jul 6 08:13:59 2012 +0200 RLC/MAC process makes use from attributes, received from PCU socket For OpenBTS interface and BSSGP, fixed values are still used. commit b3c6f6c716d4495b0f664b4d0da1a4708fb1d0f2 Author: Andreas Eversberg Date: Fri Jul 6 07:40:08 2012 +0200 Receive cell informations via PCU socket interface These informations provide RAI, timers, counters and other attributes to the BSSGP and RLC/MAC processes. The attributes are stored in gprs_rlcmac_bts global structure. From andreas at eversberg.eu Fri Jul 6 07:53:47 2012 From: andreas at eversberg.eu (jolly) Date: Fri, 06 Jul 2012 09:53:47 +0200 Subject: TBF acknowledged mode is now working In-Reply-To: <4FF5D73B.5070604@eversberg.eu> References: <4FF2D9A2.5040801@eversberg.eu> <4FF5D73B.5070604@eversberg.eu> Message-ID: <4FF6998B.6090304@eversberg.eu> > i also agree with alexander's comment on splitting the commits. > (especially the support of cell information from socket interface.) i > can do that and provide seperate patches to this list tomorrow. > sometimes it is hard to implement new features without doing cleanups > at the same time, since i don't know what have to be cleaned in order > to make the new feature work. instead i work on the feature and clean > at the same time. (like replacing all hardcoded values by the cell > information from the socket interface (or maybe from config file, one > day).) hi, i splitted the last commit and pushed them in a new branch: jolly_new i hope it is now easier to merge. also i removed my work on using libosmogp, because it was already done by harald in the master branch. regards, andreas commit 1944bd58721920cbd6235c03ff72da1c346e5423 Author: Andreas Eversberg Date: Fri Jul 6 09:32:39 2012 +0200 Minor fix of MCC, MNC options commit 3e372d57ed36e68836b14dd96f6bda595bb6fe9e Author: Andreas Eversberg Date: Fri Jul 6 09:28:15 2012 +0200 Cleanup of BSSGP code. The hack for resetting BSSGP instance is removed and now performed whenever the NS state changes to UNBLOCKED. The BSSGP instance is now created only once, as it should be. Received STATUS messages are ignored as they should be. The creation and destruction of BSSGP/NS instances is now handled by layer 1 interface alone. commit bf5a0f6e2c9d0ae564b171b210f0f97bcbdddbf3 Author: Andreas Eversberg Date: Fri Jul 6 08:58:22 2012 +0200 Move BSSGP/NS instances creation and desctruction to gprs_bssgp_pcu.cpp commit 81e895b6193530ea4b180c2118b9f40bb33de5b7 Author: Andreas Eversberg Date: Fri Jul 6 08:24:53 2012 +0200 Adding MCC/MNC spoof options to pcu_main.cpp The option added is required to change PLMN that is announced to SGSN. This allows BTS to have a different PLMN. (Usefull for roaming in conjunction with simlock.) commit dfa563cd3bba9b6214289bc63c84b00f1f7676cd Author: Andreas Eversberg Date: Fri Jul 6 08:13:59 2012 +0200 RLC/MAC process makes use from attributes, received from PCU socket For OpenBTS interface and BSSGP, fixed values are still used. commit b3c6f6c716d4495b0f664b4d0da1a4708fb1d0f2 Author: Andreas Eversberg Date: Fri Jul 6 07:40:08 2012 +0200 Receive cell informations via PCU socket interface These informations provide RAI, timers, counters and other attributes to the BSSGP and RLC/MAC processes. The attributes are stored in gprs_rlcmac_bts global structure. From Ivan.Kluchnikov at fairwaves.ru Fri Jul 6 10:49:12 2012 From: Ivan.Kluchnikov at fairwaves.ru (Ivan Kluchnikov) Date: Fri, 6 Jul 2012 14:49:12 +0400 Subject: TBF acknowledged mode is now working In-Reply-To: <4FF6998B.6090304@eversberg.eu> References: <4FF2D9A2.5040801@eversberg.eu> <4FF5D73B.5070604@eversberg.eu> <4FF6998B.6090304@eversberg.eu> Message-ID: Hi, Andreas! Thank you for explanation of Time Indication and your effort in splitting commits. According to your plan, I guess it makes sense to merge in several steps: 1. After cleanup of debugging levels. At this step I plan to use your code as base, but I should add our implementation of encoding control blocks (without hand-hacked code!, but uses wireshark transcoding code). I guess that this merge will be a good point to bring to a common view master and your branch. After this merge it will be better, if you continue working on your branch from this point, in order to avoid merge problems in future. 2. After adding support of encodix and changing to c. 3. After adding multislot support. So our current plans are: - spend time for developing OpenBTS side; - try to make some refactoring of the code for improvement of internal logic, after adding support of encodix and changing to c; - to make more test before adding multislot support. 2012/7/6 jolly > > > i also agree with alexander's comment on splitting the commits. > > (especially the support of cell information from socket interface.) i > > can do that and provide seperate patches to this list tomorrow. > > sometimes it is hard to implement new features without doing cleanups > > at the same time, since i don't know what have to be cleaned in order > > to make the new feature work. instead i work on the feature and clean > > at the same time. (like replacing all hardcoded values by the cell > > information from the socket interface (or maybe from config file, one > > day).) > hi, > > i splitted the last commit and pushed them in a new branch: jolly_new > i hope it is now easier to merge. also i removed my work on using > libosmogp, because it was already done by harald in the master branch. > > regards, > > andreas > > commit 1944bd58721920cbd6235c03ff72da1c346e5423 > Author: Andreas Eversberg > Date: Fri Jul 6 09:32:39 2012 +0200 > > Minor fix of MCC, MNC options > > commit 3e372d57ed36e68836b14dd96f6bda595bb6fe9e > Author: Andreas Eversberg > Date: Fri Jul 6 09:28:15 2012 +0200 > > Cleanup of BSSGP code. > > The hack for resetting BSSGP instance is removed and now performed > whenever the NS state changes to UNBLOCKED. > > The BSSGP instance is now created only once, as it should be. > > Received STATUS messages are ignored as they should be. > > The creation and destruction of BSSGP/NS instances is now handled by > layer 1 interface alone. > > commit bf5a0f6e2c9d0ae564b171b210f0f97bcbdddbf3 > Author: Andreas Eversberg > Date: Fri Jul 6 08:58:22 2012 +0200 > > Move BSSGP/NS instances creation and desctruction to gprs_bssgp_pcu.cpp > > commit 81e895b6193530ea4b180c2118b9f40bb33de5b7 > Author: Andreas Eversberg > Date: Fri Jul 6 08:24:53 2012 +0200 > > Adding MCC/MNC spoof options to pcu_main.cpp > > The option added is required to change PLMN that is announced to SGSN. > This allows BTS to have a different PLMN. > > (Usefull for roaming in conjunction with simlock.) > > commit dfa563cd3bba9b6214289bc63c84b00f1f7676cd > Author: Andreas Eversberg > Date: Fri Jul 6 08:13:59 2012 +0200 > > RLC/MAC process makes use from attributes, received from PCU socket > > For OpenBTS interface and BSSGP, fixed values are still used. > > commit b3c6f6c716d4495b0f664b4d0da1a4708fb1d0f2 > Author: Andreas Eversberg > Date: Fri Jul 6 07:40:08 2012 +0200 > > Receive cell informations via PCU socket interface > > These informations provide RAI, timers, counters and other attributes > to > the BSSGP and RLC/MAC processes. > > The attributes are stored in gprs_rlcmac_bts global structure. > > > > -- Regards, Ivan Kluchnikov. http://fairwaves.ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Tue Jul 10 23:23:29 2012 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 11 Jul 2012 01:23:29 +0200 Subject: git tree / branches / ancestor? Message-ID: <20120710232329.GB2490@prithivi.gnumonks.org> Hi all! while reviewing the current PCU code in the git repository, it occurred to me that somehow the jolly_new branch doesn't seem to be based on master, and the only common ancestor is 9b06ff0c4c49f1927b9029d38e16670a7b7301fb from June 15. In fact, Ivan seems to have made a number of changes concurrently with Andreas, but not basing on each other's code. It's really a big mess, from what I can tell. I'm referring to the followign commit's by Ivan: a9e6dc5084627e7c279ba08de7a7809e97ebc539 d78ee736239414021fde8010179f42b86464a238 Which are completely unrelated to the work that Andreas has been doing at the same time (all his commit's from 2012-06-27 on, i.e. 39621c41f303e24b7324dc4c91447a449d2a654b and later. I strongly recomend that you coordinate more and re-view each others' code better. And regarding the messy situatin with master vs. jolly_new: I think the only practical solution is to drop one of the two parallel and incompatible changes regarding the RLC/MAC and TBF establishment changes. Do you have any input on how to resolve this specific issue? I think none of us can afford to waste resources on duplication of work and creating virtually un-mergeable branches :/ Regards, Harald -- - Harald Welte 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 Tue Jul 10 23:28:02 2012 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 11 Jul 2012 01:28:02 +0200 Subject: bug in common/oml.c of osmo-bts? In-Reply-To: <4FF34036.3080406@eversberg.eu> References: <4FF34036.3080406@eversberg.eu> Message-ID: <20120710232802.GC2490@prithivi.gnumonks.org> Hi Andreas, sorry for the delayed response. That mail got somehow missed... On Tue, Jul 03, 2012 at 08:55:50PM +0200, Andreas Eversberg wrote: > rlcc->parameter[T_DL_TBF_EXT] = *(uint16_t *)cur * 10; > rlcc->parameter[T_UL_TBF_EXT] = *(uint16_t *)cur * 10; > > 1. isnt it * 2 instead of * 10? the parameter is coded in units of 10ms. So in order to get from the wire encoding to milliseconds, we need to multiply by 10. > 2. did you forget ntoh(*(uint16_t *)cur)? yes, it seems. I've committed a fix now. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From alexander.chemeris at gmail.com Wed Jul 11 06:27:55 2012 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Wed, 11 Jul 2012 10:27:55 +0400 Subject: git tree / branches / ancestor? In-Reply-To: <20120710232329.GB2490@prithivi.gnumonks.org> References: <20120710232329.GB2490@prithivi.gnumonks.org> Message-ID: I completely agree. That was the reason I proposed Ivan and Andreas agree on a path to merge existing work and coordinate better in future. I think that current code is not _that_ hard to merge, but it can't continue like this for a long time. On Wed, Jul 11, 2012 at 3:23 AM, Harald Welte wrote: > Hi all! > > while reviewing the current PCU code in the git repository, it occurred > to me that somehow the jolly_new branch doesn't seem to be based on > master, and the only common ancestor is > 9b06ff0c4c49f1927b9029d38e16670a7b7301fb from June 15. > > In fact, Ivan seems to have made a number of changes concurrently with > Andreas, but not basing on each other's code. It's really a big mess, > from what I can tell. > > I'm referring to the followign commit's by Ivan: > a9e6dc5084627e7c279ba08de7a7809e97ebc539 > d78ee736239414021fde8010179f42b86464a238 > > Which are completely unrelated to the work that Andreas has been doing > at the same time (all his commit's from 2012-06-27 on, i.e. > 39621c41f303e24b7324dc4c91447a449d2a654b and later. > > I strongly recomend that you coordinate more and re-view each others' > code better. > > And regarding the messy situatin with master vs. jolly_new: I think the > only practical solution is to drop one of the two parallel and > incompatible changes regarding the RLC/MAC and TBF establishment > changes. > > Do you have any input on how to resolve this specific issue? I think > none of us can afford to waste resources on duplication of work and > creating virtually un-mergeable branches :/ > > Regards, > Harald > -- > - Harald Welte http://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) > -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From Ivan.Kluchnikov at fairwaves.ru Wed Jul 11 06:41:46 2012 From: Ivan.Kluchnikov at fairwaves.ru (Ivan Kluchnikov) Date: Wed, 11 Jul 2012 10:41:46 +0400 Subject: git tree / branches / ancestor? In-Reply-To: <20120710232329.GB2490@prithivi.gnumonks.org> References: <20120710232329.GB2490@prithivi.gnumonks.org> Message-ID: Hi, Harald! As we previously discussed with Andreas, today I plan to merge jolly_new branch with master and use Andreas's code as base. After this merge, it makes sense, if we all continue working from this point, in order to avoid merge problems in future. Actually, we have already briefly discussed and coordinated our plans with Andreas in mailing list thread "TBF acknowledged mode is now working". 2012/7/11 Harald Welte > Hi all! > > while reviewing the current PCU code in the git repository, it occurred > to me that somehow the jolly_new branch doesn't seem to be based on > master, and the only common ancestor is > 9b06ff0c4c49f1927b9029d38e16670a7b7301fb from June 15. > > In fact, Ivan seems to have made a number of changes concurrently with > Andreas, but not basing on each other's code. It's really a big mess, > from what I can tell. > > I'm referring to the followign commit's by Ivan: > a9e6dc5084627e7c279ba08de7a7809e97ebc539 > d78ee736239414021fde8010179f42b86464a238 > > Which are completely unrelated to the work that Andreas has been doing > at the same time (all his commit's from 2012-06-27 on, i.e. > 39621c41f303e24b7324dc4c91447a449d2a654b and later. > > I strongly recomend that you coordinate more and re-view each others' > code better. > > And regarding the messy situatin with master vs. jolly_new: I think the > only practical solution is to drop one of the two parallel and > incompatible changes regarding the RLC/MAC and TBF establishment > changes. > > Do you have any input on how to resolve this specific issue? I think > none of us can afford to waste resources on duplication of work and > creating virtually un-mergeable branches :/ > > Regards, > Harald > -- > - Harald Welte > 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: From andreas at eversberg.eu Sun Jul 22 06:32:08 2012 From: andreas at eversberg.eu (jolly) Date: Sun, 22 Jul 2012 08:32:08 +0200 Subject: Multislot finished and well tested Message-ID: <500B9E68.7000909@eversberg.eu> hi, i like to announce that multislot supports has been finished and is working well. it supports all classes, but i could not test other classes than semi-duplex class 12. the algorithm allocates as many downlink slots as allowed by class and as avaiable. it will only allocate a single uplink slot. there is no dynamic dl/up allocation depending on traffic. the code is located at osmo-pcu: jolly branch: git log 4b470ffe regards, andreas From alexander.chemeris at gmail.com Sun Jul 22 06:42:43 2012 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Sun, 22 Jul 2012 10:42:43 +0400 Subject: Multislot finished and well tested In-Reply-To: <500B9E68.7000909@eversberg.eu> References: <500B9E68.7000909@eversberg.eu> Message-ID: Hi Andreas, On Sun, Jul 22, 2012 at 10:32 AM, jolly wrote: > i like to announce that multislot supports has been finished and is > working well. Thank you for your effort! We'll be testing this with OpenBTS soon. What is your next target? -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From laforge at gnumonks.org Sun Jul 22 07:29:48 2012 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 22 Jul 2012 09:29:48 +0200 Subject: Multislot finished and well tested In-Reply-To: References: <500B9E68.7000909@eversberg.eu> Message-ID: <20120722072948.GK7693@prithivi.gnumonks.org> Hi Alexander, On Sun, Jul 22, 2012 at 10:42:43AM +0400, Alexander Chemeris wrote: > What is your next target? Our initial funding for the PCU basically stops at this featureset. So if there are bugs, the bugs will still have to be fixed, but in terms of features, this is it for now. We've reached a point where we can demonstrate GPRS capability with a small number of phones to customers. Once we get customer buy-in, we will continue in terms of features, like: * TA loop * EGPRS support * Hand-over * dynamic timeslot allocation (i.e. use timeslots as PDCH until we need more TCH/H due to call load Andreas: It would be great if you could take some time to create a document in the osmo-pcu.git repository that describes the current limitations of the implementation, similar to the README I've put in the osmo-bts.git repository. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From alexander.chemeris at gmail.com Sun Jul 22 09:10:01 2012 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Sun, 22 Jul 2012 13:10:01 +0400 Subject: Multislot finished and well tested In-Reply-To: <20120722072948.GK7693@prithivi.gnumonks.org> References: <500B9E68.7000909@eversberg.eu> <20120722072948.GK7693@prithivi.gnumonks.org> Message-ID: Hi Harald, 22.07.2012 11:30 ???????????? "Harald Welte" ???????: > > Hi Alexander, > > On Sun, Jul 22, 2012 at 10:42:43AM +0400, Alexander Chemeris wrote: > > What is your next target? > > Our initial funding for the PCU basically stops at this featureset. So > if there are bugs, the bugs will still have to be fixed, but in terms of > features, this is it for now. We've reached a point where we can > demonstrate GPRS capability with a small number of phones to customers. > > Once we get customer buy-in, we will continue in terms of features, > like: > * TA loop > * EGPRS support > * Hand-over > * dynamic timeslot allocation (i.e. use timeslots as PDCH until we need > more TCH/H due to call load > > Andreas: It would be great if you could take some time to create a > document in the osmo-pcu.git repository that describes the current > limitations of the implementation, similar to the README I've put in the > osmo-bts.git repository. Thanks for the update! I hope you'll be able to sell this to customers. ;) We're also working on getting more funding to improve PCU/SGSN/GGSN. It seems SGSN needs some work to be really useful in deployments. Sent from my Android device. -- Regards, Alexander Chemeris CEO, Fairwaves LLC http://fairwaves.ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Sun Jul 22 09:31:23 2012 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 22 Jul 2012 11:31:23 +0200 Subject: Multislot finished and well tested In-Reply-To: References: <500B9E68.7000909@eversberg.eu> <20120722072948.GK7693@prithivi.gnumonks.org> Message-ID: <20120722093123.GO7693@prithivi.gnumonks.org> Hi Alexander. On Sun, Jul 22, 2012 at 01:10:01PM +0400, Alexander Chemeris wrote: > It seems SGSN needs some work to be really useful in deployments. yes, that's also on my agenda. In the short term, at least some of the knownbug fixing, such as * foreign/local TLLI probelms on routing area update * msgb ownership/free issues * merging + testing of flow control * testing of encryption The HLR-access from the SGSN will likely delayed until we have ripped out the HLR/DB from OpenBSC. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From hfreyther at sysmocom.de Sun Jul 22 13:29:38 2012 From: hfreyther at sysmocom.de (Holger Hans Peter Freyther) Date: Sun, 22 Jul 2012 15:29:38 +0200 Subject: Multislot finished and well tested In-Reply-To: <500B9E68.7000909@eversberg.eu> References: <500B9E68.7000909@eversberg.eu> Message-ID: <20120722132938.GD1552@sangmingze.sysmocom.de> On Sun, Jul 22, 2012 at 08:32:08AM +0200, jolly wrote: > hi, > > i like to announce that multislot supports has been finished and is > working well. great! Do you have any unit tests for the scheduler? I think it is essential to have unit tests for the scheduling, e.g. specially as someone making a modification might not have devices with all the classes. I can help you to setup the autotest setup we are using in the other modules. > > it supports all classes, but i could not test other classes than > semi-duplex class 12. the algorithm allocates as many downlink slots as > allowed by class and as avaiable. it will only allocate a single uplink > slot. there is no dynamic dl/up allocation depending on traffic. -- - Holger Freyther http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Schivelbeiner Str. 5 * 10439 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte From alexander.chemeris at gmail.com Sun Jul 22 14:14:55 2012 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Sun, 22 Jul 2012 18:14:55 +0400 Subject: Multislot finished and well tested In-Reply-To: <20120722132938.GD1552@sangmingze.sysmocom.de> References: <500B9E68.7000909@eversberg.eu> <20120722132938.GD1552@sangmingze.sysmocom.de> Message-ID: On Sun, Jul 22, 2012 at 5:29 PM, Holger Hans Peter Freyther wrote: > On Sun, Jul 22, 2012 at 08:32:08AM +0200, jolly wrote: >> hi, >> >> i like to announce that multislot supports has been finished and is >> working well. > > great! Do you have any unit tests for the scheduler? I think it is > essential to have unit tests for the scheduling, e.g. specially as > someone making a modification might not have devices with all the > classes. I can help you to setup the autotest setup we are using in > the other modules. I second that - scheduling is a peculiar part and it's important to have tests for it. Though I would say it should be more of a manual testing to characterize performance and check for corner cases rather then autotests. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From hfreyther at sysmocom.de Mon Jul 23 07:12:12 2012 From: hfreyther at sysmocom.de (Holger Hans Peter Freyther) Date: Mon, 23 Jul 2012 09:12:12 +0200 Subject: Multislot finished and well tested In-Reply-To: References: <500B9E68.7000909@eversberg.eu> <20120722132938.GD1552@sangmingze.sysmocom.de> Message-ID: <20120723071212.GA14541@sangmingze.sysmocom.de> On Sun, Jul 22, 2012 at 06:14:55PM +0400, Alexander Chemeris wrote: > > I second that - scheduling is a peculiar part and it's important to > have tests for it. Though I would say it should be more of a manual > testing to characterize performance and check for corner cases rather > then autotests. well, the problem with manual tests was already described in Andreas's email. In general one will not have devices of all classes and with manual tests it is easy to skip a step or not being able to reproduce a specific failure. On the other hand I believe that scheduling can be fully tested using autotests at first it will help to move the "scheduling" out of the gprs_rlcmac_rcv_rts_block function into a dedicated allocation function and the same applies to the deallocation routines that are inside the gprs_rlcmac_rcv_data_block_acknowledged. Right now TBF allocation/deallocation is nested and spread across functions, writing tests requires one to move them to new dedicated functions. Once the code became testable the easiest test would be to allocate TBFs by hand, then call a function and observe how the state changes. The next step would be to read commands from a text file that describe what is allocated, timedout, acked. The last part is optional but the previous parts are absolutely necessary. This PCU needs to work with thousands of subscribers, handle overload and failures. There are not too many places with thousands of test users and I really don't want to debug this PCU on a live system. So please make the code testable and write tests. Again I am happy to help you in setting up the framework and give advice on writing tests. holger PS: NOOB question, what is the meaning of USF==0x7? -- - Holger Freyther http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Schivelbeiner Str. 5 * 10439 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte From alexander.chemeris at gmail.com Mon Jul 23 08:15:06 2012 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Mon, 23 Jul 2012 10:15:06 +0200 Subject: Multislot finished and well tested In-Reply-To: <20120723071212.GA14541@sangmingze.sysmocom.de> References: <500B9E68.7000909@eversberg.eu> <20120722132938.GD1552@sangmingze.sysmocom.de> <20120723071212.GA14541@sangmingze.sysmocom.de> Message-ID: Hi Holger, On Mon, Jul 23, 2012 at 9:12 AM, Holger Hans Peter Freyther wrote: > On Sun, Jul 22, 2012 at 06:14:55PM +0400, Alexander Chemeris wrote: >> >> I second that - scheduling is a peculiar part and it's important to >> have tests for it. Though I would say it should be more of a manual >> testing to characterize performance and check for corner cases rather >> then autotests. > > well, > > the problem with manual tests was already described in Andreas's email. > In general one will not have devices of all classes and with manual > tests it is easy to skip a step or not being able to reproduce a > specific failure. > > On the other hand I believe that scheduling can be fully tested > using autotests at first it will help to move the "scheduling" out of > the gprs_rlcmac_rcv_rts_block function into a dedicated allocation > function and the same applies to the deallocation routines that are > inside the gprs_rlcmac_rcv_data_block_acknowledged. Right now TBF > allocation/deallocation is nested and spread across functions, > writing tests requires one to move them to new dedicated functions. > > Once the code became testable the easiest test would be to allocate > TBFs by hand, then call a function and observe how the state changes. > The next step would be to read commands from a text file that describe > what is allocated, timedout, acked. The last part is optional but the > previous parts are absolutely necessary. > > This PCU needs to work with thousands of subscribers, handle overload > and failures. There are not too many places with thousands of test users > and I really don't want to debug this PCU on a live system. So please > make the code testable and write tests. Again I am happy to help you > in setting up the framework and give advice on writing tests. This system is exactly what I meant. What I'm saying is that (1) those test doesn't always have OK/FAIL result, they may rather have numeric performance results, and (2) this framework is useful not only for regression testing, but for the allocation algorithm hacking/tuning. > PS: NOOB question, what is the meaning of USF==0x7? This is a special value which in means "free", i.e. it's not allocated to any mobile if we use dynamic allocation (IIRC). And if we use PRACH channel instead of RACH, then USF 7 is used to mark places for Access Bursts. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From hfreyther at sysmocom.de Mon Jul 23 08:30:01 2012 From: hfreyther at sysmocom.de (Holger Hans Peter Freyther) Date: Mon, 23 Jul 2012 10:30:01 +0200 Subject: [PATCH] misc: Fix typos in the comments Message-ID: <1343032201-18583-1-git-send-email-hfreyther@sysmocom.de> From: Holger Hans Peter Freyther ressource -> resorce shure -> sure --- src/gprs_bssgp_pcu.cpp | 4 ++-- src/gprs_rlcmac.cpp | 14 +++++++------- src/gprs_rlcmac.h | 2 +- src/gprs_rlcmac_data.cpp | 10 +++++----- src/gprs_rlcmac_sched.cpp | 20 ++++++++++---------- src/tbf.txt | 2 +- 6 files changed, 26 insertions(+), 26 deletions(-) diff --git a/src/gprs_bssgp_pcu.cpp b/src/gprs_bssgp_pcu.cpp index 217acdb..dc8e454 100644 --- a/src/gprs_bssgp_pcu.cpp +++ b/src/gprs_bssgp_pcu.cpp @@ -190,7 +190,7 @@ int gprs_bssgp_pcu_rx_dl_ud(struct msgb *msg, struct tlv_parsed *tp) // Create new TBF (any TRX) tfi = tfi_alloc(GPRS_RLCMAC_DL_TBF, &trx, &ts, use_trx, first_ts); if (tfi < 0) { - LOGP(DRLCMAC, LOGL_NOTICE, "No PDCH ressource\n"); + LOGP(DRLCMAC, LOGL_NOTICE, "No PDCH resource\n"); /* FIXME: send reject */ return -EBUSY; } @@ -198,7 +198,7 @@ int gprs_bssgp_pcu_rx_dl_ud(struct msgb *msg, struct tlv_parsed *tp) tbf = tbf_alloc(tbf, GPRS_RLCMAC_DL_TBF, tfi, trx, ts, ms_class, ss); if (!tbf) { - LOGP(DRLCMAC, LOGL_NOTICE, "No PDCH ressource\n"); + LOGP(DRLCMAC, LOGL_NOTICE, "No PDCH resource\n"); /* FIXME: send reject */ return -EBUSY; } diff --git a/src/gprs_rlcmac.cpp b/src/gprs_rlcmac.cpp index d1f0b54..5284260 100644 --- a/src/gprs_rlcmac.cpp +++ b/src/gprs_rlcmac.cpp @@ -80,7 +80,7 @@ llist_head *gprs_rlcmac_tbfs_lists[] = { }; void *rlcmac_tall_ctx; -/* FIXME: spread ressources over multiple TRX. Also add option to use same +/* FIXME: spread resources over multiple TRX. Also add option to use same * TRX in case of existing TBF for TLLI in the other direction. */ /* search for free TFI and return TFI, TRX and first TS */ int tfi_alloc(enum gprs_rlcmac_tbf_direction dir, uint8_t *_trx, uint8_t *_ts, @@ -264,7 +264,7 @@ struct gprs_rlcmac_tbf *tbf_alloc(struct gprs_rlcmac_tbf *old_tbf, else rc = bts->alloc_algorithm(old_tbf, tbf, bts->alloc_algorithm_curst); - /* if no ressource */ + /* if no resource */ if (rc < 0) { talloc_free(tbf); return NULL; @@ -272,7 +272,7 @@ struct gprs_rlcmac_tbf *tbf_alloc(struct gprs_rlcmac_tbf *old_tbf, /* assign control ts */ tbf->control_ts = 0xff; rc = tbf_assign_control_ts(tbf); - /* if no ressource */ + /* if no resource */ if (rc < 0) { talloc_free(tbf); return NULL; @@ -767,12 +767,12 @@ void tbf_free(struct gprs_rlcmac_tbf *tbf) LOGP(DRLCMAC, LOGL_ERROR, "Software error: Pending uplink " "assignment. This may not happen, because the " "assignment message never gets transmitted. Please " - "be shure not to free in this state. PLEASE FIX!\n"); + "be sure not to free in this state. PLEASE FIX!\n"); if (tbf->dl_ass_state != GPRS_RLCMAC_DL_ASS_NONE) LOGP(DRLCMAC, LOGL_ERROR, "Software error: Pending downlink " "assignment. This may not happen, because the " "assignment message never gets transmitted. Please " - "be shure not to free in this state. PLEASE FIX!\n"); + "be sure not to free in this state. PLEASE FIX!\n"); tbf_timer_stop(tbf); while ((msg = msgb_dequeue(&tbf->llc_queue))) msgb_free(msg); @@ -802,9 +802,9 @@ int tbf_update(struct gprs_rlcmac_tbf *tbf) tbf_unlink_pdch(tbf); rc = bts->alloc_algorithm(ul_tbf, tbf, bts->alloc_algorithm_curst); - /* if no ressource */ + /* if no resource */ if (rc < 0) { - LOGP(DRLCMAC, LOGL_ERROR, "No ressource after update???\n"); + LOGP(DRLCMAC, LOGL_ERROR, "No resource after update???\n"); return -rc; } diff --git a/src/gprs_rlcmac.h b/src/gprs_rlcmac.h index 71ff608..fbae677 100644 --- a/src/gprs_rlcmac.h +++ b/src/gprs_rlcmac.h @@ -99,7 +99,7 @@ extern struct gprs_rlcmac_bts *gprs_rlcmac_bts; enum gprs_rlcmac_tbf_state { GPRS_RLCMAC_NULL = 0, /* new created TBF */ GPRS_RLCMAC_ASSIGN, /* wait for downlink assignment */ - GPRS_RLCMAC_FLOW, /* RLC/MAC flow, ressource needed */ + GPRS_RLCMAC_FLOW, /* RLC/MAC flow, resource needed */ GPRS_RLCMAC_FINISHED, /* flow finished, wait for release */ GPRS_RLCMAC_WAIT_RELEASE,/* wait for release or restart of DL TBF */ GPRS_RLCMAC_RELEASING, /* releasing, wait to free TBI/USF */ diff --git a/src/gprs_rlcmac_data.cpp b/src/gprs_rlcmac_data.cpp index 2f67bd0..b56d63d 100644 --- a/src/gprs_rlcmac_data.cpp +++ b/src/gprs_rlcmac_data.cpp @@ -220,7 +220,7 @@ uplink_request: /* create new TBF, use sme TRX as DL TBF */ tfi = tfi_alloc(GPRS_RLCMAC_UL_TBF, &trx, &ts, tbf->trx, tbf->first_ts); if (tfi < 0) { - LOGP(DRLCMAC, LOGL_NOTICE, "No PDCH ressource\n"); + LOGP(DRLCMAC, LOGL_NOTICE, "No PDCH resource\n"); /* FIXME: send reject */ break; } @@ -228,7 +228,7 @@ uplink_request: ul_tbf = tbf_alloc(tbf, GPRS_RLCMAC_UL_TBF, tfi, trx, ts, tbf->ms_class, 0); if (!ul_tbf) { - LOGP(DRLCMAC, LOGL_NOTICE, "No PDCH ressource\n"); + LOGP(DRLCMAC, LOGL_NOTICE, "No PDCH resource\n"); /* FIXME: send reject */ break; } @@ -269,7 +269,7 @@ uplink_request: } tlli = tbf->tlli; } - LOGP(DRLCMAC, LOGL_ERROR, "RX: [PCU <- BTS] %s TFI: %u TLLI: 0x%08x FIXME: Packet ressource request\n", (tbf->direction == GPRS_RLCMAC_UL_TBF) ? "UL" : "DL", tbf->tfi, tbf->tlli); + LOGP(DRLCMAC, LOGL_ERROR, "RX: [PCU <- BTS] %s TFI: %u TLLI: 0x%08x FIXME: Packet resource request\n", (tbf->direction == GPRS_RLCMAC_UL_TBF) ? "UL" : "DL", tbf->tfi, tbf->tlli); break; default: LOGP(DRLCMAC, LOGL_NOTICE, "RX: [PCU <- BTS] unknown control block received\n"); @@ -838,14 +838,14 @@ int gprs_rlcmac_rcv_rach(uint8_t ra, uint32_t Fn, int16_t qta) // Create new TBF tfi = tfi_alloc(GPRS_RLCMAC_UL_TBF, &trx, &ts, -1, -1); if (tfi < 0) { - LOGP(DRLCMAC, LOGL_NOTICE, "No PDCH ressource\n"); + LOGP(DRLCMAC, LOGL_NOTICE, "No PDCH resource\n"); /* FIXME: send reject */ return -EBUSY; } /* set class to 0, since we don't know the multislot class yet */ tbf = tbf_alloc(NULL, GPRS_RLCMAC_UL_TBF, tfi, trx, ts, 0, 1); if (!tbf) { - LOGP(DRLCMAC, LOGL_NOTICE, "No PDCH ressource\n"); + LOGP(DRLCMAC, LOGL_NOTICE, "No PDCH resource\n"); /* FIXME: send reject */ return -EBUSY; } diff --git a/src/gprs_rlcmac_sched.cpp b/src/gprs_rlcmac_sched.cpp index f6af9b7..83a89ac 100644 --- a/src/gprs_rlcmac_sched.cpp +++ b/src/gprs_rlcmac_sched.cpp @@ -90,7 +90,7 @@ int gprs_rlcmac_rcv_rts_block(uint8_t trx, uint8_t ts, uint16_t arfcn, ul_ass_tbf = tbf; } - /* check uplink ressource for polling */ + /* check uplink resource for polling */ if (poll_tbf) { LOGP(DRLCMACSCHED, LOGL_DEBUG, "Received RTS for PDCH: TRX=%d " "TS=%d FN=%d block_nr=%d scheduling free USF for " @@ -99,17 +99,17 @@ int gprs_rlcmac_rcv_rts_block(uint8_t trx, uint8_t ts, uint16_t arfcn, (tbf->direction == GPRS_RLCMAC_UL_TBF) ? "UL" : "DL", poll_tbf->tfi); /* use free USF */ - /* else, we search for uplink ressource */ + /* else, we search for uplink resource */ } else { - /* select uplink ressource */ + /* select uplink resource */ for (i = 0, tfi = pdch->next_ul_tfi; i < 32; i++, tfi = (tfi + 1) & 31) { tbf = pdch->ul_tbf[tfi]; /* no TBF for this tfi, go next */ if (!tbf) continue; - /* no UL ressources needed, go next */ - /* we don't need to give ressources in FINISHED state, + /* no UL resources needed, go next */ + /* we don't need to give resources in FINISHED state, * because we have received all blocks and only poll * for packet control ack. */ if (tbf->state != GPRS_RLCMAC_FLOW) @@ -119,9 +119,9 @@ int gprs_rlcmac_rcv_rts_block(uint8_t trx, uint8_t ts, uint16_t arfcn, usf = tbf->dir.ul.usf[ts]; LOGP(DRLCMACSCHED, LOGL_DEBUG, "Received RTS for PDCH: " "TRX=%d TS=%d FN=%d block_nr=%d scheduling " - "USF=%d for required uplink ressource of " + "USF=%d for required uplink resource of " "UL TBF=%d\n", trx, ts, fn, block_nr, usf, tfi); - /* next TBF to handle ressource is the next one */ + /* next TBF to handle resource is the next one */ pdch->next_ul_tfi = (tfi + 1) & 31; break; } @@ -160,7 +160,7 @@ int gprs_rlcmac_rcv_rts_block(uint8_t trx, uint8_t ts, uint16_t arfcn, /* Prio 2: select data message for downlink */ if (!msg) { - /* select downlink ressource */ + /* select downlink resource */ for (i = 0, tfi = pdch->next_dl_tfi; i < 32; i++, tfi = (tfi + 1) & 31) { tbf = pdch->dl_tbf[tfi]; @@ -170,7 +170,7 @@ int gprs_rlcmac_rcv_rts_block(uint8_t trx, uint8_t ts, uint16_t arfcn, /* no DL TBF, go next */ if (tbf->direction != GPRS_RLCMAC_DL_TBF) continue; - /* no DL ressources needed, go next */ + /* no DL resources needed, go next */ if (tbf->state != GPRS_RLCMAC_FLOW && tbf->state != GPRS_RLCMAC_FINISHED) continue; @@ -178,7 +178,7 @@ int gprs_rlcmac_rcv_rts_block(uint8_t trx, uint8_t ts, uint16_t arfcn, LOGP(DRLCMACSCHED, LOGL_DEBUG, "Scheduling data " "message at RTS for DL TBF=%d (TRX=%d, " "TS=%d)\n", tfi, trx, ts); - /* next TBF to handle ressource is the next one */ + /* next TBF to handle resource is the next one */ pdch->next_dl_tfi = (tfi + 1) & 31; /* generate DL data block */ msg = gprs_rlcmac_send_data_block_acknowledged(tbf, fn, diff --git a/src/tbf.txt b/src/tbf.txt index eab58ba..025e56c 100644 --- a/src/tbf.txt +++ b/src/tbf.txt @@ -118,7 +118,7 @@ Control TS: Polling: In order to poll uplink control block from MS, a special poll state and frame number is stored at TBF. The scheduler reads that value and will not - assign uplink ressource for other TBFs at that frame number. + assign uplink resource for other TBFs at that frame number. When there is no uplink transmission received on the block, a timeout is indicated by layer 1 interface. There are two ways of checking timeout: -- 1.7.10.4 From hfreyther at sysmocom.de Mon Jul 23 08:50:18 2012 From: hfreyther at sysmocom.de (Holger Hans Peter Freyther) Date: Mon, 23 Jul 2012 10:50:18 +0200 Subject: [PATCH] misc: Add the libosmocore CFLAGS to the CPPFLAGS Message-ID: <1343033418-30284-1-git-send-email-hfreyther@sysmocom.de> From: Holger Hans Peter Freyther libosmocore might not be in the standard include path, add the CFLAGS to the preprocessor flags. This is fixing the build on the Osmocom Jenkins. --- src/Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/Makefile.am b/src/Makefile.am index 041831f..98574fa 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -18,7 +18,7 @@ # along with this program. If not, see . # -AM_CPPFLAGS = $(STD_DEFINES_AND_INCLUDES) +AM_CPPFLAGS = $(STD_DEFINES_AND_INCLUDES) $(LIBOSMOCORE_CFLAGS) $(LIBOSMOGB_CFLAGS) $(LIBOSMOGSM_CFLAGS) AM_CXXFLAGS = -Wall -ldl -pthread noinst_LTLIBRARIES = libgprs.la -- 1.7.10.4 From alexander.chemeris at gmail.com Mon Jul 23 20:51:14 2012 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Tue, 24 Jul 2012 00:51:14 +0400 Subject: [PATCH] misc: Fix typos in the comments In-Reply-To: <1343032201-18583-1-git-send-email-hfreyther@sysmocom.de> References: <1343032201-18583-1-git-send-email-hfreyther@sysmocom.de> Message-ID: Hi Holger. Looks good with me. Why don't you just push that? On Mon, Jul 23, 2012 at 12:30 PM, Holger Hans Peter Freyther wrote: > From: Holger Hans Peter Freyther > > ressource -> resorce > shure -> sure > --- > src/gprs_bssgp_pcu.cpp | 4 ++-- > src/gprs_rlcmac.cpp | 14 +++++++------- > src/gprs_rlcmac.h | 2 +- > src/gprs_rlcmac_data.cpp | 10 +++++----- > src/gprs_rlcmac_sched.cpp | 20 ++++++++++---------- > src/tbf.txt | 2 +- > 6 files changed, 26 insertions(+), 26 deletions(-) > > diff --git a/src/gprs_bssgp_pcu.cpp b/src/gprs_bssgp_pcu.cpp > index 217acdb..dc8e454 100644 > --- a/src/gprs_bssgp_pcu.cpp > +++ b/src/gprs_bssgp_pcu.cpp > @@ -190,7 +190,7 @@ int gprs_bssgp_pcu_rx_dl_ud(struct msgb *msg, struct tlv_parsed *tp) > // Create new TBF (any TRX) > tfi = tfi_alloc(GPRS_RLCMAC_DL_TBF, &trx, &ts, use_trx, first_ts); > if (tfi < 0) { > - LOGP(DRLCMAC, LOGL_NOTICE, "No PDCH ressource\n"); > + LOGP(DRLCMAC, LOGL_NOTICE, "No PDCH resource\n"); > /* FIXME: send reject */ > return -EBUSY; > } > @@ -198,7 +198,7 @@ int gprs_bssgp_pcu_rx_dl_ud(struct msgb *msg, struct tlv_parsed *tp) > tbf = tbf_alloc(tbf, GPRS_RLCMAC_DL_TBF, tfi, trx, ts, ms_class, > ss); > if (!tbf) { > - LOGP(DRLCMAC, LOGL_NOTICE, "No PDCH ressource\n"); > + LOGP(DRLCMAC, LOGL_NOTICE, "No PDCH resource\n"); > /* FIXME: send reject */ > return -EBUSY; > } > diff --git a/src/gprs_rlcmac.cpp b/src/gprs_rlcmac.cpp > index d1f0b54..5284260 100644 > --- a/src/gprs_rlcmac.cpp > +++ b/src/gprs_rlcmac.cpp > @@ -80,7 +80,7 @@ llist_head *gprs_rlcmac_tbfs_lists[] = { > }; > void *rlcmac_tall_ctx; > > -/* FIXME: spread ressources over multiple TRX. Also add option to use same > +/* FIXME: spread resources over multiple TRX. Also add option to use same > * TRX in case of existing TBF for TLLI in the other direction. */ > /* search for free TFI and return TFI, TRX and first TS */ > int tfi_alloc(enum gprs_rlcmac_tbf_direction dir, uint8_t *_trx, uint8_t *_ts, > @@ -264,7 +264,7 @@ struct gprs_rlcmac_tbf *tbf_alloc(struct gprs_rlcmac_tbf *old_tbf, > else > rc = bts->alloc_algorithm(old_tbf, tbf, > bts->alloc_algorithm_curst); > - /* if no ressource */ > + /* if no resource */ > if (rc < 0) { > talloc_free(tbf); > return NULL; > @@ -272,7 +272,7 @@ struct gprs_rlcmac_tbf *tbf_alloc(struct gprs_rlcmac_tbf *old_tbf, > /* assign control ts */ > tbf->control_ts = 0xff; > rc = tbf_assign_control_ts(tbf); > - /* if no ressource */ > + /* if no resource */ > if (rc < 0) { > talloc_free(tbf); > return NULL; > @@ -767,12 +767,12 @@ void tbf_free(struct gprs_rlcmac_tbf *tbf) > LOGP(DRLCMAC, LOGL_ERROR, "Software error: Pending uplink " > "assignment. This may not happen, because the " > "assignment message never gets transmitted. Please " > - "be shure not to free in this state. PLEASE FIX!\n"); > + "be sure not to free in this state. PLEASE FIX!\n"); > if (tbf->dl_ass_state != GPRS_RLCMAC_DL_ASS_NONE) > LOGP(DRLCMAC, LOGL_ERROR, "Software error: Pending downlink " > "assignment. This may not happen, because the " > "assignment message never gets transmitted. Please " > - "be shure not to free in this state. PLEASE FIX!\n"); > + "be sure not to free in this state. PLEASE FIX!\n"); > tbf_timer_stop(tbf); > while ((msg = msgb_dequeue(&tbf->llc_queue))) > msgb_free(msg); > @@ -802,9 +802,9 @@ int tbf_update(struct gprs_rlcmac_tbf *tbf) > > tbf_unlink_pdch(tbf); > rc = bts->alloc_algorithm(ul_tbf, tbf, bts->alloc_algorithm_curst); > - /* if no ressource */ > + /* if no resource */ > if (rc < 0) { > - LOGP(DRLCMAC, LOGL_ERROR, "No ressource after update???\n"); > + LOGP(DRLCMAC, LOGL_ERROR, "No resource after update???\n"); > return -rc; > } > > diff --git a/src/gprs_rlcmac.h b/src/gprs_rlcmac.h > index 71ff608..fbae677 100644 > --- a/src/gprs_rlcmac.h > +++ b/src/gprs_rlcmac.h > @@ -99,7 +99,7 @@ extern struct gprs_rlcmac_bts *gprs_rlcmac_bts; > enum gprs_rlcmac_tbf_state { > GPRS_RLCMAC_NULL = 0, /* new created TBF */ > GPRS_RLCMAC_ASSIGN, /* wait for downlink assignment */ > - GPRS_RLCMAC_FLOW, /* RLC/MAC flow, ressource needed */ > + GPRS_RLCMAC_FLOW, /* RLC/MAC flow, resource needed */ > GPRS_RLCMAC_FINISHED, /* flow finished, wait for release */ > GPRS_RLCMAC_WAIT_RELEASE,/* wait for release or restart of DL TBF */ > GPRS_RLCMAC_RELEASING, /* releasing, wait to free TBI/USF */ > diff --git a/src/gprs_rlcmac_data.cpp b/src/gprs_rlcmac_data.cpp > index 2f67bd0..b56d63d 100644 > --- a/src/gprs_rlcmac_data.cpp > +++ b/src/gprs_rlcmac_data.cpp > @@ -220,7 +220,7 @@ uplink_request: > /* create new TBF, use sme TRX as DL TBF */ > tfi = tfi_alloc(GPRS_RLCMAC_UL_TBF, &trx, &ts, tbf->trx, tbf->first_ts); > if (tfi < 0) { > - LOGP(DRLCMAC, LOGL_NOTICE, "No PDCH ressource\n"); > + LOGP(DRLCMAC, LOGL_NOTICE, "No PDCH resource\n"); > /* FIXME: send reject */ > break; > } > @@ -228,7 +228,7 @@ uplink_request: > ul_tbf = tbf_alloc(tbf, GPRS_RLCMAC_UL_TBF, tfi, trx, > ts, tbf->ms_class, 0); > if (!ul_tbf) { > - LOGP(DRLCMAC, LOGL_NOTICE, "No PDCH ressource\n"); > + LOGP(DRLCMAC, LOGL_NOTICE, "No PDCH resource\n"); > /* FIXME: send reject */ > break; > } > @@ -269,7 +269,7 @@ uplink_request: > } > tlli = tbf->tlli; > } > - LOGP(DRLCMAC, LOGL_ERROR, "RX: [PCU <- BTS] %s TFI: %u TLLI: 0x%08x FIXME: Packet ressource request\n", (tbf->direction == GPRS_RLCMAC_UL_TBF) ? "UL" : "DL", tbf->tfi, tbf->tlli); > + LOGP(DRLCMAC, LOGL_ERROR, "RX: [PCU <- BTS] %s TFI: %u TLLI: 0x%08x FIXME: Packet resource request\n", (tbf->direction == GPRS_RLCMAC_UL_TBF) ? "UL" : "DL", tbf->tfi, tbf->tlli); > break; > default: > LOGP(DRLCMAC, LOGL_NOTICE, "RX: [PCU <- BTS] unknown control block received\n"); > @@ -838,14 +838,14 @@ int gprs_rlcmac_rcv_rach(uint8_t ra, uint32_t Fn, int16_t qta) > // Create new TBF > tfi = tfi_alloc(GPRS_RLCMAC_UL_TBF, &trx, &ts, -1, -1); > if (tfi < 0) { > - LOGP(DRLCMAC, LOGL_NOTICE, "No PDCH ressource\n"); > + LOGP(DRLCMAC, LOGL_NOTICE, "No PDCH resource\n"); > /* FIXME: send reject */ > return -EBUSY; > } > /* set class to 0, since we don't know the multislot class yet */ > tbf = tbf_alloc(NULL, GPRS_RLCMAC_UL_TBF, tfi, trx, ts, 0, 1); > if (!tbf) { > - LOGP(DRLCMAC, LOGL_NOTICE, "No PDCH ressource\n"); > + LOGP(DRLCMAC, LOGL_NOTICE, "No PDCH resource\n"); > /* FIXME: send reject */ > return -EBUSY; > } > diff --git a/src/gprs_rlcmac_sched.cpp b/src/gprs_rlcmac_sched.cpp > index f6af9b7..83a89ac 100644 > --- a/src/gprs_rlcmac_sched.cpp > +++ b/src/gprs_rlcmac_sched.cpp > @@ -90,7 +90,7 @@ int gprs_rlcmac_rcv_rts_block(uint8_t trx, uint8_t ts, uint16_t arfcn, > ul_ass_tbf = tbf; > } > > - /* check uplink ressource for polling */ > + /* check uplink resource for polling */ > if (poll_tbf) { > LOGP(DRLCMACSCHED, LOGL_DEBUG, "Received RTS for PDCH: TRX=%d " > "TS=%d FN=%d block_nr=%d scheduling free USF for " > @@ -99,17 +99,17 @@ int gprs_rlcmac_rcv_rts_block(uint8_t trx, uint8_t ts, uint16_t arfcn, > (tbf->direction == GPRS_RLCMAC_UL_TBF) ? "UL" : "DL", > poll_tbf->tfi); > /* use free USF */ > - /* else, we search for uplink ressource */ > + /* else, we search for uplink resource */ > } else { > - /* select uplink ressource */ > + /* select uplink resource */ > for (i = 0, tfi = pdch->next_ul_tfi; i < 32; > i++, tfi = (tfi + 1) & 31) { > tbf = pdch->ul_tbf[tfi]; > /* no TBF for this tfi, go next */ > if (!tbf) > continue; > - /* no UL ressources needed, go next */ > - /* we don't need to give ressources in FINISHED state, > + /* no UL resources needed, go next */ > + /* we don't need to give resources in FINISHED state, > * because we have received all blocks and only poll > * for packet control ack. */ > if (tbf->state != GPRS_RLCMAC_FLOW) > @@ -119,9 +119,9 @@ int gprs_rlcmac_rcv_rts_block(uint8_t trx, uint8_t ts, uint16_t arfcn, > usf = tbf->dir.ul.usf[ts]; > LOGP(DRLCMACSCHED, LOGL_DEBUG, "Received RTS for PDCH: " > "TRX=%d TS=%d FN=%d block_nr=%d scheduling " > - "USF=%d for required uplink ressource of " > + "USF=%d for required uplink resource of " > "UL TBF=%d\n", trx, ts, fn, block_nr, usf, tfi); > - /* next TBF to handle ressource is the next one */ > + /* next TBF to handle resource is the next one */ > pdch->next_ul_tfi = (tfi + 1) & 31; > break; > } > @@ -160,7 +160,7 @@ int gprs_rlcmac_rcv_rts_block(uint8_t trx, uint8_t ts, uint16_t arfcn, > > /* Prio 2: select data message for downlink */ > if (!msg) { > - /* select downlink ressource */ > + /* select downlink resource */ > for (i = 0, tfi = pdch->next_dl_tfi; i < 32; > i++, tfi = (tfi + 1) & 31) { > tbf = pdch->dl_tbf[tfi]; > @@ -170,7 +170,7 @@ int gprs_rlcmac_rcv_rts_block(uint8_t trx, uint8_t ts, uint16_t arfcn, > /* no DL TBF, go next */ > if (tbf->direction != GPRS_RLCMAC_DL_TBF) > continue; > - /* no DL ressources needed, go next */ > + /* no DL resources needed, go next */ > if (tbf->state != GPRS_RLCMAC_FLOW > && tbf->state != GPRS_RLCMAC_FINISHED) > continue; > @@ -178,7 +178,7 @@ int gprs_rlcmac_rcv_rts_block(uint8_t trx, uint8_t ts, uint16_t arfcn, > LOGP(DRLCMACSCHED, LOGL_DEBUG, "Scheduling data " > "message at RTS for DL TBF=%d (TRX=%d, " > "TS=%d)\n", tfi, trx, ts); > - /* next TBF to handle ressource is the next one */ > + /* next TBF to handle resource is the next one */ > pdch->next_dl_tfi = (tfi + 1) & 31; > /* generate DL data block */ > msg = gprs_rlcmac_send_data_block_acknowledged(tbf, fn, > diff --git a/src/tbf.txt b/src/tbf.txt > index eab58ba..025e56c 100644 > --- a/src/tbf.txt > +++ b/src/tbf.txt > @@ -118,7 +118,7 @@ Control TS: > Polling: > In order to poll uplink control block from MS, a special poll state and > frame number is stored at TBF. The scheduler reads that value and will not > - assign uplink ressource for other TBFs at that frame number. > + assign uplink resource for other TBFs at that frame number. > > When there is no uplink transmission received on the block, a timeout is > indicated by layer 1 interface. There are two ways of checking timeout: > -- > 1.7.10.4 > > -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From alexander.chemeris at gmail.com Mon Jul 23 20:52:46 2012 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Tue, 24 Jul 2012 00:52:46 +0400 Subject: [PATCH] misc: Add the libosmocore CFLAGS to the CPPFLAGS In-Reply-To: <1343033418-30284-1-git-send-email-hfreyther@sysmocom.de> References: <1343033418-30284-1-git-send-email-hfreyther@sysmocom.de> Message-ID: Hi Holger, Looks good. If others don't object, could you apply this? On Mon, Jul 23, 2012 at 12:50 PM, Holger Hans Peter Freyther wrote: > From: Holger Hans Peter Freyther > > libosmocore might not be in the standard include path, > add the CFLAGS to the preprocessor flags. This is fixing > the build on the Osmocom Jenkins. > --- > src/Makefile.am | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/Makefile.am b/src/Makefile.am > index 041831f..98574fa 100644 > --- a/src/Makefile.am > +++ b/src/Makefile.am > @@ -18,7 +18,7 @@ > # along with this program. If not, see . > # > > -AM_CPPFLAGS = $(STD_DEFINES_AND_INCLUDES) > +AM_CPPFLAGS = $(STD_DEFINES_AND_INCLUDES) $(LIBOSMOCORE_CFLAGS) $(LIBOSMOGB_CFLAGS) $(LIBOSMOGSM_CFLAGS) > AM_CXXFLAGS = -Wall -ldl -pthread > > noinst_LTLIBRARIES = libgprs.la > -- > 1.7.10.4 > > -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From hfreyther at sysmocom.de Tue Jul 24 09:28:45 2012 From: hfreyther at sysmocom.de (Holger Hans Peter Freyther) Date: Tue, 24 Jul 2012 11:28:45 +0200 Subject: Multislot finished and well tested In-Reply-To: <20120722132938.GD1552@sangmingze.sysmocom.de> References: <500B9E68.7000909@eversberg.eu> <20120722132938.GD1552@sangmingze.sysmocom.de> Message-ID: <20120724092845.GC2296@sangmingze.sysmocom.de> On Sun, Jul 22, 2012 at 03:29:38PM +0200, Holger Hans Peter Freyther wrote: > On Sun, Jul 22, 2012 at 08:32:08AM +0200, jolly wrote: > > hi, > > > > i like to announce that multislot supports has been finished and is > > working well. Hi Jolly, > > great! Do you have any unit tests for the scheduler? I think it is > essential to have unit tests for the scheduling, e.g. specially as > someone making a modification might not have devices with all the > classes. I can help you to setup the autotest setup we are using in > the other modules. any comments? It is an absolute requirement to be able to test this code. holger -- - Holger Freyther http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Schivelbeiner Str. 5 * 10439 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte From andreas at eversberg.eu Tue Jul 24 13:42:33 2012 From: andreas at eversberg.eu (jolly) Date: Tue, 24 Jul 2012 15:42:33 +0200 Subject: Multislot finished and well tested In-Reply-To: <20120724092845.GC2296@sangmingze.sysmocom.de> References: <500B9E68.7000909@eversberg.eu> <20120722132938.GD1552@sangmingze.sysmocom.de> <20120724092845.GC2296@sangmingze.sysmocom.de> Message-ID: <500EA649.4010402@eversberg.eu> >> great! Do you have any unit tests for the scheduler? I think it is >> essential to have unit tests for the scheduling, e.g. specially as >> someone making a modification might not have devices with all the >> classes. I can help you to setup the autotest setup we are using in >> the other modules. >> hi holger, i think it is quite complex to do tests. the scheduler does not deal with any class. it just assigns up and downlink ressource to blocks of a specific timeslot, if it is assigned to TBFs. in order to test all classes, we need to check the multislot algorithm. in my opinion, the only way to test all this would be to emulate a phone with all different classes, do up and downlink assignment, and check if the assigned slots comply to the classes. regards, andreas From andreas at eversberg.eu Tue Jul 24 13:59:16 2012 From: andreas at eversberg.eu (jolly) Date: Tue, 24 Jul 2012 15:59:16 +0200 Subject: Multislot finished and well tested In-Reply-To: References: <500B9E68.7000909@eversberg.eu> Message-ID: <500EAA34.3000501@eversberg.eu> Alexander Chemeris wrote: > Hi Andreas, > > On Sun, Jul 22, 2012 at 10:32 AM, jolly wrote: > >> i like to announce that multislot supports has been finished and is >> working well. >> > Thank you for your effort! We'll be testing this with OpenBTS soon. > > What is your next target? > > hi alexander, there are two major features already in the jolly and jolly_dsp branch and some bugfixes/improvements. the two things are: paging of mobile through PCU socket interface. the BTS must send mobile identitiy (including CHANNEL_REQIRED IE) to the PCU whenever a paging is performed. (see pcuif_proto.h) the PCU will send the paging on PACCH, so the mobile can receive paging in packet transfer mode. (since the PCU cannot relate the mobile identity (TMSI) to the TBFs, it will send it on PACCHs, so all TBFs will receive it. it is implemented in sysmo-bts too. if you need help with that on openbts side, let me know. direct access of DSP of sysmo-BTS for PDCH data. this way there is less overhead. but alternatively all packets can be forwarded through PCU socket interface as usual. i don't have anything more in mind for now, except some tests and bugfixes. regards, andreas From hfreyther at sysmocom.de Tue Jul 24 18:57:52 2012 From: hfreyther at sysmocom.de (Holger Hans Peter Freyther) Date: Tue, 24 Jul 2012 20:57:52 +0200 Subject: Multislot finished and well tested In-Reply-To: References: <500B9E68.7000909@eversberg.eu> <20120722132938.GD1552@sangmingze.sysmocom.de> <20120723071212.GA14541@sangmingze.sysmocom.de> Message-ID: <20120724185752.GB14047@sangmingze.sysmocom.de> On Mon, Jul 23, 2012 at 10:15:06AM +0200, Alexander Chemeris wrote: > > PS: NOOB question, what is the meaning of USF==0x7? > > This is a special value which in means "free", i.e. it's not allocated > to any mobile if we use dynamic allocation (IIRC). And if we use PRACH > channel instead of RACH, then USF 7 is used to mark places for Access > Bursts. Okay, so next noob question (and applies to the jolly branch) gprs_rlmac_sched.c:gprs_rlcmac_rcv_rts_block(...) { uint8_t usf = 0x7; if (poll_tbf) { } else { nested_for_loop { ... usf = ... break_on_found_item; } } msg->data[0] = (msg->data[0] & 0xf8) | usf; } in the above it is possible that !poll_tbf and usf == 0x7, is this the right behavior in case no TBF could be found? -- - Holger Freyther http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Schivelbeiner Str. 5 * 10439 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte From hfreyther at sysmocom.de Tue Jul 24 19:45:06 2012 From: hfreyther at sysmocom.de (Holger Hans Peter Freyther) Date: Tue, 24 Jul 2012 21:45:06 +0200 Subject: Multislot finished and well tested In-Reply-To: <500EA649.4010402@eversberg.eu> References: <500B9E68.7000909@eversberg.eu> <20120722132938.GD1552@sangmingze.sysmocom.de> <20120724092845.GC2296@sangmingze.sysmocom.de> <500EA649.4010402@eversberg.eu> Message-ID: <20120724194506.GA16049@sangmingze.sysmocom.de> On Tue, Jul 24, 2012 at 03:42:33PM +0200, jolly wrote: > Good evening, > > i think it is quite complex to do tests. the scheduler does not deal > with any class. it just assigns up and downlink ressource to blocks of a > specific timeslot, if it is assigned to TBFs. in order to test all > classes, we need to check the multislot algorithm. in my opinion, the > only way to test all this would be to emulate a phone with all different > classes, do up and downlink assignment, and check if the assigned slots > comply to the classes. well, your knowledge about the code and the GPRS specification is greater than mine. It is a hard requirement to be able to test this code and I can give you general advice how to structure your code to make this possible. The complexity to test really boils down to how the code is structured, I agree that with the given structure (long functions, concerns mixed) it is difficult to test but given the tbf.txt file some great unit tests are described and just need to be implemented in C. Some very short basics. A unittest tests a part (an unit, a module, an algorithm) of the whole system in isolation. In general there are white and black box tests, with white one actually knows the implementation and aims for full coverage (e.g. every possible combination, sqlite is a project doing that). When a method is called there will be a return value and a side-effect (e.g. the state of TBF is changed) both can and should be observed when writing a test. One example of making code testable: The gprs_rlcmac_rcv_rts_block method can be split into several units that can be tested separately. This can be done for many other methods as well: 1.) sched_poll(poll_fn, out **poll_tbf, out *ul_ack_tbf...) (maybe return a struct with pointers to the queues) 2.) int (usf) sched_select_uplink(in *pdch) the next_ul_tfi side-effect might not be in that method 4.) sched_select_ctrl_msg(in *queues) 3.) msgb* sched_select_downlink(in *pdch) 5.) the rest of the method into a new method that generates the msgb.. I understand that it might be difficult to find a structure that makes testing more easy but in most cases it exists. holger -- - Holger Freyther http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Schivelbeiner Str. 5 * 10439 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte From andreas at eversberg.eu Tue Jul 24 19:51:22 2012 From: andreas at eversberg.eu (Andreas Eversberg) Date: Tue, 24 Jul 2012 21:51:22 +0200 Subject: Multislot finished and well tested Message-ID: <500EFCBA.6070605@eversberg.eu> Holger Hans Peter Freyther wrote: > in the above it is possible that !poll_tbf and usf == 0x7, is this the > right behavior in case no TBF could be found? hi holger, if poll_tbf is set, we must use an unassigned usf, because only the polled mobile may transmit. (usf 7 is never assigned.) if poll_tbf is not set and if no uplink ressource is required, i use usf 7 (any other usf would also be ok, since we don't need any mobile to transmit on uplink, but i use 7, because it is never assigend to any mobile). regards, andreas From hfreyther at sysmocom.de Tue Jul 24 21:51:17 2012 From: hfreyther at sysmocom.de (Holger Hans Peter Freyther) Date: Tue, 24 Jul 2012 23:51:17 +0200 Subject: talloc, malloc and memory leaks Message-ID: <20120724215117.GB16049@sangmingze.sysmocom.de> Hi, this is not meant as an intensive review on memory allocations in the PCU code. While browsing the code of the ready-to-send method to select the next payload I noticed the code below: RlcMacDownlink_t * mac_control_block = (RlcMacDownlink_t *)malloc(sizeof(RlcMacDownlink_t)); LOGP(DRLCMAC, LOGL_DEBUG, "+++++++++++++++++++++++++ TX : Packet Paging Request +++++++++++++++++++++++++\n"); decode_gsm_rlcmac_downlink(pag_vec, mac_control_block); LOGPC(DCSN1, LOGL_NOTICE, "\n"); LOGP(DRLCMAC, LOGL_DEBUG, "------------------------- TX : Packet Paging Request -------------------------\n"); bitvec_free(pag_vec); This and other all other places really should use talloc to make finding memory leaks more easy (e.g. by printing the leak report), the second part is that we appear to leak this on every paging message sent by the PCU and the third is actually a question. Should we use a GCC extension that helps dealing with local variables? GCC can call a cleanup function on exit of the scope, an example can be seen here[1] nad this[2] is the description of the feature. holger [1] https://mail.gnome.org/archives/gtk-devel-list/2011-November/msg00050.html [2] http://gcc.gnu.org/onlinedocs/gcc/Variable-Attributes.html#Variable-Attributes -- - Holger Freyther http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Schivelbeiner Str. 5 * 10439 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte From hfreyther at sysmocom.de Tue Jul 24 22:23:16 2012 From: hfreyther at sysmocom.de (Holger Hans Peter Freyther) Date: Wed, 25 Jul 2012 00:23:16 +0200 Subject: Compiling with clang --analyze Message-ID: <20120724222316.GC16049@sangmingze.sysmocom.de> Hi, one more email for tonight. Using clang/smatch from time to time can highlight certain issues. The easiest way to invoke it is this: $ make CC="clang --analyze" CXX="clang++ --analyze" 1.) gprs_bssgp_pcu.cpp:241:6: warning: Access to field 'state' results in a dereference of a null pointer (loaded from variable 'bctx') if (bctx->state & BVC_S_BLOCKED && pdu_type != BSSGP_PDUT_STATUS) ^~~~ the handling of bctx is a bit weird, in theory it can be NULL but I am not sure if we are likely to receive the messages that would make the PCU crash though. gprs_bssgp_pcu_rcvmsg can call the above function/line with a NULL bctx. 2.) gprs_rlcmac.cpp:728:25: warning: Assigned value is garbage or undefined tbf->dir.ul.usf[ts] = usf[ts]; ^ ~~~~~~~ Probably true, alloc_algorithm_b is really too big to be readable to verify that this is not a false positive. cheers holger -- - Holger Freyther http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Schivelbeiner Str. 5 * 10439 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte From andreas at eversberg.eu Wed Jul 25 06:53:50 2012 From: andreas at eversberg.eu (jolly) Date: Wed, 25 Jul 2012 08:53:50 +0200 Subject: Multislot finished and well tested In-Reply-To: <20120724194506.GA16049@sangmingze.sysmocom.de> References: <500B9E68.7000909@eversberg.eu> <20120722132938.GD1552@sangmingze.sysmocom.de> <20120724092845.GC2296@sangmingze.sysmocom.de> <500EA649.4010402@eversberg.eu> <20120724194506.GA16049@sangmingze.sysmocom.de> Message-ID: <500F97FE.9060601@eversberg.eu> > 1.) sched_poll(poll_fn, out **poll_tbf, out *ul_ack_tbf...) > (maybe return a struct with pointers to the queues) > 2.) int (usf) sched_select_uplink(in *pdch) > the next_ul_tfi side-effect might not be in that method > 4.) sched_select_ctrl_msg(in *queues) > 3.) msgb* sched_select_downlink(in *pdch) > 5.) the rest of the method into a new method that generates > the msgb.. > hi holger, i splitted the scheduler and committed it to jolly branch. i did not make them static, so they can be used from test code. also i committed a replacement patch for malloc(). it now frees all allocated decoder structures after use. regards, andreas From andreas at eversberg.eu Wed Jul 25 07:15:59 2012 From: andreas at eversberg.eu (jolly) Date: Wed, 25 Jul 2012 09:15:59 +0200 Subject: Compiling with clang --analyze In-Reply-To: <20120724222316.GC16049@sangmingze.sysmocom.de> References: <20120724222316.GC16049@sangmingze.sysmocom.de> Message-ID: <500F9D2F.5000000@eversberg.eu> hi holger, i commited fixes to these issues. i have not clang installed, so i could not test it, but is should be fixed. regards, andreas From alexander.chemeris at gmail.com Wed Jul 25 07:17:03 2012 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Wed, 25 Jul 2012 09:17:03 +0200 Subject: talloc, malloc and memory leaks In-Reply-To: <20120724215117.GB16049@sangmingze.sysmocom.de> References: <20120724215117.GB16049@sangmingze.sysmocom.de> Message-ID: On Tue, Jul 24, 2012 at 11:51 PM, Holger Hans Peter Freyther wrote: > Should we use a GCC extension that > helps dealing with local variables? GCC can call a cleanup function > on exit of the scope, an example can be seen here[1] nad this[2] is > the description of the feature. Oh, this looks like "hack your C to be C++", isn't it better to just use C++ then? It has a very clean semantics for this which is supported by _all_ compilers. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From hfreyther at sysmocom.de Wed Jul 25 09:12:17 2012 From: hfreyther at sysmocom.de (Holger Hans Peter Freyther) Date: Wed, 25 Jul 2012 11:12:17 +0200 Subject: Multislot finished and well tested In-Reply-To: <500F97FE.9060601@eversberg.eu> References: <500B9E68.7000909@eversberg.eu> <20120722132938.GD1552@sangmingze.sysmocom.de> <20120724092845.GC2296@sangmingze.sysmocom.de> <500EA649.4010402@eversberg.eu> <20120724194506.GA16049@sangmingze.sysmocom.de> <500F97FE.9060601@eversberg.eu> Message-ID: <20120725091217.GB30905@sangmingze.sysmocom.de> On Wed, Jul 25, 2012 at 08:53:50AM +0200, jolly wrote: > > also i committed a replacement patch for malloc(). it now frees all > allocated decoder structures after use. lovely. I created the 'testsuite' setup and a no-op testcase. I will push it to a branch based on yours. What is the plan in regard to merging your changes to master? holger -- - Holger Freyther http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Schivelbeiner Str. 5 * 10439 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte From hfreyther at sysmocom.de Wed Jul 25 09:19:19 2012 From: hfreyther at sysmocom.de (Holger Hans Peter Freyther) Date: Wed, 25 Jul 2012 11:19:19 +0200 Subject: talloc, malloc and memory leaks In-Reply-To: References: <20120724215117.GB16049@sangmingze.sysmocom.de> Message-ID: <20120725091919.GD30905@sangmingze.sysmocom.de> On Wed, Jul 25, 2012 at 09:17:03AM +0200, Alexander Chemeris wrote: > > Oh, this looks like "hack your C to be C++", isn't it better to just > use C++ then? It has a very clean semantics for this which is > supported by _all_ compilers. Hi, for me the PCU code is C compiled with a C++ compiler. I would more think we will move to using to use a C compiler than using more of C++ features. But yes the 'cleanup' attribute can be easily handled by a "template TallocPtr" class. holger -- - Holger Freyther http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Schivelbeiner Str. 5 * 10439 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte From andreas at eversberg.eu Thu Jul 26 11:25:24 2012 From: andreas at eversberg.eu (jolly) Date: Thu, 26 Jul 2012 13:25:24 +0200 Subject: Multislot finished and well tested In-Reply-To: References: <500B9E68.7000909@eversberg.eu> Message-ID: <50112924.80902@eversberg.eu> Alexander Chemeris wrote: > What is your next target hi alexander, i experiemented with moving C++ code to C. except for csn1 transcoding, all code should be C in my opinion. this way the code becomes much cleaner. (no extern "C" or #ifdef __cplusplus is required.) also it is much easier to add VTY features, because VTY will not compile with C++. what do you think? regards, andreas