Part I

1. When the event that you are timing is small, it is sometimes a good idea to run the event many times, and time the whole operation instead of timing just one event. For example, you could have opened a connection, sent data, and closed a connection in a loop, and then time the whole loop. You can then divide the time you measure by the number of loop iterations to get an estimate of how long one iteration takes. Of course, you still have to run the whole experiment (of timing the loop) several times, to ensure that you have enough samples.
2. You needed to use /usr/bin/time in order to get the real time, the user time and the system time. Using something like gettimeofday(), or gethrtime() will only give you the real time, which is the total elapsed time from the beginning of execution to the end. This also includes the time that your process is blocked and sleeping. Using gettimeofday() or gethrtime() you have no simple way of determining how much time the process has spent in the running state. This is why you needed to use /usr/bin/time.
3. You should give a table with your results. As an example, the table for question 1 can be as simple as this (note that units are important, and the title should also be clear and precise):

   	Real (units)	User (units)	System (units)
   First run
   Second run
   Third run
   ...
   n'th run
   Average
   Std. deviation

   
   Table 1: Real, User and System time for sending data through TCP

   You would need one table for TCP and one for UDP, or you can combine them. Putting the standard deviation is not a must, but it's nice because it shows how close together or far apart your results are.

4. You were asked to explain the difference in wall time between the TCP and UDP processes. The answer is that the discrepancy is due to the extra network overhead in the system calls associated with TCP, in particular, the connection setup time (all of which takes place while the process is blocked). Since this overhead incurs only a trivial amount of extra CPU cycles, only the total time goes up, not system or user time. It was not sufficient to simply say that there is an overhead involved in TCP, since an overhead usually implies more CPU usage. It's the fact that the TCP process is blocked during this overhead that explains the discrepancy.

Part II

This part was generally well done. Look at the comments in your marking sheet for details.