Hi Alexander, On Sun, Jul 22, 2012 at 10:42:43AM +0400, Alexander Chemeris wrote: 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 <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

Hi Alexander. On Sun, Jul 22, 2012 at 01:10:01PM +0400, Alexander Chemeris wrote: 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 <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

Alexander Chemeris wrote: 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

On Sun, Jul 22, 2012 at 5:29 PM, Holger Hans Peter Freyther <hfreyther(a)sysmocom.de> 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. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ООО УмРадио http://fairwaves.ru

Hi Holger, On Mon, Jul 23, 2012 at 9:12 AM, Holger Hans Peter Freyther <hfreyther(a)sysmocom.de> wrote: 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. 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

On Sun, Jul 22, 2012 at 03:29:38PM +0200, Holger Hans Peter Freyther wrote: Hi Jolly, any comments? It is an absolute requirement to be able to test this code. holger -- - Holger Freyther <hfreyther(a)sysmocom.de> 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

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 <hfreyther(a)sysmocom.de> 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

On Wed, Jul 25, 2012 at 08:53:50AM +0200, jolly wrote: 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 <hfreyther(a)sysmocom.de> 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