Shortcomings

The developed application strives to be true to the design in the previous chapter. However, there are some things that could not be completed and must be addressed. The implications of these shortcomings will be evaluated in Chapter 6.

The first and most substantial shortcoming is the lack of state information in the WCDMA information. This State-parameter is described in section 2.2.6 and would show us which kind of neighbors we have. These different kinds of WCDMA neighbors can be either Active Set, Monitored Neighbor or

32 CHAPTER 5. RESULTS Detected Neighbor and supplies the user with more extensive information about the system. In GSM systems this parameter is not applicable since we only have one neighbor belonging to the would-be Active Set, namely the neighbor we are communicating with.

The signal quality indicator for GSM, RxQual, is also not available. This means that we cannot perform accurate signal quality analysis, but as mentioned in section 2.1.5 this is not as important as in the WCDMA case. The implications of this short coming will be evaluated in Chapter 6.

The last substantial shortcoming that the application suffers from is associated with the GPS hardware. The subsystem is only able to supply us with location updates once every second. Since the final output is a merge consisting of network data from the network data gatherer module and the location data from the GPS location acquisition module we could potentially get output files with several entries with the same GPS location data.

Chapter 6

Evaluation

In this chapter I will evaluate the resulting application presented in Chapter 5. Whether or not the application is able to cope with the performance requirements and deliver results at a satisfying rate and whether or not the presented data is relevant will be evaluated. The applications memory foot print will be evaluated in section 6.1 and the CPU performance will be evaluated in section 6.2. Furthermore in section 6.3, the data that has been collected by the application will be evaluated and compared with the theoretical background provided in Chapter 2.

6.1

Memory

Most modern cellular phones in the mid to upper price range come with plenty of available internal resources. However, the high processing needs of the complex Symbian OS might result in that we still see that we do not have enough memory for the application. In this section both memory allocated to the stack of the application and the global heap memory will be evaluated.

6.1.1

Stack

In its original design the application uses TBuf-descriptors1to save information from the network data gatherer and the GPS modules. The TBuf is always allocated to the application stack and so if we have larger entries that we want to write to file through the usage of TBuf descriptors we are naturally going to need more stack space. The collected data is however written to file every second so there is not going to be so much information that needs to be stored on the stack.

How much stack memory that is available to the application can be set in the project settings file. Symbian programming paradigms advises to not use more stack memory than one thinks one will need. The way it works in the settings file is that a minimum and a preferred maximum value is set, and the operating system will try to provide that to the application. If the entire memory indicated by the preferred maximum value is not used that memory can 1_{A Symbian C++ string-like type that contains a string with a fixed length, hence not} zero-terminated

34 CHAPTER 6. EVALUATION still be used by other applications. This fairness amongst different applications is an important factor for keeping Symbian OS applications running smoothly. The default stack size is 8KB, even though it is encouraged to increase this to 20KB[21]. The maximum stack size per process is 20MB.

The minimum amount of stack memory that is needed for running the application without complications is 30,000 bytes. The results of different stack sizes are showed in Table 6.1. Note that when starting the application with less than 30,000 bytes it will not be able to load secondary screens correctly. This means that when changing tabs a Symbian TRAP message will be sent and the Symbian OS will advise to close some applications in order to free memory.

Table 6.1: Memory usage for different components in the stack, in bytes Stack size (bytes) Implication

10,000 Memory full. Application cannot start.

25,000 Normal startup of application. Not enough memory

to change to second screen. Savings does not work. 27,500 Normal startup of application. Enough memory to go

to second screen, but not third. Saving does not work. 28,500 Still not able to go to third screen, but saving works

normally.

30,000 Application runs normally.

The application is going to need more available stack memory if more information is stored in each entry or if several entries are pushed to the stack before writing them to file. But the default stack size of 8KB is evaluated to be sufficient for this application in normal operation.

6.1.2

Heap

The available amount of heap memory is configured similarly to the stack memory in the project configuration file. One can choose how much global heap memory one would prefer to have dedicated to the application, but the Symbian OS will distribute the memory to the different running applications. In later versions of Symbian OS there is no upper maximum limit to how much global heap memory the application can request.

Since the stack is not meant to contain large entities of data it is preferable to use TBufC descriptors. These can be allocated on the heap with a configurable size and as long as the application has remaining eligible memory on the heap it can continue to allocate new TBufC descriptors.

In the RAT-UE application this is not applicable to a great extent in its original design since all data entities are handled on the application stack. But for the sake of evaluation the entities will be saved to the heap in order to see if it is favorable.

The amount of memory that needs to be allocated for all entries to be saved is:

Heapsize = entrysize ∗ N (6.1)

where entry size is variable and N is the number of entries to be stored on the heap.

6.2. CPU 35 The amount of memory that needs to be allocated for each TBufC descriptor is directly dependent on many entries that are going to be saved. In the original design this is equal to the previously used TBuf. But in this evaluation it has been tested with up to 10,000 entries. This has been evaluated to work properly. Further evaluation of saving many entries to the heap before writing them to file is handled in section 6.2.3.

The default size for the heap in Symbian applications is 1MB, but this naturally has to be increased if as many as 10,000 entries have to be saved.

6.2

CPU

The cellular phone that deploys the application has to be able to deliver a reasonable amount of processing capability. In its original design the network data gatherer and the GPS module collects one entry each second and the application appends the result to a file. In this evaluation I will test to see how the network data gatherer behaves under stress and if it can sustain a harder processing demand. The GPS module will also be evaluated in section 6.2.2. Finally in section 6.2.3 I will test to see whether or not it is favorable to keep a number of entries in memory before writing to file to save overhead.