Welcome to the Linux Foundation Forum!

LFS201 Lab 15.1 Comparing I/O Schedulers.

Hi, I'm not sure of the workflow for getting the lab.iosched.sh script to run for this lab.

Im using Ubuntu 20.4 and the command to use was;

$ sudo ./lab_iosched.sh [# reads/writes (NMAX)] [file size in MB (NMEGS)]

How do I get the file into a place where Linux knows where to find it and run it?

Welcome!

It looks like you're new here. Sign in or register to get started.
Sign In

Comments

  • Posts: 99

    Probably chmod +x lab_iosched.sh will do.

  • Note: we worked this in the Office Hours session. Need to do just 'sudo ./lab_iosched.sh' for starting. doing 'less lab_iosched.sh' will provide more information about the parameters.

    Regards,
    Luis.

  • Posts: 916

    Yes, you will have to make it executable probably if you downloaded in place. If you got from the "SOLUTIONS" tar ball it already is executable. Your results will depend on distro and kernel. For example I just ran it on Ubuntu 20.04 and the only IO schedulers were "mq-deadline" and "none". On RHEL 8 you have also "bfq" which is actually the default, at least for a vanilla kernel.

  • Posts: 99

    Mark: You mentioned during the office hour that you didn't manage to set sudo permissions for your default user. I sent you a private message with examples for /etc/sudoers and /etc/group configurations.

  • edited July 2022

    hi @luisviveropena , I fininshed this lab, but I dont understand how to compare the results. Could you please hellp me to interpret the results of running this script? I understand that it is comparing four different I/O scheduling strategies, but the results mean what?. For example, what does this means:

    1. testing IOSCHED = mq-deadline
    2. [mq-deadline] kyber bfq none
    3. 0.517 0.010 0.752

    The full output from the script on my system is like this:

    1. [javier@fedora Downloads]$ sudo ./lab_iosched.sh 16 300
    2. Doing: 16 parallel read/writes on: 300 MB size files
    3.  
    4. creating as needed random input files
    5.  
    6. doing timings of parallel reads
    7.  
    8. REAL USER SYS
    9.  
    10. testing IOSCHED = mq-deadline
    11. [mq-deadline] kyber bfq none
    12. 0.517 0.010 0.752
    13. testing IOSCHED = kyber
    14. mq-deadline [kyber] bfq none
    15. 0.522 0.008 0.645
    16. testing IOSCHED = bfq
    17. mq-deadline kyber [bfq] none
    18. 0.522 0.008 1.062
    19. testing IOSCHED = none
    20. [none] mq-deadline kyber bfq
    21. 0.527 0.011 1.072
    22.  
    23. doing timings of parallel writes
    24.  
    25. REAL USER SYS
    26.  
    27. testing IOSCHED = none
    28. [none] mq-deadline kyber bfq
    29. 0.102 0.056 0.217
    30. testing IOSCHED = mq-deadline
    31. [mq-deadline] kyber bfq none
    32. 0.091 0.033 0.216
    33. testing IOSCHED = kyber
    34. mq-deadline [kyber] bfq none
    35. 0.094 0.043 0.220
    36. testing IOSCHED = bfq
    37. mq-deadline kyber [bfq] none
    38. 0.102 0.035 0.140
  • Posts: 916

    Reading the lab_iosched.sh script that produces the output would tell you what the numbers are. For example the output for the write test is produced by the line:

    time do_write_test

    the three numbers are: wallclock (real) time, user (process) time, and system (kernel) time, in seconds. There are actually these three headings in the output. In hyour results there are very few differences, as can be explained by choice of hardware, linux kernel etc, and if you are on a virtual machine you may have trouble seeing the differences as it is a fake environment. On my real workstation I get:

    1. ROOT@c9:/tmp/TEMP>../lab_iosched.sh
    2. Doing: 8 parallel read/writes on: 100 MB size files
    3.  
    4. creating as needed random input files
    5. 100+0 records in
    6. 100+0 records out
    7. 104857600 bytes (105 MB, 100 MiB) copied, 0.304284 s, 345 MB/s
    8.  
    9. doing timings of parallel reads
    10.  
    11. REAL USER SYS
    12.  
    13. testing IOSCHED = mq-deadline
    14. [mq-deadline] kyber bfq none
    15. 0.158 0.009 0.627
    16. testing IOSCHED = kyber
    17. mq-deadline [kyber] bfq none
    18. 0.155 0.005 0.637
    19. testing IOSCHED = bfq
    20. mq-deadline kyber [bfq] none
    21. 0.164 0.007 0.645
    22. testing IOSCHED = none
    23. [none] mq-deadline kyber bfq
    24. 0.156 0.005 0.689
    25.  
    26. doing timings of parallel writes
    27.  
    28. REAL USER SYS
    29.  
    30. testing IOSCHED = none
    31. [none] mq-deadline kyber bfq
    32. 24.404 0.011 1.052
    33. testing IOSCHED = mq-deadline
    34. [mq-deadline] kyber bfq none
    35. 25.426 0.013 1.116
    36. testing IOSCHED = kyber
    37. mq-deadline [kyber] bfq none
    38. 25.788 0.011 0.958
    39. testing IOSCHED = bfq
    40. mq-deadline kyber [bfq] none
    41. 23.774 0.010 0.891
    42.  
    43.  
    44. Once again not much difference. Modern hardware such as SSD drives has rendered this kind
    45. of issue mostly moot except on certain kinds of situations and the deadline scheduler is almost always the
    46. best choice. It is here partly just so you understand that the kernel has to make decsions about what to read and write and when and in what order
    47.  

Welcome!

It looks like you're new here. Sign in or register to get started.
Sign In

Welcome!

It looks like you're new here. Sign in or register to get started.
Sign In

Categories

Upcoming Training