[00:49] <waltman> /dev/random also blocks, which makes it a really bad choice for benchmarking.
[09:46] <teddy-dbear> Morning peoples, critters and everything else
[13:35] <ChinnoDog> Here is my new crude CPU benchmark: dd if=/dev/urandom bs=1M count=1024 | sha256sum
[13:36] <ChinnoDog> It has the benefit of being able to use the dd output stats for measurement. I get 82.6MB/s
[13:44] <waltman> I'm still confused about what it is you think you're measuring. That pipeline uses 3 cpus.
[13:45] <waltman> dd + sha256sum + one to run the RNG code
[13:54] <ChinnoDog> One to run the rng code? I assumed dd usage would be insignificant since it is only copying bits in memory.
[13:54] <ChinnoDog> I guess generating random numbers could be expensive. hmm
[13:58] <ChinnoDog> I measured it. It is expensive.
[14:00] <ChinnoDog> I would need to make it run single threaded to get the number I wanted. However, both systems I am comparing have 2+ CPUs so I think it is ok for now.
[14:07] <waltman> Surely there are existing benchmarks to measure whatever it is you're interested in.
[14:07] <ChinnoDog> I couldn't find any convenient CPU benchmark tools in the default RHEL repositories which is all I have to work with.
[14:08] <waltman> Once you write a pipeline you're using multiple CPUs.
[14:09] <ChinnoDog> There must be a way to constrain all child processes from my command to a single CPU.
[14:10] <ChinnoDog> I could wrap it in a "sh -c" if I had to.
[14:11] <waltman> I really doubt it.
[14:37] <ChinnoDog> That sounds like a challenge.
[14:38] <waltman> It's kind of the point to take advantage of multiple CPUs for this.
[14:39] <waltman> If you want to be sure things are constrained to a single CPU, you're far better writing an actual program than trying to rely on shell tricks, especially since you don't seem to understand them well.
[15:51] <ChinnoDog> I understand them and I knew that there would be some parallelization, I just thought that they would be insignificant relative to the sha2 algorithm
[15:52] <ChinnoDog> I mean sha256. The RNG does take about 1/4 of the time of the sha256 calculation time though so I would expect if done right the command will take 25% longer when single threaded.
[15:53] <waltman> You fundamentally can't test just single-threaded CPU performance in a pipeline. Find a program.
[15:54] <waltman> Pipelines run on multiple CPUs. If you're accessing /dev/urandom, that's causing the kernel to run the random number generator and it's going to affect your results.
[15:55] <waltman> Also as you've discovered it's easy to guess wrong about what's going to take the time.
[15:56] <waltman> https://linuxconfig.org/how-to-benchmark-your-linux-system
[16:10] <ChinnoDog> I made it run on one core. taskset -a -c 0 sh -c "dd if=/dev/urandom bs=1M count=1024 | sha256sum"
[16:10] <ChinnoDog> Although I'm not letting the scheduler select the core I think the number it produces is accurate since the scheduler will just send the other processes to other cores.
[16:11] <ChinnoDog> Incidentally, it actually runs /faster/ when it is confined to one core.
[16:13] <ChinnoDog> I verified by running it with a large count for DD and verifying with top that the CPU time for dd + sha256sum <= 100%
[16:53] <waltman> What exactly is it you're trying to do?
[16:54] <waltman> Even if you confine that to a single CPU, you've still got process switching involved.
[17:24] <ChinnoDog>  That is ok! My intent was to come up with a way to compare CPU performance on different systems. That is all. I don't need an exact measure since I only need to know if there was something wrong with one of the systems.
[20:36] <ChinnoDog> I used the earlier multi-threaded version to confirm that the performance of the server in question was similar to my laptop so it did not have a CPU issue. It is suffering from the usual cause of slowness. Bad programming.
[20:38] <ChinnoDog> No matter how fast computers get people still make them run slow by doing Bad Things
[20:39] <waltman> I mean, you do you, but I still think your methodology is bogus.
[20:39] <waltman> :)
[20:39] <ChinnoDog> I don't understand why. I ran a command that was restricted to one CPU and received a measurement of how fast it ran. Is that not what a benchmark is?
[20:41] <ChinnoDog> It took nothing into account except the raw performance of a couple common CPU intensive algorithms so it isn't great for comparing diverse hardware but that wasn't part of the design criteria.
[20:45] <waltman> You've got too many variables. You've got several algorithms running different processes so you've also got task switching to consider. Not to mention you're reinventing the wheel.
[20:45] <waltman> Any, I've given up on trying to convince you. Have fun.