Linux / Posix.4 Environment: Clock Resolution, Scheduling, Memory Locking, And Nanosleep

This assignment requires a working Linux / Posix.4 environment. You can use either your own setup (POSIX.4 is supported by all modern Linux kernels across all important distributions) or use the Linux VM in IT103.

POSIX Clock Resolution: Use the clock_getres system call to extract the clock resolution.

See posix_getres.c code example.

Comment on result, i.e. the importance of resolution in determining overall system performance and responsiveness.

Overview:

By default Linux/Unix implement a complex timesharing scheduling algorithm. The nice command allows you to give greater/lesser priority to certain processes but the underlying scheduler is still timesharing. Posix.4 provides realtime extensions to this, namely FIFO and Round Robin. This assignment will compare process runtimes using the standard Linux scheduler (along with nice) and the realtime extensions.

Part A: nice

• Implement a simple piece of code where the process runtime is measured e.g. similar to Ccode provided in the attachment. Ensure sleeptime argument is greater than resolution. Summarise the results, i.e. distribution of sleep times and the total process run time.

• Run a number of identical processes concurrentlyin different terminals and summarise results, i.e. you should see a changing distribution as no of parallel processes increases.

• Use the NICEcommand to give certain processes priority over the remaining similar processes. Note: NICE –N +VE is nice to other processes, NICE –N –VE is not and requires root access.

Example: NICE –N 10 TIMER 2 1000 runs executable timer with 2 msec sleep and 1000 iterations with nice value of +10. Repeat with different settings and analyse results.

• Note: The system monitor utility will give you ‘realtime’ graphical information on process priorities and how they are changing under the time sharing alg. In non-GUI environments you can use the top

• Implement the very same code but use the FIFO scheduling policy for one version. (Need to run as root). See cas an example. This code implements the process at the highest FIFO priority. Run this concurrently with other versions running under default timesharing policy i.e. timer_usleep.c. Summarise and analyse performance.

• Repeat part B above, but use code TIMERc.Compare with part B; the results should show benefits of FIFO much more clearly. If so, why?

Overview:

By default Linux/Unix use virtual memory with paging to run multiple processes with a memory size greater than available memory. This exercise will help you to understand the benefits of memory locking whereby a process is locked down in memory.

Part A:

• Implement a memory intensive piece of code where process runtime is measured (similar to cprovided). Run and analyse performance (an array of 10000000 floats take up approximately 40MB). As above, use a system monitor tool to get a feel for what’s happening with memory. Run a number of processes concurrently thus increasing the memory requirement until memory is being fully utilised and paging is a necessity. The command line VMSTAT utility allows you to look at the degree of paging going on. Increase number of concurrent processes until paging is occurring frequently and you can see significant changes in runtime. Summarise and analyse results.

Part B:

• Implement POSIX.4 memory locking (root access required) for one instance of code. See cprovided. Run this with other concurrent versions without memory locking (timer_mem_use.c) and increase number of these until paging is required. Be careful to start timer_memlock.c version first. Watch what is happening with memory. Summarise/ analyse performance.

• Compile and run the code c. Compare the code and the results with those from timer_usleep.c.

Problem 1: Clock Resolution

Use the clock_getres system call to extract the clock resolution.

See posix_getres.c code example.

Comment on result, i.e. the importance of resolution in determining overall system

performance and responsiveness.

The resolution value is returned in the clock_getres() system call to give application programmers an idea of the (in)accuracy of timers. Timer values are rounded up to this resolution values.

 

Figure 1: Clock Resolution : posix_getres.c

Without time synchronization, accurately correlating information among devices becomes very difficult, and almost impossible. When it comes to security, if you cannot successfully compare logs between each of your devices such as routers and all your network servers, you will find it very hard to develop a reliable picture of an incident. Again, even if you are able to put the pieces together, unsynchronized times, especially between log files, may give an attacker with a good attorney enough wiggle room to escape prosecution.

Part A: nice

Implement a simple piece of code where the process runtime is measured e.g.

similar to timer_usleep.c code provided in the attachment. Ensure

sleeptime argument is greater than resolution. Summarise the results, i.e.

distribution of sleep times and the total process run time.

usleep - suspends execution for microsecond intervals. The  usleep()  function  suspends execution of the calling thread for (at least) usec microseconds.  The sleep may be lengthened slightly by any system activity or by  the time spent processing the call or by the granularity of system timers.

The source code for this is as below:

#include<stdio.h>

#include<time.h>

#include <sys/time.h>

#include <sys/resource.h>

int main(int argc, char** argv)

