omotoye / arp_assignment_1

Advanced Robot Programming Assignment

Designed By Omotoye Shamsudeen Adekoya

Documentation for the ARP Assignment 1

Outline

1--> Design Choices
2--> How to Compile
3--> Result Discussion

                                 _____________________
                                 |  DESIGN CHOICES    |   
                                 ---------------------
                                 
                                       [G1]
                                           \
                                            \
                                             \[R]------>[M]
                                             /
                                            /
                                           /
                                       [G2]     

*In the program, two generator processes G1 and G2 are supposed to generate quasi periodic messages to send to 
 process R. Process R will then computed the message and send it to process M for Outputing, making process M the 
 last process to terminal. It is for this reason that i have chosen process M to be the Master Process. The 
 process M then forks a child process which represents the process R, process R forks process G1 and process G1
 forks process G2. The process tree looks something like this (M)--->(R)--->(G1)--->(G2).
*For the pipes, in the unnamed pipe version, three unammed pipes are created in the M process and the file 
 descriptors required by each of the processes are then passed down the heirarchy during the exec process as 
 command line arquments. In the Named pipe version, the only change from the previous architecture is the 
 communication between the Gi processes and the R process. Instead of using two unnamed pipes for the 
 communication, one named pipe was created at the R process and then open for READ_ONLY, the created 
 FIFO(Named Pipe) was opened by each of the Gi processes for WRITE_ONLY.
*Another thing to note is that the process computes its time in microseconds and after 1000000 microseconds
 its 1 second then the microseconds starts from 1 again. The program is going to run for well over 1 second
 which means multiple cycle of microseconds. This has to be watched out for in the latency, offset delay and
 Bandwidth computation. My solution to this is a conditional statement that checks if creation time is higher than 
 reception time. If this is TRUE it means another cycle just started and the difference in time will be calculated 
 as difference = (1000000 - creation_time) + reception time 
*How the program will run: the program will print each message received from the R process in the format
 "The message %d from %c was created at %ld and received at %ld\n", where %d is for the sequence number of
 the message, %c is a char identifying the message, and %ld is for the timestamp of the message. 
 Initially i left the print out of the program, and put just a single print statement that prints, "please wait
 while the program computes", but the program takes a while to finish so i thought it would be a good idea to 
 have a feedback while the program is running so you know the program is working. 
 After the loop is done and all the message has been received and computed by the R process, the R process 
 then sends a kill signal to the G1 process which has a signal handler to handler the sigkill signal, in the 
 handler function of the G1, there are two statements one sends a kill signal to kill the child process which 
 is G2 and the other kills the current pid which is itself.
 After the signal has been handled the R process sends all the computed data to the M process through a pipe
 by the way of struct and the M process does some extra work on the data and Outputs it. This means when you
 run the program you'll see a lot of messages generated and after that the M_process then output the final 
 computation of all the messages. The M process also keeps a log of the computed output, the messages generated 
 is not included in the log file, only the final output is logged.

                                
                                _______________________
                                |   HOW TO COMPILE    |
                                -----------------------

---> to compile the M_Process.c
gcc M_Process.c      (this will save the executable as a.out, which is ok since it's the master process)
---> to compile the receiver.c 
gcc receiver.c -o receiver (the naming of the file MUST NOT BE CHANGED, this is because the executable will
be exec from it's parent process with this name, if the name changes, exec will fail!!!)
---> to compile the generator_1.c 
gcc generator_1.c -o generator_1 (same rule apply)
---> to compile the generator_2.c
gcc generator_2.c -o generator_2 (same rule apply)

run ./a.out  and the process will start execution 

                                _____________________________
                                |    RESULT DISCUSSION      |
                                -----------------------------   
---> Unnamed Pipe Version
Three test was done for different timeout conditions and their average was taken

* test with Gi offset = 10, select timeout = 1, timeout if no data = 10
-> total offset delay in G1: 70000000(microseconds) same for G2 
-> latency: 55
-> Bandwidth: 310000(bit/s)

* test with Gi offset = 10, select timeout = 5, timeout if no data = 20
-> total offset delay in G1: 75000000(microseconds) same for G2 
-> latency: 140
-> Bandwidth: 110000(bit/s)

* test with Gi offset = 20, select timeout = 1, timeout if no data = 10
-> total offset delay in G1: 80000000(microseconds) same for G2 
-> latency: 45
-> Bandwidth: 400000(bit/s)

* test with Gi offset = 20, select timeout = 5, timeout if no data = 20
-> total offset delay in G1: 85000000(microseconds) same for G2 
-> latency: 60
-> Bandwidth: 250000(bit/s)

---> Named Pipe Version
Three test was done for different timeout conditions and their average was taken

* test with Gi offset = 10
-> total offset delay in G1: 450000000(microseconds) same for G2 
-> latency: 25
-> Bandwidth: 700000(bit/s)

* test with Gi offset = 20
-> total offset delay in G1: 470000000(microseconds) same for G2 
-> latency: 22
-> Bandwidth: 750000(bit/s)


                          ****** Discussion *********

From the above result, the version with the Named pipe has a significantly higher Bandwidth than 
any of the versions of the Unnamed pipe but falls short in the delay, it take x5 times longer to 
receiver all the messages as compared to the version with Unnamed pipe because of the high delay
from working with different process through one channel. 
Another point to discuss is the effect of the changes in timeout. The higher the wait time when 
no data is available the higher the latency, but it all depends on the offset delay from the 
generators, if the offset delay in the generator is high enough to compensate for the timeout delay
then the latency will be reduced significantly.

                          ******** Conclusion ********** 

The version with the single Named pipe will be best suited for a system that require very 
quick response to a process

The version with the multiple Unnamed pipe will be best suited for a system that requires 
a simultaneous response to high number of processes.






You can now find this project on my GitHub page that i wil add here later :)
I want to make a change so i can test out my git status code

More random thing to be added just to check the diff command if it also print
changes from more than one file