ultimately its about building - compiling - rolling out - streamlining ... all clones of one worker ... all with linux - all with exact same hardware - all with ccminer-spmod ( and sgminer at the moment for the current amd cards ) ...
i guess we will need to wait and see if any of these plans come to light ... im on this full time and daily now - so time is not an issue any more ...
edit - the compile still bombs ... but i am tired and need sleep - so maybe im doing something wrong ... tomorrow will work on it further ...
#crysx
Hardware shouldn't be an issue except for the CPU and GPU. There is no technical need, though you may have other reasons,
to have all the HW identical. Even the CPU and GPU differences can be ovecome in many cases. Different GPU generations
can be supported with a single compile as discussed in the part that I snipped. And differences in CPU extensions can be worked
around by specifying the arcitecture that works on the least capable CPU. Not really a good idea for CPU critical progs.
Software, of course, has to be the same.
I don't know if there is any benefit to having matching GPUs in the same rig. I tend to mix bigger and smaller cards as it's
easier on power supplies (I'm less likely to need a new bigger one) and heat dissipation especially on Linux where fan control
is usually limited to only one card.
Regarding your compile problems, and assuming they are related to the compute version setting in the makefile, the syntax
is pretty straightforward if you understand the difference between = and +=. Any C programmer would not have to think twice
but you've said many times you are not a coder so I'll offer the following.
= is a direct variable assignment. There must be exactly one of these for the compute version.
+= will add to the existing variable. There may be any number of these or none and they must be
after the direct assignment.
# is a comment. Those lines are not read by the compiler.
If you are compiling for only one compute version you only need the direct assignment of that version.
If you are compiling for multiple compute versions you need one direct assignment followed by as many
add assignments as needed to specify all the desired compute versions.
I took a close look at the code I posted and it should have worked for you as is. I also took another look
at your problem description, the part about Makefile.in. AFAIK that file is not part of the clone but created
by the compile process (either autogen or configure, not sure which). The point is did you do a make distclean
before attempting the second compile with the modified Makefile.am? I sometimes delete the tree and re-expand
the tarball if I'm having a bad compile day. You may want to reclone and edit (or replace) Makefile.am before doing
anything else.
i appreciate your explanation ... it has helped ...
just to clarify a couple of points jo ...
the reason i have designed the machines in the format they are AND we have the farm mining the way it does ( structurally and software ) is to simplify maintenance and maintain an even level of comparative statistics with respect to power draw - physical location and 'stacking' ( which is why these machines are to be rebuilt in the custom designed frames we have almost finished ) - cooling and software roll out ...
the main design goal is duplication ... which is why a development machine ( testing ) needs not comply with the overall farm design - though is beneficial for the software rollout ...
so when compiling - the cpu / gpu and software can be setup once - and rolled out to the existing infrastructure AND future when expansion to the farm is required ... so keeping everything in line with the gen and model and software is of major importance if the 'hands on' component is to be minimized ...
so all the same hardware and software would be much more beneficial across the farm - in order for the rollout to happen smoothly - and in the future of the farm in terms of expansion or even upgrades ( say - when the gtx 980 oc cards become the 'norm' ( so to speak - as 750ti oc has ) ) ...
so when the compilation breaks - it becomes an issue ... not so if there was only one machine to handle - thats simple ... but an issue when there are multiple machines with the same break ...
in this case - i did do clean - and that is part of the compile / installation script ... when i took sp's suggestion of copying back the previous makefile from the older v51 compile - the compilation went through without issue ...
i guess its just a matter of changing the makefile back to the way it was - or to the way you have posted earlier which i havent retested ... i was completely spent last night ... so mistakes would have been prevalent in almost all of the changes made to anything i touch last night ...
the main goal is to just standardize the clone / compile / install procedure via a script and rollout the same way across the machines of the farm ...
for the moment - gigabyte 750ti oc lp cards ar ethe only cards that will be used in this farm ... so compute_52 is useless to us here ...
obviously this is a rare issue and only seems to happen with us - as sp develops for the broader community ...
but i like to bring it to light here - just in case someone else has a similar issue ...
tanx again jo ...
#crysx
