This is yet another example of you copy/pasting things you've seen on the forums without understanding what they do.
You're using a -n value of 160, which is like 40-80x larger than it should be, which is dramatically increasing the kernel execution time, preventing the main loop from being able to calculate the speed since the kernel hasn't returned yet.
As I told you on your other thread, -n 160 makes no sense for this algorithm. You would use this -n value for a fast hash like MD5, not a slow non-hash like 7zip. Further, as I also explained on your other thread, -w is an alias for automatically setting the appropriate -n/-u values, so you specify either -w or you specify -n/-u -- you never specify both.
Just get rid of -n & -u and it should be a lot better. If not, try -w 1. If that's too slow, then get rid of -w and try -n 2 or -n 1 with -u 1024.
You're using a -n value of 160, which is like 40-80x larger than it should be, which is dramatically increasing the kernel execution time, preventing the main loop from being able to calculate the speed since the kernel hasn't returned yet.
As I told you on your other thread, -n 160 makes no sense for this algorithm. You would use this -n value for a fast hash like MD5, not a slow non-hash like 7zip. Further, as I also explained on your other thread, -w is an alias for automatically setting the appropriate -n/-u values, so you specify either -w or you specify -n/-u -- you never specify both.
Just get rid of -n & -u and it should be a lot better. If not, try -w 1. If that's too slow, then get rid of -w and try -n 2 or -n 1 with -u 1024.