From vasu.018 at gmail.com Fri Jul 8 13:30:42 2016 From: vasu.018 at gmail.com (Vasu Devan) Date: Fri, 8 Jul 2016 09:30:42 -0400 Subject: GTP, GGSN and PGW testing Message-ID: 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From raghav at watchy.in Tue Jul 12 03:12:16 2016 From: raghav at watchy.in (Raghavendran N) Date: Tue, 12 Jul 2016 08:42:16 +0530 Subject: GTP, GGSN and PGW testing In-Reply-To: References: Message-ID: Hi Vasu, Generally, such requests will need to be accompanied with the places you looked for information: wiki, email archives etc,. After you don't find the required information, you would write to the list saying where you looked and what was not found. It will be good if you could do that and reply back. Good to see that you are working in LTE. Best regards, -raghav On Fri, Jul 8, 2016 at 7:00 PM, Vasu Devan wrote: > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vasu.018 at gmail.com Tue Jul 12 04:28:35 2016 From: vasu.018 at gmail.com (Vasu Devan) Date: Tue, 12 Jul 2016 00:28:35 -0400 Subject: GTP, GGSN and PGW testing In-Reply-To: References:

Message-ID: Got the needed details of the code. Thanks & Regards Vasu. On Mon, Jul 11, 2016 at 11:12 PM, Raghavendran N wrote: > Hi Vasu, > > Generally, such requests will need to be accompanied with the places you > looked for information: wiki, email archives etc,. After you don't find the > required information, you would write to the list saying where you looked > and what was not found. It will be good if you could do that and reply back. > > Good to see that you are working in LTE. > > Best regards, > -raghav > > On Fri, Jul 8, 2016 at 7:00 PM, Vasu Devan wrote: > >> 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. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Tue Jul 12 06:09:08 2016 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 12 Jul 2016 08:09:08 +0200 Subject: GTP, GGSN and PGW testing In-Reply-To: References: Message-ID: <20160712060908.GV5250@nataraja> Hi Vasu, On Fri, Jul 08, 2016 at 09:30:42AM -0400, Vasu Devan wrote: > Currently i am working in LTE please try to exlain the nature of your work. Don't forget to mention if the result of your work is open source available to the wider community (and if so, where can we find it). If that's the case, many people might be more sympathetic to helping you with responses. > (i) Latest mainline linux kernel version with your GTP code and user space GTP > module. The kernel code is in mainline, i.e. the officiall latest linux kernel git repo of Linus Torvalds. The netlink library for its control can be found at http://git.osmocom.org/libgtpnl/ > (ii) Also, could you please kindly provide me access to the SGW/GGSN and PGW > codes. I'm not sure where you got the expectation that a) the Osmocom project had implemented any SGW or PGW b) that the Osmocom project - as a pure FOSS project - would hide access to any of its code. In terms of GGSN, Pablo did some work of making openggsn work on top of the kenrel GTP-U code, whihc is available from http://git.osmocom.org/openggsn/ in the 'osmo-ggsn' branch. There is also an unrelated project called 'ergw' which strives to implement bot GGSN and P-GW functions: https://github.com/travelping/ergw > Please kindly provide me access to the latest code, All code we release is available from http://git.osmocom.org/ > such that i could test it and will even post the test results to the > community. This community is primarily about joint development of code, so you can help us to create by using the existing code and adding what you need. We do need people improve testing of the code, too - but then we need testing of existing code, not of code that doesn't even exist yet :) -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From holger at freyther.de Tue Jul 12 06:43:25 2016 From: holger at freyther.de (Holger Freyther) Date: Tue, 12 Jul 2016 08:43:25 +0200 Subject: Testcase + commit on EDGE patches Message-ID: <18FD46F4-6530-4C7D-9283-9FC41CF46EB1@freyther.de> 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 From holger at freyther.de Tue Jul 12 06:58:25 2016 From: holger at freyther.de (Holger Freyther) Date: Tue, 12 Jul 2016 08:58:25 +0200 Subject: Status of EDGE work and plans Message-ID: 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 From nhofmeyr at sysmocom.de Tue Jul 12 11:58:21 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 12 Jul 2016 13:58:21 +0200 Subject: Testcase + commit on EDGE patches In-Reply-To: <18FD46F4-6530-4C7D-9283-9FC41CF46EB1@freyther.de> References: <18FD46F4-6530-4C7D-9283-9FC41CF46EB1@freyther.de> Message-ID: <20160712115821.GA1622@ass40.sysmocom.de> On Tue, Jul 12, 2016 at 08:43:25AM +0200, Holger Freyther wrote: > * 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. Yes: I would typically like to first submit an XFAIL test to show that the behavior is broken, then fix the problem as well as the result expectation in the same commit. But in all osmocom projects I'm active in there is no XFAIL... So I would submit the test and the fix in the same commit. To verify the test, one would revert the fixing part of the commit. We can't add easily a way to expect failure with autotest, can we? > please do the refactoring _before_ applying the bugfix. +1 > For bugfixes try to make them as small and clear as possible. +1 ~Neels -- - Neels Hofmeyr http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Gesch?ftsf?hrer / Managing Directors: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From holger at freyther.de Wed Jul 13 09:43:06 2016 From: holger at freyther.de (Holger Freyther) Date: Wed, 13 Jul 2016 11:43:06 +0200 Subject: Profiling data of decoding EPDAN compressed bitmap In-Reply-To: References: <0E9A040D-A440-4B2C-8C89-E77B879E749B@freyther.de>