{

struct timeval tv;

struct timezone tz;

int i,delay,num_iter;

double init,start,stop;

if (argc!=3)

{

fprintf(stderr, "Usage: %s <sleep time..msec><num_iteration>n", argv[0]);

exit(1);

}

// progname=argv[0];

delay=atoi(argv[1]);

num_iter=atoi(argv[2]);

printf("Delay is %d..num_iter is %dn",delay,num_iter);

gettimeofday( &tv,&tz);

init=tv.tv_sec + tv.tv_usec*0.000001;

for(i=0;i<num_iter;++i)

{

gettimeofday( &tv,&tz);

start=tv.tv_sec + tv.tv_usec*0.000001;

// Now sleep

usleep(delay*1000);

gettimeofday( &tv,&tz);

stop=tv.tv_sec + tv.tv_usec*0.000001;

printf("Time is %ld : %ld..slept for %lf msn",tv.tv_sec,tv.tv_usec,(stop-start)*1000);

}

printf("Total time taken : actual %lf theory(excl. runtime): %d, ms n",(stop-

init)*1000,num_iter*delay);

return 0;

}

Upon execution of the above code, the below screenshot is the running program.

 

Figure 2.1: Usleep – time_usleep.c

In Figure 2.1, demonstrates how usleep allocates execution time to processes by suspending execution of other processes by microseconds. In my case, running usleep with sleep time set to 100 resulted to “Total time taken : actual 18.857956 theory(excl. runtime): 0, ms”

Problem 2: Scheduling

Implement the very same code but use the FIFO scheduling policy for one

version. (Need to run as root). See timer_mod_FIFO.c as an example.

This code implements the process at the highest FIFO priority. Run this

concurrently with other versions running under default timesharing policy

i.e. timer_usleep.c. Summarise and analyse performance.

The below is the souce code for the same:

#include<stdio.h>

#include<time.h>

#include <sys/time.h>

#include <sys/resource.h>

#include <sched.h>

int main(int argc, char** argv){

struct timeval tv;

struct timezone tz;

int i,delay,num_iter;

double init,start,stop;

// FIFO stuff

int j;

struct sched_param my_sched_params;

int scheduler,prio;

// Start

// Set this process to highest priority FIFO

my_sched_params.sched_priority=sched_get_priority_max(SCHED_FIFO);

printf("Max FIFO priority is %d n",my_sched_params.sched_priority);

j=sched_setscheduler(getpid(),SCHED_FIFO,&my_sched_params);

// Now check actual parameters

scheduler=sched_getscheduler(0); // 0 is shorthand for calling process ID

prio=sched_getparam(getpid(),&my_sched_params);

printf("Scheduler is %d (0=TS, 1=FIFO, 2=RR)and priority is %dn",scheduler,my_sched_params.sched_priority);

if (argc!=3) {

fprintf(stderr, "Usage: %s <sleep time..msec><num_iter>n", argv[0]);

exit(1);

}

// progname=argv[0];

delay=atoi(argv[1]);

num_iter=atoi(argv[2]);printf("Delay is %d..num_iter is %dn",delay,num_iter);

gettimeofday( &tv,&tz);

init=tv.tv_sec + tv.tv_usec*0.000001;

for(i=0;i<num_iter;++i)

{

gettimeofday( &tv,&tz);

start=tv.tv_sec + tv.tv_usec*0.000001;

// now sleep

usleep(delay*1000);

gettimeofday( &tv,&tz);

stop=tv.tv_sec + tv.tv_usec*0.000001;

printf("Time is %ld : %ld..slept for %lf msn",tv.tv_sec,tv.tv_usec,(stop-

start)*1000);

}

printf("Total time taken : actual %lf theory(excl. runtime): %d, ms n",(stop-

init)*1000,num_iter*delay);

return 0;

}

The screen shots below shows execution of the FIFO vs Time sharing

Figure 2b: 1-FIFO vs TimeSharing-FIFO.png

 

Figure 2b: 2-Fifo vs TimeSharing-Usleep

From the two figures above (figure 2b 1-2). it is clearly evident that FIFO performs better than Usleep. Looking closely at the ranges, FIFO takes approximately 0.0128 ms while Usleep takes around 0.060 ms. This makes a huge difference as show by the total time. For Instance, with sleep time set to 200 for both the Fifo and Usleep, Fifo total execution time was 2428 ms while usleep had an execution time of 5893.69.

Part C: FIFO vs timesharing part 2

Repeat part B above, but use code timer_FIFO_loop.c. Compare with

part B; the results should show benefits of FIFO much more clearly. If so, why?

 

Figure 2c : timer_FIFO_loop

 

