Anyone know if there is a way to still see the output in the miner and also put the info into a log.txt.
Command line please if there is? I know how to get it to log to a file, but would like to also see that info in the miner still as well while log to .txt.
On Linux you can use the "tee" command. |
|
|
|
Please stop spamming multiple threads. Thank you
That's what you just did. I see my contribution is not appreciated so I'll leave. |
|
|
|
|
profitability for the usual algos is going down, anyone knows some new one (or old one to revive) worth working on?
|
|
|
|
Hi! You can add my github if you wish: https://github.com/pallas1There is nothing interesting in there, as I usually do pull requests on other dev's forks, but I may have something "original" in the future ;-) |
|
|
|
The vanilla wallet is compiled with many static libraries. Other than a build annoyance for people wanting to compile themselves, it is a security issue. When your operating system does security updates on those libraries, the wallet will be unaffected by those updates and will keep being vulnerable. This is pretty common for windows applications, much less on unix. See here for the discussion: https://bitcointalk.org/index.php?topic=1064326.msg12499004#msg12499004I warned you ;-) personally i prefer static builds for security related apps, because a lib can attack its host-app. if its just a file somewhere on the system it may get updated unnoticed (i tend to update security apps more carefully than normal libs). that just means someone has to rebuild if a "normal" security hole is found in a lib: not a big issue IMHO If a hacker has access to a lib, it has access to the host program as well, so it doesn't make a difference. Seeing how often (for example) openssl has been updated for severe security issues recently, I think building it statically in a cryptocoin wallet is to be considered a security issue. YMMV of course. And before people start attacking me, I'm not bashing the coin, just saying what my concerns are. Maybe your concern has a point from your perspective but as you can see the opposite is true for many others including this coins dev. You have made your idea clear but I think you might be having trouble accepting that this is not going to change? From my point of view you are pushing system security onto the dev rather than taking it into your own hands. The simple solution, don't compile from source if you aren't comfortable with it. I don't agree with what you are saying but in order to avoid an offtopic and starting an endless discussion, I'll just add that the issue is not only for people compiling it, but also for people using precompiled binaries. And if people using VNL are fine with that, then it's ok ;-) |
|
|
|
The vanilla wallet is compiled with many static libraries. Other than a build annoyance for people wanting to compile themselves, it is a security issue. When your operating system does security updates on those libraries, the wallet will be unaffected by those updates and will keep being vulnerable. This is pretty common for windows applications, much less on unix. See here for the discussion: https://bitcointalk.org/index.php?topic=1064326.msg12499004#msg12499004I warned you ;-) personally i prefer static builds for security related apps, because a lib can attack its host-app. if its just a file somewhere on the system it may get updated unnoticed (i tend to update security apps more carefully than normal libs). that just means someone has to rebuild if a "normal" security hole is found in a lib: not a big issue IMHO If a hacker has access to a lib, it has access to the host program as well, so it doesn't make a difference. Seeing how often (for example) openssl has been updated for severe security issues recently, I think building it statically in a cryptocoin wallet is to be considered a security issue. YMMV of course. And before people start attacking me, I'm not bashing the coin, just saying what my concerns are. |
|
|
|
The vanilla wallet is compiled with many static libraries. Other than a build annoyance for people wanting to compile themselves, it is a security issue. When your operating system does security updates on those libraries, the wallet will be unaffected by those updates and will keep being vulnerable. This is pretty common for windows applications, much less on unix. See here for the discussion: https://bitcointalk.org/index.php?topic=1064326.msg12499004#msg12499004I warned you ;-) |
|
|
|
Git 1092 dont work whith solo mining...
I'm sad that it doesn't work but happy that it's not my fault :-D I assume we can revert the last commit, than, because it disabled the "don't send work to GPU while disconnected", which is quite useful. Actually I just wanted someone to test it (to know if that part was to blame), not that it ended in the main fork... I'd have tested it myself if I had the time to do it. |
|
|
|
|
between those commits there is my little modification to stop gpus when disconnected (it has been edited by sp back then):
/* prevent gpu scans before a job is received */
if ((have_stratum && work.data[0] == 0 || network_fail_flag) && !opt_benchmark)
{
sleep(1);
continue;
}
Let's see if it has something to do with solo mining problems; try changing it like this:
if (have_stratum && work.data[0] == 0 && !opt_benchmark)
|
|
|
|
|
I think this discussion is worthless.
There is tpruvot fork from which most of the others were forked from.
It's the best one in terms of features but it doesn't have all the optimisations.
You can use it.
OR
Use sp fork if you want the speed.
Or Klaust's fork. Or Djm34's. Or make your own (tip: take tpruvot and apply the optimisations). Or help fixing the bugs.
Whatever you want to do, stop whining and go ahead :-D
BTW there will never be fair rewards for the miners because you can't measure the value of each one's work. And anyway it's a handful of dollars worth.
|
|
|
|
|
This version is not marginally faster.
If you ever compared quark, neoscrypt and x11 with the other forks you'll know it's between 10 and 30 percent faster.
|
|
|
|
how to build the wallet on linux without compiling boost, db and openssl?
if I already have those libs in the system, why build them again?
(boost is pretty slow to compile, took more that 10 hours on my nas)
VNL doesn't use shared libraries for security reasons (they can be replaced or infected). You must static link all dependencies. Here is a one shot script that you can fire and walk away from: https://github.com/xCoreDev/vanillacoin-scripts  Thank you for your support. Sorry sir but this doesn't make sense. Following your reasons, I should statically link every library into every wallet or application that can deal with sensitive data, including browsers, terminals, etc. I will end up with tens of occurrencies of every library. Furthermore, you are recompiling only three libraries, not all of them. You are gonna use libc, aren't you? Can't it be infected as well? Finally, recompiling is different than statically linking. I can have the static libraries without recompiling, and they are checksum checked when installed. Cryptographic currencies should not use shared cryptographic libraries, period. libc is not a cryptographic library however boost does contain cryptographic functions that are used. The Bitcoin developers experienced a fork because they allowed the use of shared cryptographic libraries which were replaced during a system upgrade. Ultimately this was caused by gmaxwell's signature bug but brought to light by the upgraded library causing the network to fork. This same bug is what caused the Bitcoin network to recently split into two parts due to a faulty upgrade losing people 100's of thousands of dollars. Ultimately the system security is up to you, so I will leave it at that. Thank you for your support. My points are still valid. And db is not a cryptographic library :-) And taking about security... You'll need to release a new wallet every time there is a cert on any of those static libraries and find a way to force everyone to upgrade. And for Linux force rebuild of the libraries. It's a nightmare! |
|
|
|
Maybe your drivera are too old? Bugs have been fixed by NVIDIA in the latest versions.
they are all the same sp ... all these installed have exactly the same installation procedures and apps ... same os - same cuda - same components ... the only thing different between thses ystems are the motherboards and cpu ( i think ) ... the installation of both these mchines ar exactly the same as well ... this is the main reason i want to finish the hardware 'upgrade' of the systems - so that they are EXACTLY the same hardware also ... ill be doing fresh installs on ALL the machines when the frames are finished ... its quite baffling ... but they process the same though - so its all good on a hashing level ... #crysx maybe different gpu firmware or firmware version. |
|
|
|
Does C work on the 750ti. I can't get it to work. thx
It's a very simple call, similar to what it does for fan speed which works, so I don't think there is a fix for it in ccminer code. If it never works on 750, I or Sp may add a check to show it only if compute >= 5.2 Anyone with 750 and working clock logging? sorry - just popped in ... clock logging? ... i can compile the latest and test - if you let me know what im looking for ... tanx ... #crysx the gpu hashrate line has been enhanced with current clocks reading (along with already available fan speed and temperature). you must have nvml working, of course. if you are on linux and nvml isn't enabled, try compiling with "--with-nvml" |
|
|
|
Does C work on the 750ti. I can't get it to work. thx
It's a very simple call, similar to what it does for fan speed which works, so I don't think there is a fix for it in ccminer code. If it never works on 750, I or Sp may add a check to show it only if compute >= 5.2 Anyone with 750 and working clock logging? |
|
|
|
how to build the wallet on linux without compiling boost, db and openssl?
if I already have those libs in the system, why build them again?
(boost is pretty slow to compile, took more that 10 hours on my nas)
VNL doesn't use shared libraries for security reasons (they can be replaced or infected). You must static link all dependencies. Here is a one shot script that you can fire and walk away from: https://github.com/xCoreDev/vanillacoin-scripts Thank you for your support. Sorry sir but this doesn't make sense. Following your reasons, I should statically link every library into every wallet or application that can deal with sensitive data, including browsers, terminals, etc. I will end up with tens of occurrencies of every library. Furthermore, you are recompiling only three libraries, not all of them. You are gonna use libc, aren't you? Can't it be infected as well? Finally, recompiling is different than statically linking. I can have the static libraries without recompiling, and they are checksum checked when installed. |
|
|
|
CCMINER STATS--
@T-Nelson-- Your Linux CCminer displays stats differently than sp_'s version. I get Temperature, Fan Percent, and "c=0/0". What is the third statistic? --scryptr
C=graphics clock/memory clock If you're getting 0, it means it's not supported on your cards. Which chipset? Yup, that's some additions since sp_ cut a release. Just cosmetics AFAIK. I added that. It's very useful to me since my cards throttle easily. If you have fixed clocks it might look boring, still you can detect throttle and other strange behaviors in case there is some issue. |
|
|
|
don't think it is related...ccminer has been sending back much bigger messages (creditcoin for example) without any problem (and without changing that part). However I know that the message length has to be the one expected by the wallet otherwise it will get refused (like for neoscrypt btw and a few others. This assertion isn't present in all wallets... but it is present for sure for lyra2rev2 and neoscrypt, but usually the problem is more with getting the message than sending it back) The sprintf() call was the only obvious path to a smashed stack that I saw in submit_upstream_work(). Being as the stack was utterly destroyed, I couldn't examine the parameters passed in to see if they were valid or not. There could be a scribbler elsewhere, but it's going to take me a few more days to solve another block and hit my breakpoint. if you are in luck you can try testnet (I tried, however, I haven't been able to sync... ) I had the same issue just before the vtc fork. Turned out there was nobody mining on testnet so no blocks were generated :-) |
|
|
|
CCMINER STATS--
@T-Nelson-- Your Linux CCminer displays stats differently than sp_'s version. I get Temperature, Fan Percent, and "c=0/0". What is the third statistic? --scryptr
C=graphics clock/memory clock If you're getting 0, it means it's not supported on your cards. Which chipset? |
|
|
|
Can I just mine into the developers nicehash address or is there some reason I need to go through granitecoin.com?
I think the reason is that, using the "proxy", the developer can change address and pool without notifying everybody. |
|
|
|
|
Show Posts