<8E22EFFF-C582-40C0-9BE7-B9CB277CDBD0@freyther.de> <22249C3D-1004-49AA-AE77-F12C2B2D063F@freyther.de> Message-ID: <75AB52FB-ACE2-414E-ACD5-50C363626F51@freyther.de> > On 23 Jun 2016, at 16:39, Pravin Kumaravel Manoharan wrote: > Dear Parvin, > Following is the profiling results comparison of the decoding algorithms (unit in micro-seconds). Each of the 4 test inputs is decoded 10000 times for getting below data. > > Important summary: > 1. For few other identified test vectors existing algorithm fails functionally to decode whereas tree based decoding algorithm succeeds. > 2. Details of these test vectors are in the latest patch available in users/pravin/epdan_profiling at http://git.osmocom.org/radisys/osmo-pcu/ I used it from the testcase you added on gerrit and re-added osmo_t4_decode to it. More about results later: > 3. From the above results it shows that Tree based decoding algorithm is better than existing algorithm for the decoding time consumed. > 4. The max value is not included because it is abnormally high which occurs at very low frequency like once in 10000 iterations. max. Well without distribution this argument is difficult. With a tree we will "jump" through memory a lot more than with a table. E.g. outside a microbenchmark the numbers might not be that stable. Anyway on sysmoBTS #1 with nightly build as of today/yesterday and 89ce5adbe881f4292d5bd5bfc85bd142b3fb4151 (from gerrit refs/changes/17/417/2). Modified to disable verification and 100000 iterations. The difference is big enough. root at sysmobts-v2:~# time ./TbfTest.TREE real 0m24.754s user 0m22.940s sys 0m1.790s root at sysmobts-v2:~# time ./TbfTest real 1m15.535s user 1m13.100s sys 0m1.730s perf report -i perf.data.tree 33.00% TbfTest.TREE libosmocore.so.7.0.0 [.] bitvec_set_bit_pos 20.46% TbfTest.TREE TbfTest.TREE [.] bitvec_write_field(bitvec*, unsigned int&, unsigned long long, unsigned int) 14.30% TbfTest.TREE libosmocore.so.7.0.0 [.] bitvec_set_bit 9.94% TbfTest.TREE TbfTest.TREE [.] search_runlen(node*, unsigned char const*, unsigned char, unsigned char*, unsigned short*) 5.27% TbfTest.TREE TbfTest.TREE [.] Decoding::decompress_crbb(signed char, unsigned char, unsigned char const*, bitvec*) 4.97% TbfTest.TREE libosmocore.so.7.0.0 [.] 0x0000523c 4.29% TbfTest.TREE TbfTest.TREE [.] 0x000023a8 perf report -i perf.data.roll 57.51% TbfTest libosmocore.so.7.0.0 [.] osmo_t4_decode 12.09% TbfTest libosmocore.so.7.0.0 [.] bitvec_shiftl 10.63% TbfTest libosmocore.so.7.0.0 [.] bitvec_set_bit_pos 4.49% TbfTest libosmocore.so.7.0.0 [.] bitvec_set_bit 4.17% TbfTest libosmocore.so.7.0.0 [.] bitvec_fill 3.62% TbfTest libosmocore.so.7.0.0 [.] 0x00004d88 2.21% TbfTest libosmocore.so.7.0.0 [.] bitvec_get_int16_msb 1.60% TbfTest libc-2.18.so [.] memcpy 0.68% TbfTest [kernel.kallsyms] [k] read_cycles Conclusions and comments in the next mail. holger From holger at freyther.de Wed Jul 13 09:53:03 2016 From: holger at freyther.de (Holger Freyther) Date: Wed, 13 Jul 2016 11:53:03 +0200 Subject: Profiling data of decoding EPDAN compressed bitmap In-Reply-To: <75AB52FB-ACE2-414E-ACD5-50C363626F51@freyther.de> References: <0E9A040D-A440-4B2C-8C89-E77B879E749B@freyther.de>