Figure 2c : timer_usleep.c.

In Part B, we already compared Fifo performance against Usleep’s. Here in part C we carry out almost a similar comparison, but with Fifo_loop. The Out come is so impressive. Fifo execution time is less than half that of usleep. In both cases, sleep time was set to 50000.

Part A:

Implement a memory intensive piece of code where process runtime is measured (similar to timer_mem_use.c provided). Run and analyse performance (an array of 10000000 floats take up approximately 40MB). As above, use a system monitor tool to get a feel for what’s happening with memory. Run a number of processes concurrently thus increasing the memory requirement until memory is being fully utilised and paging is a necessity. The command line vmstat utility allows you to look at the degree of paging going on. Increase number of concurrent processes until paging is occurring frequently and you can see significant changes in runtime. Summarise and analyse results.

Part A: nice

Running timer_mem_use.c really used up more  resource therefore the use of this was intensive in terms of resources  to an extent of making the operating system hanging and also  I had to halt it. In my opinion  the memory used went beyond the 40MB. 100% of the ram was used up, this is because the timer_mem_use used up alot of resources  that resulted to the same effect.

Part B:

Implement POSIX.4 memory locking (root access required) for one instance of code. See timer_memlock.c provided. Run this with other concurrent versions without memory locking (timer_mem_use.c) and increase number of these until paging is required. Be careful to start timer_memlock.c version first. Watch what is happening with memory. Summarise/ analyse performance.

Upon running the timer_mem_use with timer_memlock running, the memory usage seems to be controlled as compared to when test_mem_use running on its own. Running the timer_mem_use alone really used alot of reasources than wen i runned both the timer_memlock.c alongside with the timer_mem_use.c. The memory used therefore was less than 40MB , and also less ram was used up.

Problem 4: Nanosleep

Compile and run the code posix_nanosleep.c. Compare the code and the

results with those from timer_usleep.c

posix_nanosleep.c output
Time is 1521450831 : 518881185..slept for 60081.481934 nsec
Time is 1521450831 : 519056840..slept for 146389.007568 nsec
Time is 1521450831 : 519250185..slept for 63419.342041 nsec
Time is 1521450831 : 519343611..slept for 61035.156250 nsec
Time is 1521450831 : 519434236..slept for 60319.900513 nsec
Time is 1521450831 : 519524797..slept for 60319.900513 nsec
Time is 1521450831 : 519614164..slept for 60081.481934 nsec
Time is 1521450831 : 519703684..slept for 60319.900513 nsec
Time is 1521450831 : 519793408..slept for 60796.737671 nsec
Time is 1521450831 : 519883478..slept for 59843.063354 nsec

Time is 1521450831 : 519972603..slept for 60081.481934 nsec
Time is 1521450831 : 520062079..slept for 60081.481934 nsec
Total time taken : actual 7409.404278 msec theory(excl. runtime): 0 msec

timer_usleep.c
Time is 1521451058 : 14321..slept for 0.059128 ms
Time is 1521451058 : 14458..slept for 0.109911 ms
Time is 1521451058 : 14625..slept for 0.063181 ms
Time is 1521451058 : 14740..slept for 0.060081 ms
Time is 1521451058 : 14830..slept for 0.060081 ms
Time is 1521451058 : 14919..slept for 0.059128 ms
Time is 1521451058 : 15007..slept for 0.059128 ms
Time is 1521451058 : 15095..slept for 0.058889 ms
Time is 1521451058 : 15182..slept for 0.059128 ms
Time is 1521451058 : 15270..slept for 0.060081 ms
Time is 1521451058 : 15357..slept for 0.059128 ms
Time is 1521451058 : 15445..slept for 0.060081 ms
Time is 1521451058 : 15532..slept for 0.059128 ms
Time is 1521451058 : 15702..slept for 0.142097 ms
Total time taken : actual 6857.501030 theory(excl. runtime): 0, ms

Usleep performs better than

References

1. Rochkind, M. J. (2014). Advanced UNIX programming. Pearson Education.
2. Raymond, E. S. (2013). The art of Unix programming. Addison-Wesley Professional.
3. Robbins, K. A., & Robbins, S. (2005). Practical UNIX programming: a guide to concurrency, communication, and multithreading. Prentice-Hall, Inc..
4. Kernighan, B. W., & Mashey, J. R. (1979). The UNIX™ programming environment. Software: Practice and Experience, 9(1), 1-15.
5. Kernighan, B. W., & Pike, R. (2008). The Unix programming environment(Vol. 270). Englewood Cliffs, NJ: Prentice-Hall.