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

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

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

On Sun, Jul 22, 2012 at 5:29 PM, Holger Hans Peter Freyther hfreyther@sysmocom.de 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.

Hi Holger,

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

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

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

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