[cfarm-users] Compile Farm acceptable usage---low priority batch jobs

[Jacob Bachmeyer]

On 1/1/25 17:25, Gregor Riepl via cfarm-users wrote:
>> We want nothing at all to do with any of it (well, I don't, at least),
>> even if not all of it is directly against the rules, does not violate
>> acceptable use directly: it is just distasteful.
>>
>> The cfarm is supposed to be used for developing (which includes testing
>> etc.) any software that is close enough to open source, anything that
>> benefits user freedom and all that goodness.  It is hard to see how any
>> klepto stuff will fit in with that, even if "technically" it is open
>> source.
>
> Just to weigh in with a somewhat neutral point of view here:
>
> I do not think it would be fair or in the interest of the general 
> public to ban cfarm use for specific development purposes even if they 
> are related to blockchain technology, cryptocurrencies and similar 
> fields, insofar as the infrastructure isn't (ab)used to support actual 
> schemes.

I would suggest allowing the use of the cfarm for development and 
testing, especially portability testing to non-x86 architectures, but 
making very clear that "mining" for profit is not permitted, lest all 
other use be buried under a sea of "miners".

For Bitcoin at least, I know that there is a shadow "testnet" suitable 
for such work.  Need to test a "miner" at the cfarm?  Do it on 
"testnet".  (Bitcoin "testnet" is identical except that the tokens on 
"testnet" are agreed to be worthless.  Oh, and the "testnet" hash rate 
is accordingly much lower, last I heard.)

The problem is that "mining" uses an outrageous amount of CPU 
resources---and is /intended/ to do so.  Fully testing a "miner" will 
waste a large amount of processor time that could probably be better 
used for other development work.

Perhaps a combination of nice(1) and ulimit(1) would be suitable?  
Should all "miner" testing be required to use `nice 19` to minimize 
effects on other users?  Could this be a basis for general conventions 
for lightly-attended jobs to reserve higher priorities for 
fully-interactive use?

For example, a large but non-urgent compile job (such as by CI or a 
periodic build of a GCC snapshot) could be run with `nice 5` or `nice 
10` to reduce its effects on users who are actually waiting for results.

To be fair, I have thus far always been in the latter group (actually 
waiting for results) because I have used the cfarm for testing 
portability fixes in DejaGnu on obscure systems (Solaris, AIX) before 
pushing them to Savannah, and I have /not/ encountered significant CPU 
usage by other users noticeably slowing those runs.


-- Jacob