Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 697. (Read 5805728 times)
January 19, 2012, 11:23:32 AM
Question: what efficiency should I expect (generally)? I'm mining on a Radeon 5750. I'm getting ~27% efficiency (ATM 1820 queued, 500 accepted, and U (whatever it is) is @1.89/m). Is there any way I could improve on my situation?
January 19, 2012, 04:48:30 AM
have you also done something for 7970 optimization?
No, I didn't ask for donations to get one and I don't own one and I have no idea what's required to get one working or optimised. As far as I can tell, by default, it won't even run on cgminer. That said, there is someone who offered to tune "for diablominer and cgminer" who got paid megaBTC to buy one for himself who promised to do so. Having said that, I have yet to see any code for cgminer out of it...At the moment I don't even have a machine that can mine on GPU. Eventually should nothing come from an outside source, I will do the work myself to get 79xx working.
January 19, 2012, 04:46:46 AM
Regarding the voltage settings in windows - they definitely stay what they were set even after a reboot. I've manually set the voltage to 1.1V (nothing about the voltage in the .bat launch file), the PC froze and I had to reboot. After the reboot the voltage is still at 1.1V. I think this is worth looking into, because I've no clue what my default voltage is supposed to be, or whether it would return to normal lower voltage when it's idle.
This is most certainly not intentional and I cannot do anything about it since cgminer consciously changes settings back to default, but windows decides that cgminer should crash every time instead. January 19, 2012, 04:30:23 AM
Massively updated git tree (new minor version coming soon):
[...]
[...]
Happy to see that you kept CPU mining capability (at least for now). Upped my donation rate.
January 19, 2012, 04:24:35 AM
Regarding the voltage settings in windows - they definitely stay what they were set even after a reboot. I've manually set the voltage to 1.1V (nothing about the voltage in the .bat launch file), the PC froze and I had to reboot. After the reboot the voltage is still at 1.1V. I think this is worth looking into, because I've no clue what my default voltage is supposed to be, or whether it would return to normal lower voltage when it's idle.
January 19, 2012, 04:24:15 AM
have you also done something for 7970 optimization?
Of course - that's why the post above said he has ... January 19, 2012, 04:12:19 AM
have you also done something for 7970 optimization?
January 19, 2012, 04:00:26 AM
Massively updated git tree (new minor version coming soon):
Display what support is built in.
BitForce FPGA support
cgminer will scan for and mine BitForce FPGAs on USB ports by providing the
new --scan-serial option, or autodetect them by searching
/dev/serial/by-id for *BitFORCE_SHA256*
Update copyright dates.
Update README.
Configure out building and support of all CPU mining code unless --enable-cpumining is enabled.
Add configuration option for CPU mining which will default to off.
Update example conf with 1% donation.
Allow parsed values to be zero which will allow 0 values in the config file to work.
Advertise that we can make our own midstate, so the pool can skip generating it for us
Refactor the CPU scanhash_* functions to use a common API. Fixes bugs.
- Before, some returned bool, and others returned int (which was then turned
into a bool with a comparison); now, everything returns a bool
- Before, some set hashes_done to nonce - 1 when a share was found and others
set it to nonce + 1 or 2. This caused some algorithms to scan/submit shares
twice with the new cpu_scanhash function. Now, it has all been replaced with
last_nonce, which is set to the final nonce checked by the scanhash_* func.
- VIA needs the full data, and cannot use midstate. All the others were
expecting midstate and data+64 for their parameters. Now, we pass midstate
and the full data pointer, and let the scanhash_* function choose which to
use.
Don't consider a pool lagging if a request has only just been filed.
This should decrease the false positives for "pool not providing work fast enough".
Invalidating work after longpoll made hash_pop return no work giving a false positive for dead pool.
Rework hash_pop to retry while finds no staged work until the abstime timeout really expires.
Remove TCP_NODELAY from curl options as many small packets may be contributing to network overload.
Refactor miner_thread to be common code for any kind of device
This expands on the device API, by taking the actual main thread out of the
device's code, and calling the API only for specific tasks. This brings
various changes that were made to the GPU thread code into the CPU miner.
It also fixes a bug where shares found on old GPU work were discarded when
it switched to a new work.
Simplify submit_nonce loop and avoid potentially missing FOUND - 1 entry. Reported by Luke-Jr.
Micro-optimisation in sha256_sse2 code courtesy of Guido Ascioti [email protected]
Typo in readme.
Refactor to abstract device-specific code
Display what support is built in.
BitForce FPGA support
cgminer will scan for and mine BitForce FPGAs on USB ports by providing the
new --scan-serial
/dev/serial/by-id for *BitFORCE_SHA256*
Update copyright dates.
Update README.
Configure out building and support of all CPU mining code unless --enable-cpumining is enabled.
Add configuration option for CPU mining which will default to off.
Update example conf with 1% donation.
Allow parsed values to be zero which will allow 0 values in the config file to work.
Advertise that we can make our own midstate, so the pool can skip generating it for us
Refactor the CPU scanhash_* functions to use a common API. Fixes bugs.
- Before, some returned bool, and others returned int (which was then turned
into a bool with a comparison); now, everything returns a bool
- Before, some set hashes_done to nonce - 1 when a share was found and others
set it to nonce + 1 or 2. This caused some algorithms to scan/submit shares
twice with the new cpu_scanhash function. Now, it has all been replaced with
last_nonce, which is set to the final nonce checked by the scanhash_* func.
- VIA needs the full data, and cannot use midstate. All the others were
expecting midstate and data+64 for their parameters. Now, we pass midstate
and the full data pointer, and let the scanhash_* function choose which to
use.
Don't consider a pool lagging if a request has only just been filed.
This should decrease the false positives for "pool not providing work fast enough".
Invalidating work after longpoll made hash_pop return no work giving a false positive for dead pool.
Rework hash_pop to retry while finds no staged work until the abstime timeout really expires.
Remove TCP_NODELAY from curl options as many small packets may be contributing to network overload.
Refactor miner_thread to be common code for any kind of device
This expands on the device API, by taking the actual main thread out of the
device's code, and calling the API only for specific tasks. This brings
various changes that were made to the GPU thread code into the CPU miner.
It also fixes a bug where shares found on old GPU work were discarded when
it switched to a new work.
Simplify submit_nonce loop and avoid potentially missing FOUND - 1 entry. Reported by Luke-Jr.
Micro-optimisation in sha256_sse2 code courtesy of Guido Ascioti [email protected]
Typo in readme.
Refactor to abstract device-specific code
January 18, 2012, 06:39:24 PM
3. ability to write current config to text file: {command writeConfig, param filename) (please fix the volt config bug)
The volt config bug is fixed in git. Same with any value that is zero. January 18, 2012, 06:38:53 PM
IRC 
Some changes are happening today or tomorrow.
Edit: FYI we are both in Aus - it's Thu morning here
Code:
09:58 < kanoi> conman: question, since I'm far from knowing much about git ...
if I make some changes to api.c all this luke crap isn't gonna
mean I have to keep redoing it or anything like that? (I can
just work off the current version?)
Some changes are happening today or tomorrow.
Code:
10:23 < kanoi> I wait :)
10:23 < kanoi> I'll
10:24 < kanoi> maybe tomorrow or the weekend then
Edit: FYI we are both in Aus - it's Thu morning here
January 18, 2012, 06:30:57 PM
Well, I guess I have plenty of work to do getting the webpage working nicely, even before the enhancements are ready although it would be nice to code against a working version
January 18, 2012, 06:21:14 PM
But yeah - state exactly what you want with those 2 commands and once the CPU changes happen I'll put those 2 on first priority (for 5 BTC
I would like to add V to the list. the more i read about undervolting, the more I want to try it. especially with summer approaching.
Also, since reconfiguring a bunch of rigs will be easy to do from this interface, would be nice to be able to write the config to a file.
Kano, I am willing to up the anti to get this stuff in.... 10btc? anyone else willing to contribute?
1. ability to switch pools (i think setting a pools priority to 0 would work?)
2. setting the following, for gpus's:
- "intensity" : "newValue",
- "gpu-engine" : "newValue",
- "gpu-vddc" : "newValue",
- "gpu-memclock" : "newValue",
- "gpu-fan": "newValue", ex(50-85)
I think Kano main objection to modification now is the code base will be changed significantly when cpu mining is removed. He would rather wait until cpu mining is complete, finalized, and then work off that version for more PRC enhancements.
January 18, 2012, 06:16:47 PM
But yeah - state exactly what you want with those 2 commands and once the CPU changes happen I'll put those 2 on first priority (for 5 BTC
I would like to add V to the list. the more i read about undervolting, the more I want to try it. especially with summer approaching.
Also, since reconfiguring a bunch of rigs will be easy to do from this interface, would be nice to be able to write the config to a file.
Kano, I am willing to up the anti to get this stuff in.... 10btc? anyone else willing to contribute?
1. ability to switch pools (i think setting a pools priority to 0 would work?)
2. setting the following, for gpus's:
- "intensity" : "newValue",
- "gpu-engine" : "newValue",
- "gpu-vddc" : "newValue",
- "gpu-memclock" : "newValue",
- "gpu-fan": "newValue", ex(50-85)
January 18, 2012, 05:12:01 PM
will try again when I get home, but even when cgminer writes the conf to a file, restarting cgminer will crash. removing this line will allow it to work.
The value must be valid. In some instances cgminer will write 0 as voltage which isn't valid and will cause a parsing error.
January 18, 2012, 05:05:55 PM
speaking of JSON, has anyone got it working for the Volts ?
Code:
"gpu-vddc" : "1.100",
That line works for my setup.
will try again when I get home, but even when cgminer writes the conf to a file, restarting cgminer will crash. removing this line will allow it to work.
January 18, 2012, 05:01:23 PM
speaking of JSON, has anyone got it working for the Volts ?
Code:
"gpu-vddc" : "1.100",
That line works for my setup.
January 18, 2012, 04:57:40 PM
You cannot use the default "0.000" values. Try populating the values with correct voltages.
Also, make sure you don't use comma as your decimal point as some cultures do. Should you do that, JaSON will massacre the poor, unsuspecting cgminer and no mining will be done that day.
Also, make sure you don't use comma as your decimal point as some cultures do. Should you do that, JaSON will massacre the poor, unsuspecting cgminer and no mining will be done that day.
January 18, 2012, 04:44:44 PM
Code:
"submit-stale" : true
Unless you're appending that option at the very end, you'll need a comma too:
Code:
"submit-stale" : true,
speaking of JSON, has anyone got it working for the Volts ?
anytime I put volts into the config, i cannot start cgminer. it will display a json error and stop.
January 18, 2012, 04:16:31 PM
Code:
"submit-stale" : true
Unless you're appending that option at the very end, you'll need a comma too:
Code:
"submit-stale" : true,
January 18, 2012, 03:38:42 PM
Is it possible to turn on the --submit-stale option in the *.conf file?
What is the exact format the entry needs to be in the file?
What is the exact format the entry needs to be in the file?
It can be done from the config.
I don't have it in front of me but I believe it is just:
Code:
"submit-stale" : true
Jump to: