FIRESTARTER VS coreutils

Load: 68.0C (running FIRESTARTER)

Convenient for low level testing, but if you want maximum thermal generation there is no substitute for FIRESTARTER:

https://github.com/tud-zih-energy/FIRESTARTER

With my system hooked up to a watts up (but including the monitor and a couple of other things) yes > /dev/null on each core gets a bit above 42w, openssl speed on each core occasionally gets above 45w and running FIRESTARTER for a bit gets above 57w (on an i5-6260U (NUC) with hyperthreading disabled, 15W TDP with some attempted power restraint in the BIOS, firefox on decent websites like HN tent to use about 31w and I think that is something like 10-15w measuring the computer only).

FIRESTARTER has some evolutionary algorithms as well, but at least on my CPU after hours they were still doing much worse than the default. I was wondering why there wasn't much discussion of BIOS power settings that I could find and after some testing found out that they are not effective at restraining max power use (I forget if they had any effect on typical power use either but I don't think it was much if they did). Also, the integrated GPU can use more power than the CPU and can't be limited. For that GpuTest is handy (but not open source):

https://www.geeks3d.com/gputest/

For me on the internal GPU, Pixmark Piano and Furmark use the most power, either can get 60-61w and adding FIRESTARTER in the background only adds another w or two.

Similarly, checking temps with turbostat (PkgTmp), 2x yes seems to max out about 70, testing one of the higher power openssl tests on each core reaches 75, FIRESTARTER alone quickly reaches 80 and slowly ramps up to 90, and adding gputest got up to 96. Interstingly, the max temperature is reached when the CPU dethrottles too quickly after the gputest is done. It takes a few gputests alone in a row to get into the 80s (I got bored after 2x each alternating Furmark and Piano that hit 83). Similarly, looking at power useage with turbostat the max PkgWatt with yes is 8.26, with openssl speed ecdsa 9.88, with FIRSTARTER alone 17.62, + gputest 19.97 (or gputest alone, seems unreliable).

Anyway, this is a long diversion to say that even fancy yes or openssl speed tests are not that great as CPU stress tests :).

Temperatures: 28.5°C idle / 73.1°C running Firestarter 1hr, fans on "Standard" cooling curve.

I've found Firestarter (https://github.com/tud-zih-energy/FIRESTARTER) is able to generate the highest CPU temperatures compared to other utilities. It's absolutely not comparable to real-world loads, but if can't make your PC crash, then your overclock is probably stable.

Am Ende habe ich mich für das be quiet Dark Base 900 als Ersatz entschieden, weil man dort für einen recht moderaten Preis vielleicht das letzte Gehäuse bekommt was ich je kaufen werde. Und der erste Eindruck ist durchgehend positiv: Das Gehäuse hat fast barokke Opulenz: Absolut riesig, ziemlich schwer, aber was vorallem wichtig ist: gut gekühlt und gut gedämmt. firestarter auszuführen bringt das Ding gerade in den Bereich von "offensichtlich hörbar". (Achja und ein neues, modulares, Netzteil gab es dann auch weil Kabelmanagment = geil)

https://github.com/coreutils/coreutils/commit/fcfba90d0d27a1...

A summary of other changes just released in GNU coreutils 9.5 are:

* mv accepts --exchange to swap files

> some are simple like yes(1)

Not that simple: https://github.com/coreutils/coreutils/blob/master/src/yes.c

The -S / --split-string option[1] of /usr/bin/env is a relatively recent addition to GNU Coreutils. It's available starting from GNU Coreutils 8.30[2], released on 2018-07-01.

Beware of portability: it relies on a non-standard behavior from some operating systems. It only works for OS's that treat all the text after the first space as argument(s) to the shebanged executable; rather than just treating the whole string as an executable path (that can happen to contain spaces).

Fortunately this non-standard behavior is more the norm than the exception: it works at least on modern GNU/Linux, BSDs, and macOS.

[1] https://www.gnu.org/software/coreutils/manual/html_node/env-...

[2] https://github.com/coreutils/coreutils/blob/b09dc6306e7affaf...

> building a cat from scratch

> That would be an interesting project.

Here is the source code of the OpenBSD implementation of cat:

> https://github.com/openbsd/src/blob/master/bin/cat/cat.c

and here of the GNU coreutils implementation:

> https://github.com/coreutils/coreutils/blob/master/src/cat.c

Thus: I don't think building a cat from scratch or creating a tutorial about that topic is particularly hard (even though the HN audience would likely be interested in it). :-)

the yes command, writing to /dev/null, is making IO calls, which interfere with predictable scheduling.

If you look at the source code for yes, https://github.com/coreutils/coreutils/blob/master/src/yes.c

it builds a buffer of output and then writes that in a for loop

  while (full_write (STDOUT_FILENO, buf, bufused) == bufused)

Looking at the source of nohup, if the execvp() of the child happens then it _must_ have already done the signal (SIGHUP, SIG_IGN) so - WTF?

This got me wondering so I went and looked and it seems like lo and behold there was actually a commit to the GNU ls source just 2 weeks ago.

https://github.com/coreutils/coreutils/blob/master/src/ls.c

"maint: prefer char32_t to wchar_t"

even an empty file? Yes. so now it was a file with a copyright disclaimer and nothing else. And the koan-like question comes to mind is "Can you copyright nothing?" well AT&T sure tried.

Then somebody said our programs should be well defined and not depend on a fluke of unix, which at this point was probable a good idea. so it became "exit 0"

Then somebody said we should write our system utilities in C instead of shell so it runs faster. openbsd still has a good example of how this would look.

http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr....

At some point gnu bureaucracy got involved and said all programs must support the '-h' flag. so that got added, then they said all programs must support locale so that got added. now days gnu true is an astonishing 80 lines long.

https://github.com/coreutils/coreutils/blob/master/src/true....

http://trillian.mit.edu/~jc/humor/ATT_Copyright_true.html

> Yes, ls is maintained. Although, maintained is a very strong word. It exists.

Why would it be a strong word? Here it is, in src/ls.c: https://github.com/coreutils/coreutils

It is then packaged by tens of operating system distributions, who themselves maintain extra patchsets, some of which are then upstreamed.

It is installed and used on millions (billions?) of devices, for 3 decades.

It's a very reliable and trusty "sharp stick of metal" :)