<8E22EFFF-C582-40C0-9BE7-B9CB277CDBD0@freyther.de> <22249C3D-1004-49AA-AE77-F12C2B2D063F@freyther.de> <75AB52FB-ACE2-414E-ACD5-50C363626F51@freyther.de> Message-ID: <586CD5D3-1ED6-4D37-891D-782CF846029E@freyther.de> > On 13 Jul 2016, at 11:43, Holger Freyther wrote: > Hi all, > perf report -i perf.data.tree > > 33.00% TbfTest.TREE libosmocore.so.7.0.0 [.] bitvec_set_bit_pos > 20.46% TbfTest.TREE TbfTest.TREE [.] bitvec_write_field(bitvec*, unsigned int&, unsigned long long, unsigned int) > 14.30% TbfTest.TREE libosmocore.so.7.0.0 [.] bitvec_set_bit so crazily neither the original of the C++ bitvec_write_field nor the C version end up inlining bitvec_set_bit/bitvec_set_bit_pos. 1st) the C++ bitvec_write_field with the reference should be a inline function that calls the C version and passes the parameter as pointer 2nd) We need to get set_bit_pos and set_bit inlined into bitvec_write_field. The wall clock time of my benchmark run goes from ~24s to ~13s if these routines are inlined. > 9.94% TbfTest.TREE TbfTest.TREE [.] search_runlen(node*, unsigned char const*, unsigned char, unsigned char*, unsigned short*) > 5.27% TbfTest.TREE TbfTest.TREE [.] Decoding::decompress_crbb(signed char, unsigned char, unsigned char const*, bitvec*) > 57.51% TbfTest libosmocore.so.7.0.0 [.] osmo_t4_decode osmo_t4_decode (got the runlen step and such inlined). What I think decompress_crbb is doing better is 1st not using bitvec as input but iterating over the bits itself and being more direct in applying the codeword in the result. What I am missing and have to check is if search_runlen can be implemented around the "table" we have and what the performance difference is. I have asked Max for help. I will follow up after I have seen the performance difference. holger From msuraev at sysmocom.de Wed Jul 13 10:21:20 2016 From: msuraev at sysmocom.de (Max) Date: Wed, 13 Jul 2016 12:21:20 +0200 Subject: Profiling data of decoding EPDAN compressed bitmap In-Reply-To: <586CD5D3-1ED6-4D37-891D-782CF846029E@freyther.de> References: <0E9A040D-A440-4B2C-8C89-E77B879E749B@freyther.de>

