+Intro
+Prephase
+TimePlan
+Outline
+Research Phase
+-28 Feb.-
+-5 Mar.-
+-12 Mar.-
+-Odysee
+-19 Mar.-
+-26 Mar.-
+- > 2 Apr.-
+Develope Tests Spec.
+- 9 Apr.-
+Test Phase
+- 16 Apr.-
+- 23 Apr.-
+- 30 Apr.-
+Review Results
+- 7 May.-
+Prep. Report
+- 14 May.-
+- 21 May.-
+After Project
About writing the software
A first structure is given with this image. It shows
how the different objects may be ordered and what objects are
needed. I also tried to analyze where difficulties could be (color red)
and where I know how to solve the problem, just haven t spent time on it
(color turkis). A dataflow is also shown. Altogether this draft helped
me to order my ideas about the software.Researching again - for writing the software
Deciding to write an own software didn t end my times in the library. I needed to find out about common ways to measure the desired parameters, best in terms of source code examples. Also the internet was usefull, but as I already knew, that no jitter and good delay measuerment software is avaible I concentrated on conference papers and research literature.Sideways the road - Network testing generally
Finding helpful information wasn t straight forward, but sometimes the side information is also worth mentioning. A book dealing with network testing, mentioned the reasons for testing a network. This especially could be usefull for a network administrator needing to conveince buisness people to open a test budget. This are the following:- Application Response time
- Important as this could be seen as the time the User can work
- Application Feature/ Functionality testing
- Important to test applications under heavy load and unorthodox input sequences
- Regression Testing
- Compares the new release of hardware or software with the actually used one. Important for preventing chaos in forehand.
- Throughput
- Is used to find bottlenecks, compare different products and components of the network
- Acceptance
- Similar to regression, but emphasizing on real production enviroment.
- Configuration Sizing
- Using the other testresults and repeating tests with different configurations the administrator gets to know the product before he needs to know it (means before he needs to adjust the configuration, because of errors or bottlenecks). Doing configuration sizing on a real network could cause unneeded down times and chaos.
- Reliability
- Seen from the perspective of time. The main part is to monitor the test for a longer period ( > 24hours) and detirmine problems afterwards
- Product Evaluation
- Today not only the pure figures of maximal users or throughput are important, but also the used underlying technology. A good example was the novell netware system, using IPX and beside file sharing and printer service not supporting services like VoIP,HTTP or email. Employing a very good Novell server did mean mixing the network protocolls IPX and TCP/IP, causing some NT servers in earlier time to interesting behaviour. Also the network devices (especially with managements functions) need to be capable of two different protocols. In this case product evaluation would include technology evaluation as well.
- Capacity Planing
- Determine the needed capacities and keep a buffer for later - this could mean buy know a more expensive equipment, but save later a reinvestment into the network. Sadly a computer network never is finished... also the point, taking today something cheap, while later in an expensive comprehensive reinvestment the whole structure will be changed, is worth concerning.
- Bottleneck identification and Problem Isolation
- Probably this is the one mostly connected to testing.
More about the software
Sources for information aobut how to write the sofware were:- The internet especially avaible sources of GNU software
- RFC 2043 ( A standard of network testing)
- Books and talks about Markov Chains (to get an idea for the timing generator)
- ...to be completed after finish of the software...
Changelog of the sofware
For further documentation of my work I like to include the ChangeLog, which I write at every program I am doing. My personal version even includes versions of the future for having a kind of roadmap and concrete targets to aim at.Version 0.3 Going forward to get all functionallities New: * The timermatrix is now calculated using random numbers and transition probabilities. * timermatrix will be transmitted to server at start (and tcp does give no guaranty of one piece delivery ...) * with the timermatrix it is possible to specify a testperiod time Version 0.2 The Basics are working. Now implement functionality New: * Results will be send from server to client at end of testses * Session parameters will be transmitted to server at start * Syncronizing is nearly finished. I record the one way latency, but for now I only change the systemclock, better would be to implement a adjust routine, without changing system parameters !#! * The sender is sheduled now (send and silent periods fixed) * BER, delay, jitter and packetloss recording Version 0.1 Just get it going, get a TCP, UDP session and show that data is transmitted New: * First big step forward was putting receiver and sender in own processes * Parent receives results from receiver (child) at end of tests