Workload on the Network

Besides the readability of the QR code, difficulties with the WiFi network were identified. As one of the specifications was to avoid setting up a dedicated network, all devices had to use the existing university WiFi network or the data network of a mobile network

Chapter 5. Evaluation

provider. Unfortunately, the WiFi network at the university was not designed to serve more than a hundred parallel data connections within one room at that time. Therefore, it was one of the first topics of interest to survey the network load and network delay. In a sample experiment, the network load caused by a single student using the Mo- bileQuiz was measured. Afterwards, the actual load in real classroom conditions was measured during a lecture with 139 students. After implementing the MobileQuiz2 and recognizing new performance issues, the measurements of the WiFi network traffic were repeated. We report the results below.

Workload in a Sample Study with the MobileQuiz

In this sample experiment, the network load caused by one student was measured in an isolated environment. The experiment was performed with the MobileQuiz and a quiz containing five questions with three possible answers each. The answers contained no pictures or other multimedia content. Figure 5.2 shows the network load for this quiz participant. The data download to the device caused about 240 kbits, which is represented by the high bar at the sixth second. The upload for submitting the answers caused about 100 kbits of traffic at second 15. Altogether, 340 kbits of network load arose for one participant. When inspecting the data, it could be recognized that the largest part of the downloaded data consisted of graphic symbols, which were used for the layout and the JQuery libraries.

After this measurement for one participant, the strain of the WiFi network was measured with the university WiFi network access points. While the quiz was used during a lecture where seven devices participated, the load on all nearby WiFi access points was measured for the whole lecture time. But the additional network traffic of these seven devices could not be recognized in the overall daily WiFi network traffic, it was absorbed by general traffic noise. The WiFi access points could handle up to 100 mbit/s, so even for more than 100 students the pure data load should not have been a limitation. Unfortunately, independent of the network load, the WiFi network delay increases with an increasing number of clients (see also Xiao [209]). Additional packets are needed to regulate the network traffic and to avoid packet collisions. This causes a noticeable packet overhead and increases the overall delay. But considering the small number of students in this sample test scenario, an impact on network delay could not be noticed.

Chapter 5. Evaluation

Workload in Classroom Study with the MobileQuiz

After the sample study described above the network load was tested in a larger classroom environment. The network load was measured a second time, with the university’s WiFi access points during a quiz round. But this time, a lecture was selected which was attended by 139 students. Figure 5.3 shows the amount of network data during the entire lecture time. Upload (blue) and download (red) were measured in megabits per second and arithmetically averaged over a frame of four seconds. The quiz took place from 10:36 to 10:41 and consisted of only one numeric question. 95 students participated, and 85 of them used the university’s WiFi network. The other ten students used the Internet access of their mobile phone network provider. At the time when the quiz started, the graph shows a peak up to 8 Mbit/s and then decreases to about 3 Mbit/s. When comparing this amplitude to the average network load during the whole lecture, the quiz can clearly be recognized. But regarding the maximum possible network load of 100 Mbit/s (IEEE 802.11n with MIMO) for our university’s WiFi, the maximum capacity of the WiFi network was not utilized. But as mentioned above, the WiFi network delay increases with an increasing number of clients, because additional packets are needed to regulate the network traffic and to avoid packet collisions. Even with about 85 students participating via WiFi, a significant impact on the network delay was not recognized. However, only quiz rounds with plain text questions were examined so far. When adding multimedia content, the network load would rise considerably.

Figure 5.3: Network load during a MobileQuiz usage in a lecture with a quiz at 10:36h.

The experiences show that the MobileQuiz application was feasible in practice and met its requirements. The measurements on the network load showed that the university’s WiFi infrastructure was sufficient; lectures with hundreds of students could be handled. The reason why ten students used the Internet connection of their mobile phone provider was not further investigated. Whether it was their default access option or if they had trouble connecting the university’s WiFi network could not be told.

Chapter 5. Evaluation

Network Load when Using the MobileQuiz2

The analyses with the MobileQuiz showed, that the network was no bottleneck. This observation was confirmed by several semesters in which the MobileQuiz was used dur-

ing actual lectures. Even in classrooms with more than a hundred of students, no

performance issues emerged. But this changed when lecturers started to use the new MobileQuiz2 . Depending on the scenario, huge performance delays could be observed, especially in lectures with a high number of participants. To identify the new bottle- necks, the network traffic was observed again. At first, it was measured directly on the Apache web server.

Figure 5.4 shows the number of server connections in a large exercise in the Fall semester 2015. It was a scenario of Question Phases with three phases; about 80 students par- ticipated. The three phases can easily be identified in the Figure by the peaks in the number of connections. The server’s configuration for the maximum number of connec- tions was set to 150. Unfortunately two separate connections were established for every participant although only one was actively used. During the third phase, the server became so busy that it wasn’t even able to log the connections any more, and it took about ten minutes to recover. Because the students complained about the huge delays, the lecturer canceled the quiz round at that point.

Figure 5.4: Server connections during a complex MobileQuiz2 scenario with a gap at 14:20h due to CPU overload.

When looking at the actual network traffic in Figure 5.5 the view slightly differs from the information above. In the first two phases, the network traffic rose up to 800 kilobytes/s, which describes the students’ activity as expected. But in the third phase, when the server got really busy, the actual network traffic at the server remained under 400 kilo- bytes/s and even decreased shortly before it got too heavy at 14:20. When considering this observation, the network load is less likely the most restraining bottleneck.

In search of the real bottleneck, the application logged delay times for the whole exe- cution process, which was described in detail in Section 3.4.5. This process was further divided into four steps:

Chapter 5. Evaluation

Figure 5.5: Network traffic on the server during a complex MobileQuiz2 scenario with a gap at 14:20h due to CPU overload.

• Time in the network.

• Time for processing the data.

• Time to gather the relevant data attributes for the student’s display. • Time to render the page with the new information on the student’s phone. The times were measured for different kinds of input actions, as displayed in Figure 5.6. The Figure shows the mean values of the measured times throughout several MobileQuiz2 quiz rounds. It could be observed that only a small amount of delay was caused by the network. Most of the delay was caused by data processing on the web server. The delays for gathering the information attributes or rendering the layout on the mobile devices were so small that they could almost be ignored. This suggests that the bottleneck has to be identified within the server’s data processing.

Chapter 5. Evaluation