Report

Another draft had been delivered and the figures to the report were drawn. Lastly the used books information were collected for the bibliography.

With a bit time - Reason for increased delay

Minor time had been used to start searching for the reason of the increased delay. However no result is found. During the search the software was improved by using a real time like scheduling algorithm (Round Robin, with higher priority). Also a way to gather the timestamp from the kernel, instead of recording the time the packet arrived at the test software was found and implemented.
Finally a short calculation had been done, if 18.2 ms increase is in 1 minute and it is assumed, that the clocks go different, than this means 5,5 Minutes difference in one Month or while one clock maesures 1 minute the other is still at 59982 ms.
A positive point toward this theory would be the experiences of the OpenH323 programmers, who had a frequently click in the jitter buffer, which was caused by one process puttin each 29/30ms something in, while another each 30/31ms something removed - hence over a long period a buffer underrun for a very short period occurs...
As at the moment I do not know a very quick test setup for measuring if there is a clock difference (on the accuracy of ms), I postbone this.

The End

At the end some ideas about continuing of this project.

Personal

I personally, if I am staying in the VoIP area, will try to remove the increase delay problem and make the software (running on a ordinary PC) as accurate for measurements as possible, then I believe this is a very good tool to confirm improvements in queueing algorithms and the capability of a QoS network. As I would like to stay in the VoIP area maybe the software could be used as a testing tool of other work I might do...

Seen from point of view of my supervisor

As one of the targets could be the final employment of VoIP in a real Wireless Local Loop network. One step could be to install a outdoor link between Kevin street and Aungier street (or other location nearby of the DIT). With the cards, baught during the project, the Link could be connected to a small telephone system (maybe 2 telephones on each side (using 2x phonejack, 2x line jack) or a small analog PABX (using 2x linejack)). This link could be used to test the real live behaviour of the WLL equipment and the needed out door antennas. As the PC acting as the gateways, could route also PC (netmeeting) traffic into the wireless link a scaling to higher number of simultanious conversations could be possible. However I advise not to route the IPX traffic onto the wireless link, as this will decrease the performance significantly. This means if connecting the access point to the DIT LAN, the tunnel IPX option from the local terminal adapter menu needs to be switched off.
Another more into VoIP area belonging continuation would be to estable in one project, a QoS wired network or at least record parameters of the wired network and in another project develop QoS capabilities for the wireless network and compare the then measured values with the one of the wired system.