Should I be running "--no-submit-stale " when I use BFL (FPGA)?
Probably not. "--no-submit-stale" is basically broken-by-design, but exists because it is technically required by the old longpoll specification. I say broken-by-design because it tries to guess which shares are stale based on insufficient information (this algorithm is also required by the old LP spec): whenever a longpoll is received, all shares found on old work is discarded. Many pools are using longpolls even when the old shares are still valid as a way to improve the Bitcoin network (by processing more transactions) - at least Eligius, EclipseMC, and TripleMining to my knowledge. p2pool also expects valid blocks to be found in stale shares, so you don't want to discard those either. Additionally, discarding stale shares makes all pools' website stats underreport your stale rate. So if you do use "--no-submit-stale", anything your pool tells you about your stales is wrong. On the other hand, submitting stales doesn't hurt unless your internet connection can't handle your mining rigs (in which case, your mining experience will suffer all the time there isn't a longpoll!). 
Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 565. (Read 5805546 times)
June 03, 2012, 10:36:22 AM
June 03, 2012, 10:27:28 AM
Should I be running "--no-submit-stale " when I use BFL (FPGA)?
Depends which pool your using.
June 03, 2012, 10:20:20 AM
Should I be running "--no-submit-stale " when I use BFL (FPGA)?
June 03, 2012, 12:41:22 AM
Kano,
Do you have a list of each version of your API, and what it adds? Change log type thing?
NEWS fileDo you have a list of each version of your API, and what it adds? Change log type thing?
I'm pretty certain I've changed the version number every time for a new release with new commands or new data.
Edit: also - it's highly consistent from one version to the next - new fields are added to the end - the order is never changed ... with CGMiner
Edit2: hmm looks like some of the NEWS descriptions don't say the actual API version numbers very often
(I guess I'll need to check the git why ...)
e.g. commands added/changed, fields added and such
June 02, 2012, 11:33:42 PM
New version - 2.4.2, June 3rd 2012
Human readable changelog:
-Longpoll will now finally only connect to the main pool unless you switch pools, and then it will drop the longpoll on the next block if you are still on the new pool. This should complete the rework to make cgminer have the absolute optimum number of connections open at any one time - the minimum possible while having the best hashrate, and will likely decrease the lost work across block changes. No solution to multipool+LP here was going to be perfect but this seemed the best overall to miners and pools alike.
-The windows crash at 7 days which occurred thanks to the AMD driver fuckage should be fixed. Now it will behave the way it used to behave:you'll just lose your fan monitoring once the driver has fucked up.
-New Icarus code should scan more of each work item and has some hidden advanced timing options (see new readme file)
-Saved config file when there are no GPUs should no longer be corrupt.
-Separate READMEs for API and FPGA evolving.
Full changelog
- API.class compiled with Java SE 6.0_03 - works with Win7x64
- miner.php highlight devs too slow finding shares (possibly failing)
- API update version to V1.11 and document changes
- API save default config file if none specified
- api.c save success incorrectly returns error
- api.c replace BUFSIZ (linux/windows have different values)
- Move RPC API content out of README to API-README
- Open a longpoll connection if a pool is in the REJECTING state as it's the
only way to re-enable it automatically.
- Use only one longpoll as much as possible by using a pthread conditional
broadcast that each longpoll thread waits on and checks if it's the current pool
before
- If shares are known stale, don't use them to decide to disable a pool for
sequential rejects.
- Restarting cgminer from within after ADL has been corrupted only leads to a
crash. Display a warning only and disable fanspeed monitoring.
- Icarus: fix abort calculation/allow user specified abort
- Icarus: make --icarus-timing hidden and document it in FPGA-README
- Icarus: high accuracy timing and other bitstream speed support
- add-MIPSEB-to-icarus-for-BIG_ENDIAN
- work_decode only needs swab32 on midstate under BIG ENDIAN
- add compile command to api-example.c
- save config bugfix: writing an extra ',' when no gpus
- Add dpkg-source commits
Human readable changelog:
-Longpoll will now finally only connect to the main pool unless you switch pools, and then it will drop the longpoll on the next block if you are still on the new pool. This should complete the rework to make cgminer have the absolute optimum number of connections open at any one time - the minimum possible while having the best hashrate, and will likely decrease the lost work across block changes. No solution to multipool+LP here was going to be perfect but this seemed the best overall to miners and pools alike.
-The windows crash at 7 days which occurred thanks to the AMD driver fuckage should be fixed. Now it will behave the way it used to behave:you'll just lose your fan monitoring once the driver has fucked up.
-New Icarus code should scan more of each work item and has some hidden advanced timing options (see new readme file)
-Saved config file when there are no GPUs should no longer be corrupt.
-Separate READMEs for API and FPGA evolving.
Full changelog
- API.class compiled with Java SE 6.0_03 - works with Win7x64
- miner.php highlight devs too slow finding shares (possibly failing)
- API update version to V1.11 and document changes
- API save default config file if none specified
- api.c save success incorrectly returns error
- api.c replace BUFSIZ (linux/windows have different values)
- Move RPC API content out of README to API-README
- Open a longpoll connection if a pool is in the REJECTING state as it's the
only way to re-enable it automatically.
- Use only one longpoll as much as possible by using a pthread conditional
broadcast that each longpoll thread waits on and checks if it's the current pool
before
- If shares are known stale, don't use them to decide to disable a pool for
sequential rejects.
- Restarting cgminer from within after ADL has been corrupted only leads to a
crash. Display a warning only and disable fanspeed monitoring.
- Icarus: fix abort calculation/allow user specified abort
- Icarus: make --icarus-timing hidden and document it in FPGA-README
- Icarus: high accuracy timing and other bitstream speed support
- add-MIPSEB-to-icarus-for-BIG_ENDIAN
- work_decode only needs swab32 on midstate under BIG ENDIAN
- add compile command to api-example.c
- save config bugfix: writing an extra ',' when no gpus
- Add dpkg-source commits
June 02, 2012, 10:38:08 PM
This is probably a bad way to do it, but I just found the section in cgminer.c with the disabled message and changed it to exit.
Then I start it with a .bat file:
Now if I pull the plug on the BFL Singles, it stops and waits for 60 seconds and then tries to restart again.
Code:
if (unlikely(!hashes)) {
applog(LOG_ERR, "%s %d failure, disabling!", api->name, cgpu->device_id);
cgpu->deven = DEV_DISABLED;
cgpu->device_last_not_well = time(NULL);
cgpu->device_not_well_reason = REASON_THREAD_ZERO_HASH;
cgpu->thread_zero_hash_count++;
goto disabled;
}Code:
Changed:
goto disabled;
To:
exit(1);
Then I start it with a .bat file:
Code:
:loop
C:\cgminer\cgminer.exe -S COM8 -S COM9
timeout /T 60
goto loop
Now if I pull the plug on the BFL Singles, it stops and waits for 60 seconds and then tries to restart again.
June 02, 2012, 12:24:15 PM
Why not just have a computer start mining at the appropriate time when it boots?
Thus when you have a power outage and it can't mine due to BFL's losing power ... the computer wont be doing anything either.
Then when power is restored and the computer boots up, it will then start mining again ...
Thus when you have a power outage and it can't mine due to BFL's losing power ... the computer wont be doing anything either.
Then when power is restored and the computer boots up, it will then start mining again ...
It's because the computer I have to use is a laptop, so it automatically runs on it's battery when the power goes out.
June 02, 2012, 11:28:11 AM
Why not just have a computer start mining at the appropriate time when it boots?
Thus when you have a power outage and it can't mine due to BFL's losing power ... the computer wont be doing anything either.
Then when power is restored and the computer boots up, it will then start mining again ...
Thus when you have a power outage and it can't mine due to BFL's losing power ... the computer wont be doing anything either.
Then when power is restored and the computer boots up, it will then start mining again ...
It's because the computer I have to use is a laptop, so it automatically runs on it's battery when the power goes out.
June 02, 2012, 11:08:31 AM
I've got cgminer running on a laptop, so if there's a power outage it will keep running, but it may lose network connectivity and the BFL singles will lose power.
I tried to simulate a power outage, and cgminer disabled the Singles. When I plugged the power back in, it was just stuck... it wouldn't re-enable them.
Error writing to BitForce ("ZFX")
BFL 0 failure, disabling!
Is there a setting somewhere, so that it will detect them again after they've been disabled due to a power outage so they can begin mining again?
Why not just have a computer start mining at the appropriate time when it boots?I tried to simulate a power outage, and cgminer disabled the Singles. When I plugged the power back in, it was just stuck... it wouldn't re-enable them.
Error writing to BitForce ("ZFX")
BFL 0 failure, disabling!
Is there a setting somewhere, so that it will detect them again after they've been disabled due to a power outage so they can begin mining again?
Thus when you have a power outage and it can't mine due to BFL's losing power ... the computer wont be doing anything either.
Then when power is restored and the computer boots up, it will then start mining again ...
June 02, 2012, 10:35:45 AM
I've got cgminer running on a laptop, so if there's a power outage it will keep running, but it may lose network connectivity and the BFL singles will lose power.
I tried to simulate a power outage, and cgminer disabled the Singles. When I plugged the power back in, it was just stuck... it wouldn't re-enable them.
Error writing to BitForce ("ZFX")
BFL 0 failure, disabling!
Is there a setting somewhere, so that it will detect them again after they've been disabled due to a power outage so they can begin mining again?
I tried to simulate a power outage, and cgminer disabled the Singles. When I plugged the power back in, it was just stuck... it wouldn't re-enable them.
Error writing to BitForce ("ZFX")
BFL 0 failure, disabling!
Is there a setting somewhere, so that it will detect them again after they've been disabled due to a power outage so they can begin mining again?
June 02, 2012, 02:29:47 AM
Australia is sleeping, so take this as a non-qualified guess.
--disable-opencl --disable-adl --enable-bitforce are configuration and not compile options. This is what you need to build for Linux, guess it should be same for Windows:
On successful build, run and the second line of the output will show you what is supported (for you it should be 'Built with bitforce mining support.').
HTH
--disable-opencl --disable-adl --enable-bitforce are configuration and not compile options. This is what you need to build for Linux, guess it should be same for Windows:
Code:
autogen.sh
configure --disable-opencl --disable-adl --enable-bitforce CFLAGS="-O2 -msse2"
make
On successful build, run
Code:
cgminer --help
HTH
That did it, thanks!
cgminer 2.4.1
Built with bitforce mining support.
It's mining now.
June 02, 2012, 02:01:44 AM
I received my two BFL singles so I'm trying out my self-compiled version of cgminer that disables opencl and enables bitforce. These are the options I used when I compiled it (on windows):
CFLAGS="-O2 -msse2 --disable-opencl --disable-adl --enable-bitforce"
The two BFL singles are on COM8 and COM9, so I tried starting cgminer:
cgminer -o url:port -u user -p pass -S COM8 -S COM9
But I get an error:
-S: unrecognized option
Can you think of anything I'm missing?
CFLAGS="-O2 -msse2 --disable-opencl --disable-adl --enable-bitforce"
The two BFL singles are on COM8 and COM9, so I tried starting cgminer:
cgminer -o url:port -u user -p pass -S COM8 -S COM9
But I get an error:
-S: unrecognized option
Can you think of anything I'm missing?
Australia is sleeping, so take this as a non-qualified guess.
--disable-opencl --disable-adl --enable-bitforce are configuration and not compile options. This is what you need to build for Linux, guess it should be same for Windows:
Code:
autogen.sh
configure --disable-opencl --disable-adl --enable-bitforce CFLAGS="-O2 -msse2"
make
On successful build, run
Code:
cgminer --help
HTH
June 02, 2012, 01:48:19 AM
I received my two BFL singles so I'm trying out my self-compiled version of cgminer that disables opencl and enables bitforce. These are the options I used when I compiled it (on windows):
CFLAGS="-O2 -msse2 --disable-opencl --disable-adl --enable-bitforce"
The two BFL singles are on COM8 and COM9, so I tried starting cgminer:
cgminer -o url:port -u user -p pass -S COM8 -S COM9
But I get an error:
-S: unrecognized option
Can you think of anything I'm missing?
CFLAGS="-O2 -msse2 --disable-opencl --disable-adl --enable-bitforce"
The two BFL singles are on COM8 and COM9, so I tried starting cgminer:
cgminer -o url:port -u user -p pass -S COM8 -S COM9
But I get an error:
-S: unrecognized option
Can you think of anything I'm missing?
June 01, 2012, 05:24:17 PM
Bitdefender deletes cgminer.exe, too and doesn't notify, I uninstalled that bullshit and reverted to Avira. They managed to not detect cgminer.exe, as it was a false-positive anyway.
Dia
Dia
June 01, 2012, 04:29:13 PM
For some reason, if cgminer crashes badly ( not my computer, my computer is still up and running. )
it appears that it deletes the cgminer executable.
All the other files in the cgminer folder are there, just not the executable.
Anybody else experience this?
Has been happening to me about once every 3 weeks since around cgminer 2.3.3 I think.
I'm running windows 7 and currently using cgminer 2.4.1, just experienced this issue again.
Not sure what could be causing this. It's not standard hard disk data corruption, it's happened under 3 computers of mine now and no other programs seem to be effected.
it appears that it deletes the cgminer executable.
All the other files in the cgminer folder are there, just not the executable.
Anybody else experience this?
Has been happening to me about once every 3 weeks since around cgminer 2.3.3 I think.
I'm running windows 7 and currently using cgminer 2.4.1, just experienced this issue again.
Not sure what could be causing this. It's not standard hard disk data corruption, it's happened under 3 computers of mine now and no other programs seem to be effected.
Anti-virus? Some anti-virus programs just delete "suspected files" without any user prompt.
I'm using avast. Pretty sure avast would just sandbox it, and then notify me of that.
*edit* It does appear to be avast. It started deleting it every time I copied over on one computer until I disabled avast.
Anyway, if anybody else is using avast and experiences this problem, well, here's your explanation.
Weird though... Usually avast doesnt act like this.
Trend Micro does the same thing - just deletes the .exe. I switched to MSE and it wants to get rid of it, but I told it to ignore.
May 29, 2012, 01:35:03 PM
Question for Con or Kano?
Should GPU statistics be reset when a GPU is disabled?
What I see is that "avg", "util", falls off slowly when GPU is disabled.
After some time the avg, util values are very small and when the GPU is re-enabled,
the statistics is not correct for sometime as the duration of the OFF time is taken into account.
Maybe the GPU stats should be reset when GPU is disabled.
EDIT: Maybe total_secs should take into account (subtract) the time spent in disabled state.
This should "freeze" all time sensitive stats.
Should GPU statistics be reset when a GPU is disabled?
What I see is that "avg", "util", falls off slowly when GPU is disabled.
After some time the avg, util values are very small and when the GPU is re-enabled,
the statistics is not correct for sometime as the duration of the OFF time is taken into account.
Maybe the GPU stats should be reset when GPU is disabled.
EDIT: Maybe total_secs should take into account (subtract) the time spent in disabled state.
This should "freeze" all time sensitive stats.
June 01, 2012, 04:24:43 PM
For some reason, if cgminer crashes badly ( not my computer, my computer is still up and running. )
it appears that it deletes the cgminer executable.
All the other files in the cgminer folder are there, just not the executable.
Anybody else experience this?
Has been happening to me about once every 3 weeks since around cgminer 2.3.3 I think.
I'm running windows 7 and currently using cgminer 2.4.1, just experienced this issue again.
Not sure what could be causing this. It's not standard hard disk data corruption, it's happened under 3 computers of mine now and no other programs seem to be effected.
it appears that it deletes the cgminer executable.
All the other files in the cgminer folder are there, just not the executable.
Anybody else experience this?
Has been happening to me about once every 3 weeks since around cgminer 2.3.3 I think.
I'm running windows 7 and currently using cgminer 2.4.1, just experienced this issue again.
Not sure what could be causing this. It's not standard hard disk data corruption, it's happened under 3 computers of mine now and no other programs seem to be effected.
Anti-virus? Some anti-virus programs just delete "suspected files" without any user prompt.
I'm using avast. Pretty sure avast would just sandbox it, and then notify me of that.
*edit* It does appear to be avast. It started deleting it every time I copied over on one computer until I disabled avast.
Anyway, if anybody else is using avast and experiences this problem, well, here's your explanation.
Weird though... Usually avast doesnt act like this.
June 01, 2012, 04:22:30 PM
For some reason, if cgminer crashes badly ( not my computer, my computer is still up and running. )
it appears that it deletes the cgminer executable.
All the other files in the cgminer folder are there, just not the executable.
Anybody else experience this?
Has been happening to me about once every 3 weeks since around cgminer 2.3.3 I think.
I'm running windows 7 and currently using cgminer 2.4.1, just experienced this issue again.
Not sure what could be causing this. It's not standard hard disk data corruption, it's happened under 3 computers of mine now and no other programs seem to be effected.
it appears that it deletes the cgminer executable.
All the other files in the cgminer folder are there, just not the executable.
Anybody else experience this?
Has been happening to me about once every 3 weeks since around cgminer 2.3.3 I think.
I'm running windows 7 and currently using cgminer 2.4.1, just experienced this issue again.
Not sure what could be causing this. It's not standard hard disk data corruption, it's happened under 3 computers of mine now and no other programs seem to be effected.
Anti-virus? Some anti-virus programs just delete "suspected files" without any user prompt.
June 01, 2012, 04:16:14 PM
For some reason, if cgminer crashes badly ( not my computer, my computer is still up and running. )
it appears that it deletes the cgminer executable.
All the other files in the cgminer folder are there, just not the executable.
Anybody else experience this?
Has been happening to me about once every 3 weeks since around cgminer 2.3.3 I think.
I'm running windows 7 and currently using cgminer 2.4.1, just experienced this issue again.
Not sure what could be causing this. It's not standard hard disk data corruption, it's happened under 3 computers of mine now and no other programs seem to be effected.
it appears that it deletes the cgminer executable.
All the other files in the cgminer folder are there, just not the executable.
Anybody else experience this?
Has been happening to me about once every 3 weeks since around cgminer 2.3.3 I think.
I'm running windows 7 and currently using cgminer 2.4.1, just experienced this issue again.
Not sure what could be causing this. It's not standard hard disk data corruption, it's happened under 3 computers of mine now and no other programs seem to be effected.
June 01, 2012, 12:03:29 PM
everytime i try to run java api notify i get a constant tag 13 in class file
Well "code tag" the actual error so I can see.Also include the output of "java -version"
and lastly - of course it is "java API notify"
(the capital letters I've typed before do matter)
(though that is probably nothing to do with the problem)
The fix may well be "javac API.java" but will require the java SDK
I recompiled API.java (with an old java 6.0_03 SE) and got him to download it and it worked.
Only to later find that the files were actually the same - the issue was the file protection.
I've sent a pull to the git with the new API.class it only shows a file protection difference.
So you may be able to fix it by changing the file protection of API.class in windows to be executable - though I'm really not sure of the standard method to do that in windows
Jump to: