osmocom-net-gprs

osmocom-net-gprs@lists.osmocom.org

5 participants
507 discussions

Testcase + commit on EDGE patches
by Holger Freyther 12 Jul '16

12 Jul '16

Good Morning all, my real life distraction is mostly gone and I can be more active in developing and reviewing again. From my point of view Sysmocom and me have responded to all Gerrit reviews and we are waiting for the next iteration of the patchset. Before giving a high-level point of view of orders and dependencies I would like to say some words about testing. (Automatic Unit-)testing is crucial. Sometimes it is the easiest way to test a behavior, it allows to hit/test error paths but are hit less frequently. Combined with regular execution of the tests and forbidding to merge code that breaks tests, features that worked once and have a good test will continue to work. It is the key for being able to move forward quickly. For many patches I reviewed test + feature or test + bugfix were in separate commits and then the order is problematic. From my point of view there are only a few "right" combinations. Let me try to explain: Assume some code is doing "if (res) " instead of "if (!res)" and after long debugging we have found that single line (and our code is full of printf now) and it is a path that has not been systematically tested yet. To move forward and create a patchset we should: * Add a test case that triggers the broken behavior. With a xUnit framework we would add an expected failure, with our approach we either capture the broken output, comment the OSMO_ASSERT or revert the OSMO_ASSERT condition. (See libosmocore * Let's say that if is already in code like: if (a) if (b) if (c) if (d) and we would like to re-factor it to be more readable. Then please do the refactoring _before_ applying the bugfix. The test output/result should not change as it is a refactoring. * Finally apply the fix. For bugfixes try to make them as small and clear as possible. Let's say even if you don't like the algorithm used, fix it. As part of the fix the test assertions can be enabled and the output change. The smaller the fix, the better. See libosmocore 6ac70a41ee4cc9f3f286fb6b8f397215590fc2ac for such an example. * If the algorithm is indeed bad now is the time to change it. It should just change the (refactored) method, test output and result should be stable and maybe add more tests as the new code is easier to test. In general my preferred way: New feature => one commit to add feature + test Bugfix => First test, then bugfix+test output/result update thank you holger

2 1

Status of EDGE work and plans
by Holger Freyther 12 Jul '16

12 Jul '16

Hi guys, maybe a short summary helps to see where we are and where we need to go. Let me start with myself. Besides reviewing code I have two GPRS related topics I want to look at. The first one is the missing state transition for single phase access to avoid having to revert, the second one is to use perf to look at the performance difference of the two compressed bitmap routines. The bigger picture is that we have some features that work in parallel and the right order might be important to unlock them. My review/merging priority right now is: * 11bit RACH decoding: ** Get the libosmocore change in. As 0x0 is used as a value it needs to be inside the enum ** PCU protocol change to transport this access burst type and update to uint16_t ** OpenBSC change to allow 11bit burst access ** PCU change * T4 compression/decompression: I am not sold on the look-up tree yet but I understand that for good compression the API in libosmocore needs to change. a.) We remove T4 support from libosmocore as it is not used outside of the PCU and this gives us a way to mature the API without having to synchronize two projects b.) We know which out variables we need to add and can define the API The implementation (unrolled loop vs. tree) can be decided at a later point as we can hide it from the interface. * Changing coding schemes on re-transmission/etc. These are features and fixes that only relate to the PCU. I can merge whatever patchset is ready first. kind regards and looking forward to rebased patchsets holger

1 0

GTP, GGSN and PGW testing
by Vasu Devan 12 Jul '16

12 Jul '16

Hi, Currently i am working in LTE and would like to test SGW and PDN-GW along with GTP protocol for my research aspect. I have already worked and used OpenairInterface EPC. But, i wanted to explore other kernel or user-space options of GTP. Please let me know the procedure to access the code of , (i) Latest mainline linux kernel version with your GTP code and user space GTP module. (ii) Also, could you please kindly provide me access to the SGW/GGSN and PGW codes. Please kindly provide me access to the latest code, such that i could test it and will even post the test results to the community. Thanks & Regards Vasu.