<8E22EFFF-C582-40C0-9BE7-B9CB277CDBD0@freyther.de> <22249C3D-1004-49AA-AE77-F12C2B2D063F@freyther.de> <75AB52FB-ACE2-414E-ACD5-50C363626F51@freyther.de> <586CD5D3-1ED6-4D37-891D-782CF846029E@freyther.de> <57861620.50909@sysmocom.de> Message-ID: > On 13 Jul 2016, at 12:21, Max wrote: > Hi all, > After looking at the code, I don't think reusing table implementation > would be easy - the approaches are too different as well as underlying > data structures. okay. then we will need to use the tree based version and from my point of view we should do it the following way: * Remove osmo_t4_decode (and related routines) from libosmocore (last step) * Make the tree based decoder ready in terms of the surrounding style * Adopt/Clone the osmo_t4_decode tests and move them to the PCU (as part of the commit that adds the decoder to the PCU) @Me: After the infrastructure is in the PCU I will remove osmo_t4_decode (and tests) from libosmocore @Radisys: I am afraid the tree based decoding is not ready yet and as it impacts the upcoming encoder (and other RLE code as far as I understand) let me put it here. In osmo-pcu (and all other projects) we use libtalloc for memory allocations. This means the tree should use talloc with proper parent/child allocations. This way the destructor of the decoder will also free all nodes of the tree. There should be no call to malloc/free in the PCU. Please take the tests from libosmocore and make sure they work with the new decoder. Tests are the lifeline and we need more and not less of them. The decoder needs to be robust against invalid input. search_runlen can fail but the caller doesn't check for that. Please test with invalid/truncated or broken inputs to see we don't end in a never terminating while loop. Test using unit tests. Similar the current osmo_t4_decode can return an error that is propagated back to the compressed bitmap decoding and we should have the same. Reduce code duplication. With the decoder the only difference between the if/else is if the data is filled with 0x00 or 0xFF and which table/root to use. Instead of having code clones please parameterize either by having local variables in the beginning or by calling different (inline) functions. kind regards holger From Saurabh.Sharan at radisys.com Fri Jul 15 14:25:20 2016 From: Saurabh.Sharan at radisys.com (Saurabh Sharan) Date: Fri, 15 Jul 2016 14:25:20 +0000 Subject: [EGPRS] Performance results for EGPRS test in Radisys lab Message-ID: Hello, We have completed first phase of performance test on EGPRS using iperf tool for short duration runs (1 to 3 hours). Steady throughput of 215 to 223 kbps in Downlink has been achieved under lab conditions over the air test using one Huawei E398 dongle as UE. PCU was configured for 4 PDTCH allocation. Osmo-pcu is based on master branch plus Radisys code changes which are currently under Gerrit review. The execution of test was done on NuRAN 1.0 hardware. Below is a summary of test results Test type MCS DL Duration Throughput(kbps) Achieved Theoretical TCP MCS9 1hour 217 236.8 UDP MCS9 3hour 223 236.8 Regards Saurabh From msuraev at sysmocom.de Fri Jul 15 16:25:13 2016 From: msuraev at sysmocom.de (Max) Date: Fri, 15 Jul 2016 18:25:13 +0200 Subject: access bts from pcu's L1 code Message-ID: <57890E69.7010303@sysmocom.de> Hi. While working on https://osmocom.org/issues/1531 I've found that I have to update BTS's configuration (see src/bts.cpp) from osmo-pcu L1 code (see src/osmo-bts-sysmo/sysmo_l1_hw.c). The problem is that the only thing I got in L1 is struct femtol1_hdl which have trx_no but that's about it. Is there a way to get pointer to BTS so I can call bts->set_ta() using trx_no? Or I shall somehow change interface for l1if_fd_cb() - that's where my function with new data is called from? -- Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From msuraev at sysmocom.de Tue Jul 19 09:44:45 2016 From: msuraev at sysmocom.de (Max) Date: Tue, 19 Jul 2016 11:44:45 +0200 Subject: signal quality in osmo-pcu Message-ID: <578DF68D.9010804@sysmocom.de> Hi. While looking at http://projects.osmocom.org/issues/1616 I've noticed that there seems to be no particular function which get signal quality info from dsp. At least looking at code around ENABLE_DIRECT_PHY have not enlightened me so far. The question is - how exactly signal quality is obtained from dsp (on hw with direct dsp access) to osmo-pcu. There is clear difference between l1if_pdch_req() and pcu_tx_data_req() on TX path but what's the equivalent for RX? -- Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From msuraev at sysmocom.de Wed Jul 20 16:50:24 2016 From: msuraev at sysmocom.de (Max) Date: Wed, 20 Jul 2016 18:50:24 +0200 Subject: PDTCH and PTCCH activation Message-ID: <578FABD0.9060300@sysmocom.de> Hi all. I've noticed in osmo-bts logs several messages from L1: 238:<0006> oml.c:689 (bts=0,trx=0,ts=2,ss=0) MPH-ACTIVATE.conf (PDTCH TxDL) 243:<0006> oml.c:689 (bts=0,trx=0,ts=3,ss=0) MPH-ACTIVATE.conf (PDTCH TxDL) 246:<0006> oml.c:689 (bts=0,trx=0,ts=2,ss=0) MPH-ACTIVATE.conf (PDTCH RxUL) 251:<0006> oml.c:689 (bts=0,trx=0,ts=4,ss=0) MPH-ACTIVATE.conf (PDTCH TxDL) 254:<0006> oml.c:689 (bts=0,trx=0,ts=3,ss=0) MPH-ACTIVATE.conf (PDTCH RxUL) 260:<0006> oml.c:689 (bts=0,trx=0,ts=7,ss=0) MPH-ACTIVATE.conf (PDTCH TxDL) 263:<0006> oml.c:689 (bts=0,trx=0,ts=4,ss=0) MPH-ACTIVATE.conf (PDTCH RxUL) 274:<0006> oml.c:689 (bts=0,trx=0,ts=7,ss=0) MPH-ACTIVATE.conf (PDTCH RxUL) Similarly, there are messages related to PTCCH: 257:<0006> oml.c:689 (bts=0,trx=0,ts=2,ss=0) MPH-ACTIVATE.conf (PTCCH TxDL) 266:<0006> oml.c:689 (bts=0,trx=0,ts=3,ss=0) MPH-ACTIVATE.conf (PTCCH TxDL) 277:<0006> oml.c:689 (bts=0,trx=0,ts=4,ss=0) MPH-ACTIVATE.conf (PTCCH TxDL) 288:<0006> oml.c:689 (bts=0,trx=0,ts=7,ss=0) MPH-ACTIVATE.conf (PTCCH TxDL) Notice that while PDTCH is activated for both UL and DL, the PTCCH is only activated for DL. As far as I've understood continuous TA procedure I've got to have PTCCH activated in both directions. The problem is that I have troubles locating the code which triggers the activation above. There is l1if_connect_pdch() in osmo-pcu src/sysmo_l1_if.c but it uses GsmL1_PrimId_MphConnectReq while if I understood correctly GsmL1_PrimId_MphActivateReq is necessary for channel activation. There is mph_send_activate_req() in osmo-bts oml.c which uses it. It's called from lchan_act_compl_cb() via sapi_queue_send() which is also in mph_send_activate_req() - I have hard time understanding how this works at all. Do we have this documented somewhere? -- Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From laforge at gnumonks.org Thu Jul 21 06:14:37 2016 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 21 Jul 2016 08:14:37 +0200 Subject: signal quality in osmo-pcu In-Reply-To: <578DF68D.9010804@sysmocom.de> References: <578DF68D.9010804@sysmocom.de> Message-ID: <20160721061437.GS6258@nataraja> Hi Max, On Tue, Jul 19, 2016 at 11:44:45AM +0200, Max wrote: > The question is - how exactly signal quality is obtained from dsp (on hw > with direct dsp access) to osmo-pcu. The primitives received from the DSP in the sysmoBTS products are not any different on the PCU side than on the BTS side. It's a DATA-indication (GsmL1_PhDataInd_t), and that in turn contains a GsmL1_MeasParam_t member, which has * RSSI * burst Timing * link quality * BER see http://git.sysmocom.de/sysmo-bts/layer1-api/tree/include/gsml1prim.h for more infoformation. > There is clear difference between l1if_pdch_req() and > pcu_tx_data_req() on TX path but what's the equivalent for RX? I'm not quite sure how the transmit path should ever relate to signal quality measurements? -- - 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 Thu Jul 21 06:50:01 2016 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 21 Jul 2016 08:50:01 +0200 Subject: PDTCH and PTCCH activation In-Reply-To: <578FABD0.9060300@sysmocom.de> References: <578FABD0.9060300@sysmocom.de> Message-ID: <20160721065001.GT6258@nataraja> Hi Max, On Wed, Jul 20, 2016 at 06:50:24PM +0200, Max wrote: > Notice that while PDTCH is activated for both UL and DL, the PTCCH is > only activated for DL. > > As far as I've understood continuous TA procedure I've got to have PTCCH > activated in both directions. The problem is that I have troubles > locating the code which triggers the activation above. from osmo-bts/src/osmo-bts-sysmo/oml.c: static const struct sapi_dir pdtch_sapis[] = { { GsmL1_Sapi_Pdtch,?????GsmL1_Dir_TxDownlink }, { GsmL1_Sapi_Pdtch,?????GsmL1_Dir_RxUplink }, { GsmL1_Sapi_Ptcch,?????GsmL1_Dir_TxDownlink }, { GsmL1_Sapi_Prach,?????GsmL1_Dir_RxUplink }, #if 0 { GsmL1_Sapi_Ptcch,?????GsmL1_Dir_RxUplink }, { GsmL1_Sapi_Pacch,?????GsmL1_Dir_TxDownlink }, #endif I don't know exactly why it is commented out, probably because itw as simply not used at the time? -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From msuraev at sysmocom.de Thu Jul 21 08:38:23 2016 From: msuraev at sysmocom.de (Max) Date: Thu, 21 Jul 2016 10:38:23 +0200 Subject: PDTCH and PTCCH activation In-Reply-To: <20160721065001.GT6258@nataraja> References: <578FABD0.9060300@sysmocom.de> <20160721065001.GT6258@nataraja> Message-ID: <579089FF.6030202@sysmocom.de> This code is not referenced anywhere. On 07/21/2016 08:50 AM, Harald Welte wrote: > Hi Max, > > On Wed, Jul 20, 2016 at 06:50:24PM +0200, Max wrote: > >> Notice that while PDTCH is activated for both UL and DL, the PTCCH is >> only activated for DL. >> >> As far as I've understood continuous TA procedure I've got to have PTCCH >> activated in both directions. The problem is that I have troubles >> locating the code which triggers the activation above. > from osmo-bts/src/osmo-bts-sysmo/oml.c: > > static const struct sapi_dir pdtch_sapis[] = { > { GsmL1_Sapi_Pdtch,?????GsmL1_Dir_TxDownlink }, > { GsmL1_Sapi_Pdtch,?????GsmL1_Dir_RxUplink }, > { GsmL1_Sapi_Ptcch,?????GsmL1_Dir_TxDownlink }, > { GsmL1_Sapi_Prach,?????GsmL1_Dir_RxUplink }, > #if 0 > { GsmL1_Sapi_Ptcch,?????GsmL1_Dir_RxUplink }, > { GsmL1_Sapi_Pacch,?????GsmL1_Dir_TxDownlink }, > #endif > > I don't know exactly why it is commented out, probably because itw as > simply not used at the time? > -- Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From msuraev at sysmocom.de Thu Jul 21 08:50:43 2016 From: msuraev at sysmocom.de (Max) Date: Thu, 21 Jul 2016 10:50:43 +0200 Subject: PDTCH and PTCCH activation In-Reply-To: <579089FF.6030202@sysmocom.de> References: <578FABD0.9060300@sysmocom.de> <20160721065001.GT6258@nataraja> <579089FF.6030202@sysmocom.de> Message-ID: <57908CE3.10504@sysmocom.de> See https://gerrit.osmocom.org/#/c/556/ - I've removed it and tested osmo-pcu: as expected gprs works just fine without it. So it got to be someplace else. On 07/21/2016 10:38 AM, Max wrote: > This code is not referenced anywhere. > > On 07/21/2016 08:50 AM, Harald Welte wrote: >> Hi Max, >> >> On Wed, Jul 20, 2016 at 06:50:24PM +0200, Max wrote: >> >>> Notice that while PDTCH is activated for both UL and DL, the PTCCH is >>> only activated for DL. >>> >>> As far as I've understood continuous TA procedure I've got to have PTCCH >>> activated in both directions. The problem is that I have troubles >>> locating the code which triggers the activation above. >> from osmo-bts/src/osmo-bts-sysmo/oml.c: >> >> static const struct sapi_dir pdtch_sapis[] = { >> { GsmL1_Sapi_Pdtch,?????GsmL1_Dir_TxDownlink }, >> { GsmL1_Sapi_Pdtch,?????GsmL1_Dir_RxUplink }, >> { GsmL1_Sapi_Ptcch,?????GsmL1_Dir_TxDownlink }, >> { GsmL1_Sapi_Prach,?????GsmL1_Dir_RxUplink }, >> #if 0 >> { GsmL1_Sapi_Ptcch,?????GsmL1_Dir_RxUplink }, >> { GsmL1_Sapi_Pacch,?????GsmL1_Dir_TxDownlink }, >> #endif >> >> I don't know exactly why it is commented out, probably because itw as >> simply not used at the time? >> -- Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From msuraev at sysmocom.de Thu Jul 21 09:14:42 2016 From: msuraev at sysmocom.de (Max) Date: Thu, 21 Jul 2016 11:14:42 +0200 Subject: PDTCH and PTCCH activation In-Reply-To: <20160721065001.GT6258@nataraja> References: <578FABD0.9060300@sysmocom.de> <20160721065001.GT6258@nataraja> Message-ID: <57909282.7080109@sysmocom.de> Doh, my bad - I've looked into osmo-pcu instead of osmo-bts. You're absolutely right, thanks! On 07/21/2016 08:50 AM, Harald Welte wrote: > Hi Max, > > On Wed, Jul 20, 2016 at 06:50:24PM +0200, Max wrote: > >> Notice that while PDTCH is activated for both UL and DL, the PTCCH is >> only activated for DL. >> >> As far as I've understood continuous TA procedure I've got to have PTCCH >> activated in both directions. The problem is that I have troubles >> locating the code which triggers the activation above. > from osmo-bts/src/osmo-bts-sysmo/oml.c: > > static const struct sapi_dir pdtch_sapis[] = { > { GsmL1_Sapi_Pdtch,?????GsmL1_Dir_TxDownlink }, > { GsmL1_Sapi_Pdtch,?????GsmL1_Dir_RxUplink }, > { GsmL1_Sapi_Ptcch,?????GsmL1_Dir_TxDownlink }, > { GsmL1_Sapi_Prach,?????GsmL1_Dir_RxUplink }, > #if 0 > { GsmL1_Sapi_Ptcch,?????GsmL1_Dir_RxUplink }, > { GsmL1_Sapi_Pacch,?????GsmL1_Dir_TxDownlink }, > #endif > > I don't know exactly why it is commented out, probably because itw as > simply not used at the time? > -- Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From nhofmeyr at sysmocom.de Thu Jul 21 10:25:25 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 21 Jul 2016 12:25:25 +0200 Subject: PDTCH and PTCCH activation In-Reply-To: <578FABD0.9060300@sysmocom.de> References: <578FABD0.9060300@sysmocom.de> Message-ID: <20160721102525.GA10843@ass40.sysmocom.de> On Wed, Jul 20, 2016 at 06:50:24PM +0200, Max wrote: > It's called from lchan_act_compl_cb() via sapi_queue_send() which is > also in mph_send_activate_req() - I have hard time understanding how > this works at all. Do we have this documented somewhere? Both the TCH/F_TCH/H_PDCH timeslot feature and the TCH/F_PDCH on osmo-trx are stuck on some post-lchan_act_compl SAPI stuff. So, I would also benefit from better understanding the actions after lchan_act. Apparently related: libosmocore/gsm/lapd*.c ~Neels -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From msuraev at sysmocom.de Thu Jul 21 11:22:14 2016 From: msuraev at sysmocom.de (Max) Date: Thu, 21 Jul 2016 13:22:14 +0200 Subject: [EGPRS] Performance results for EGPRS test in Radisys lab In-Reply-To: References: Message-ID: <5790B066.8090000@sysmocom.de> Thanks for sharing the results. What about MCS UL? Do you have some statistics which one has been used and if it has changed during the test? Same question regarding the throughput etc. On 07/15/2016 04:25 PM, Saurabh Sharan wrote: > Hello, > We have completed first phase of performance test on EGPRS using iperf tool for short duration runs (1 to 3 hours). > Steady throughput of 215 to 223 kbps in Downlink has been achieved under lab conditions over the air test using one Huawei E398 dongle as UE. > PCU was configured for 4 PDTCH allocation. > Osmo-pcu is based on master branch plus Radisys code changes which are currently under Gerrit review. > The execution of test was done on NuRAN 1.0 hardware. > > Below is a summary of test results > Test type MCS DL Duration Throughput(kbps) > Achieved Theoretical > TCP MCS9 1hour 217 236.8 > UDP MCS9 3hour 223 236.8 > > Regards > Saurabh -- Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From Saurabh.Sharan at radisys.com Fri Jul 22 12:30:09 2016 From: Saurabh.Sharan at radisys.com (Saurabh Sharan) Date: Fri, 22 Jul 2016 12:30:09 +0000 Subject: [EGPRS] Performance results for EGPRS test in Radisys lab Message-ID: Hello Max, > What about MCS UL? Do you have some statistics which one has been used The uplink tests have been completed for all EGPRS coding scheme (MCS1 - 9) using the ping or TCP download. We have not conducted specific test for throughput estimation in uplink direction till now. Regards Saurabh