Hello,
I want to use the local sims having different MNC/MCC for implementing GPRS
using osmocoms with OpenBTS same as I have used them for GSM calls and sms
using only openBTS. But your site
http://openbsc.osmocom.org/trac/wiki/OpenBSC_GPRS says, "it is currently
not possible". As it is long when posted on this site so I want to ask is
it possible *now* to use the local sims? Hope you have understood my
question. Waiting for your reply. Thanks.
Regards,
Saba Arshad
Hello All,
We have executed profiling test of two versions of algorithm for decoding compressed bitmap of EPDAN.
>From the results , we see that performance is better in Tree based decoding (Version2 as given below )
Version 1: Bitmap based decoding as present in current master branch ( Function name osmo_t4_decode )
Version 2: Tree based decoding ( Function name decompress_crbb , as proposed in patch "Decompress the CRBB bitmap using tree based approach"<http://lists.osmocom.org/pipermail/osmocom-net-gprs/2016-March/000525.html> )
A sample bitmap taken from a real mobile log is used for the test.
Host execution: Time taken to decode (micro seconds)
Version 1: (Bitmap based decoding) : MIN -17 MAX -19 AVERAGE -17.9
Version 2 (tree based decoding): MIN -4 MAX -13 AVERAGE - 5.2
Target execution: Time taken to decode (micro seconds)
Version 1: (Bitmap based decoding) : MIN -277 MAX -583 AVERAGE - 353
Version 2 (tree based decoding): MIN -67 MAX -86 AVERAGE - 69.8
Regards
Prasad
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
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
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
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
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
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
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
Hi,
Can you guide us to address issues we are currently facing about Gerrit process as listed below
1) Jenkins Build reports failure. Can you suggest the reason for this.
Because in our local branch the Unit test and build is successful.
2) Is there any specific process to resubmit patch after addressing the
review comments.
Thanks,
Aravind Sirsikar
Hello All,
We at Radisys have started working on EGPRS performance analysis and stability testing on NuRAN LiteCell 1.0. Below are the High level Items we have planned.
1) EGPRS Performance benchmarking analysis and optimization
2) CPU and Memory benchmarking and analysis
3) EGPRS multi user tests, Stability, Stress and Soak testing
We will keep sharing the relevant patches as well as bench marking report to the mailing list for seeking inputs and suggestion.
Thanks,
Aravind Sirsikar
Dear all,
Deater has been investigating which issues currently prevent us from
using GEA in OsmoSGSN. His mail has been sitting in my inbox too long,
and hence I'm forwarding his results here to the mailing list for
further discussion / follow-up.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)