3 3

RE: osmo-pcu[master]: Add data structure for ARQ-II in EGPRS DL
by Aravind Sirsikar 29 Jun '16

29 Jun '16

Hi Harald/Holger, Please let me know any further updates on the pending review for ARQ2?. Since it is pending for long time we would like to know how to proceed over this. Thanks, Aravind Sirsikar

2 1

RE: osmo-pcu[master]: Add data structure for ARQ-II in EGPRS DL
by Aravind Sirsikar 24 Jun '16

24 Jun '16

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

2 2

conversations in gerrit "lost" here
by Neels Hofmeyr 21 Jun '16

21 Jun '16

I am a bit ambiguous on our use of comments in gerrit. We do discuss at least some fairly interesting things in the comments on patches waiting for approval in gerrit. When these discussions are attempted on openbsc@ or osmocom-net-gprs@, you tend to block off and redirect the discussion back to the gerrit comments infrastructure. However, we have moved the gerrit mails to a separate and very noisy mailing list, and these potentially interesting discussions are moved essentially out of the public focus. Also, if we in future would like to investigate discussion on some topic, we need to search both the main ML and the gerrit ML. IMHO it would make sense to copy the human originated comments to our "human" mailing lists, so that the automatic jenkins and gerrit notifications remain on the noisy ML while we see all discussions here. Is that easy to achieve (filter on originator of comment), and would you guys agree? ~Neels -- - Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Harald Welte

1 0

gerrit and branches
by Neels Hofmeyr 20 Jun '16

20 Jun '16

Today I've taken another close look at branches and gerrit, and have written down my conclusions here: http://osmocom.org/projects/cellular-infrastructure/wiki/Gerrit#Submitting-… In summary: * Branch re-submission needs the workaround of tweaking the first commit. It would be nice to fix gerrit to not need this, but for the time being the effort of cosmetically changing the first commit log is acceptable. * It *is* possible to have private branches in the gerrit repos and still be able to submit them to master, with the proper project config. I have thus switched all our gerrit projects' configs to rebase-if-necessary with the flags as described on the wiki page. (Except for osmo-pcap, where we still disallow content merges.) I will now go back to pushing my "private" developments to the public repository (gerrit) under the neels/ or sysmocom/ namespaces. ~Neels -- - Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Harald Welte

2 4

testing gerrit, might be down shortly
by Neels Hofmeyr 20 Jun '16

20 Jun '16

I'm testing things related to our gerrit bug report, if it's not working for you right now it may be because I'm restarting gerrit to test with/out our fix. I'll repost when I'm done. ~Neels -- - Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Harald Welte

1 1

[EGPRS PCU] ARQ-2 support for EGPRS DL Retransmission
by Aravind Sirsikar 20 Jun '16

20 Jun '16

Hi, I have pushed series of patches related to ARQ-2 support for EGPRS DL Retransmission. This patches have been reviewed earlier and comments have been Addressed. These patches are tested and validated with NuRAN 1.0 hardware. Below are the links to Gerrit review of each patches along with patch description. 1) https://gerrit.osmocom.org/#/c/332/ ==>Add data structure for ARQ-II in EGPRS DL. 2) https://gerrit.osmocom.org/#/c/333/ ==>Add Accessor functions for ARQ-II in EGPRS DL. 3) https://gerrit.osmocom.org/#/c/334/ ==>Modify DL tbf flow for ARQ-II in EGPRS DL Retx. 4) https://gerrit.osmocom.org/#/c/335/ ==>Add test cases to support ARQ-II for EGPRS DL Retx. Above patches must be merged to master in the same order as mentioned above. Thanks, Aravind Sirsikar

2 1

RE: [MERGED] osmo-pcu[master]: Add test cases for Header Type 2 in EGPRS UL
by Aravind Sirsikar 17 Jun '16

17 Jun '16

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

5 6

← Newer
1
...
32
33
34
35
36
37
38
...
51
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

osmocom-net-gprs