In the ramp-requests.py file, there's no clear reason for using sleep(5) after executing the subprocess.run() method for an attack.
My guess is that when creating the process with run(), it was assumed to be non-blocking, and sleep(5) was given to match -duration 5s.
If this assumption is correct, the subprocess.run() method is blocking, and it won't execute the next command until the child process finishes, making the sleep unnecessary.
If there was an intention to add an arbitrary delay, there should be a specific comment or explanation. Otherwise, if someone assumes that subprocess.run() is non-blocking and adds time.sleep(5), it can cause confusion.
You can find more details about the blocking nature of subprocess in the following links:
Background
In the ramp-requests.py file, there's no clear reason for using sleep(5) after executing the subprocess.run() method for an attack. My guess is that when creating the process with run(), it was assumed to be non-blocking, and sleep(5) was given to match -duration 5s. If this assumption is correct, the subprocess.run() method is blocking, and it won't execute the next command until the child process finishes, making the sleep unnecessary. If there was an intention to add an arbitrary delay, there should be a specific comment or explanation. Otherwise, if someone assumes that subprocess.run() is non-blocking and adds time.sleep(5), it can cause confusion.
You can find more details about the blocking nature of subprocess in the following links:
Checklist