Topic: BTCMiner - Open Source Bitcoin Miner for ZTEX FPGA Boards, 215 MH/s on LX150 - page 12. (Read 161727 times)
June 16, 2012, 03:41:04 PM
Ok think I found out why the down throttling spiral occured. my local BTC server was only accepting connections from deepbit IP... hm wierd... since second time I started BTCMiner it complained about URL... Now mining happily locally... or how does one know they are mining properly... since I only have 1 GH it would take weeks to know right?... :/ these attacks are really smart! improves the chance of getting blocks for the attackers!!!
June 16, 2012, 03:19:38 PM
Did you try another pool?
Also try to use another software (cgminer with the fpga or others with yout cpu/gpu) to verify that the problem is not you or the pools connection.
I had to change them several times yesterday (seems ongoing DDOSon some pools). BitParking had problems and BTCGuild too.
The problem of BTCMiner stopping when connection-problems arise has to be fixed, also occurred during my testing of pools and somelike every 2 days in the morning on BitParking - couldnt identify the problem but think its the software (e.g. string handling with unhandled exceptions).
Right now mining at osco.in with no problem since yesterday evening.. looking forward to the next morning and monday morning...
/*break*/
besides: one of my quad-baords now is mailed to ztex due to one downclocking core, looking forward to be told I am too stupid using mx4 :\ or cleaning with isopropanol .
Also try to use another software (cgminer with the fpga or others with yout cpu/gpu) to verify that the problem is not you or the pools connection.
I had to change them several times yesterday (seems ongoing DDOSon some pools). BitParking had problems and BTCGuild too.
The problem of BTCMiner stopping when connection-problems arise has to be fixed, also occurred during my testing of pools and somelike every 2 days in the morning on BitParking - couldnt identify the problem but think its the software (e.g. string handling with unhandled exceptions).
Right now mining at osco.in with no problem since yesterday evening.. looking forward to the next morning and monday morning...
/*break*/
besides: one of my quad-baords now is mailed to ztex due to one downclocking core, looking forward to be told I am too stupid using mx4 :\ or cleaning with isopropanol .
June 16, 2012, 03:07:39 PM
Hm, since deepbit is down I tried starting the miner against localhost. Then the FPGA's keep dropping the frequency like crazy until they stop because of overheat but they are dead cold... ?! Now I'm back on deepbit and everything is fine. Seems it must be polling that craps out?!
June 16, 2012, 02:34:49 PM
Hm, my cluster just stopped working when deepbit was unconnectable for a while:
Lots of:
Followed by:
Ok, but why did the cluster stop!!!
If I hadn't been by the computer I might have lost hashing time.
Edit: ZtexBTCMiner-120221.jar
Lots of:
Error: connect timed out: Disabling URL http://pit.deepbit.net:8332 for 30s
Followed by:
Warning: 4 overflows occured. This is usually caused by a slow network connection.
Ok, but why did the cluster stop!!!
If I hadn't been by the computer I might have lost hashing time.
Edit: ZtexBTCMiner-120221.jar
June 13, 2012, 02:29:42 AM
K, so I am not failing with my understanding of pipes. 
I mean thanks to this forum and of course ztex and ppl like you it is all fine, we can read and ask .. also I could read the code myself - but for now I prefer just to document my silly ideas.
just edited my suggestions-post .. perhaps it inspires someone
I mean thanks to this forum and of course ztex and ppl like you it is all fine, we can read and ask .. also I could read the code myself - but for now I prefer just to document my silly ideas.
just edited my suggestions-post .. perhaps it inspires someone
June 13, 2012, 02:20:49 AM
Because it goes to stderr and not to stdout.
Thanks for clarification - but now it sounds even more like a bug to me 
OK, if you request the usage, then it should not come out on stderr. But it's easy to fix:
Code:
@@ -1923,7 +1940,7 @@
forceEP0Config = true;
}
else if ( args[i].equals("-h") ) {
- System.err.println(ParameterException.helpMsg);
+ System.out.println(ParameterException.helpMsg);
System.exit(0);
}
else if ( args[i].equals("-n") ) {
June 13, 2012, 01:52:55 AM
Because it goes to stderr and not to stdout.
Thanks for clarification - but now it sounds even more like a bug to me June 13, 2012, 12:39:28 AM
just ideas .. nothing worth, but probably sth others would also like to have
Help-output for usage with pipes
I tried -h command line switch either on Windows 7 and Ubuntu 12.04.
Not surprisingly I got the help-output for commandline switches.
As I am lazy I like to print such things into a textfile for better access.. but that doesnt work the pipe-way I am used to.
command at mine was ending:
-h >BTCMiner-help.txt
That file still is empty afterwards, but why?
Help-output for usage with pipes
I tried -h command line switch either on Windows 7 and Ubuntu 12.04.
Not surprisingly I got the help-output for commandline switches.
As I am lazy I like to print such things into a textfile for better access.. but that doesnt work the pipe-way I am used to.
command at mine was ending:
-h >BTCMiner-help.txt
That file still is empty afterwards, but why?
Because it goes to stderr and not to stdout.
Code:
> java -cp ZtexBTCMiner.jar BTCMiner -h 2> BTCMiner-help.txt
will do the job.
June 12, 2012, 11:20:10 AM
just ideas .. nothing worth, but probably sth others would also like to have
*edit due to the explanation of r0bi42
correct piping of stdout/stderrHelp-output for usage with pipes
I tried -h command line switch either on Windows 7 and Ubuntu 12.04.
Not surprisingly I got the help-output for commandline switches.
As I am lazy I like to print such things into a textfile for better access.. but that doesnt work the pipe-way I am used to.
command at mine was ending:
-h >BTCMiner-help.txt
That file still is empty afterwards, but why?
- IMHO errors should be pointed to stderr instead of mixing them with 'normal' output-msg, so we could pipe just errors in some log
- e.g. help instead belongs to stdout in my mind
- help could be printed when the jar / BTCMiner is called with unexpected switches or none (just starting the jar right now results in error msg)
/edit
Error-handling
I'd like to have some possibility to actively handle errors during runtime automatically.
One could repeatingly scan the log-file for errors.. but it appears to me a simple reporting as (documented) error-numbers and exiting BTCMiner would (optionally?) be a far better solution than running nevertheless there are problems that could be dealt with.
Even better would be to communicate with another (repeating temporary) instance of BTCMiner and the running one, so that the cluster has not to stop anytime.
Changing -oh at runtime
As the runtime-commands are waiting for string-input and release by hitting [Enter]:
can you implement some runtime-command like oh=#.##
where users can (re)set overheat protection for testing without stopping the BTCMiner?
Changing pool (using -host and -b) at runtime
Same thing like the other runtime-option:
perhaps via: pool=2
could change to 1st -b and: pool=1
back to the one given by -host
Thanks for now..
*edit due to the explanation of r0bi42
correct piping of stdout/stderr
Not surprisingly I got the help-output for commandline switches.
As I am lazy I like to print such things into a textfile for better access.. but that doesnt work the pipe-way I am used to.
command at mine was ending:
-h >BTCMiner-help.txt
That file still is empty afterwards, but why?
- IMHO errors should be pointed to stderr instead of mixing them with 'normal' output-msg, so we could pipe just errors in some log
- e.g. help instead belongs to stdout in my mind
- help could be printed when the jar / BTCMiner is called with unexpected switches or none (just starting the jar right now results in error msg)
/edit
Error-handling
I'd like to have some possibility to actively handle errors during runtime automatically.
One could repeatingly scan the log-file for errors.. but it appears to me a simple reporting as (documented) error-numbers and exiting BTCMiner would (optionally?) be a far better solution than running nevertheless there are problems that could be dealt with.
Even better would be to communicate with another (repeating temporary) instance of BTCMiner and the running one, so that the cluster has not to stop anytime.
Changing -oh at runtime
As the runtime-commands are waiting for string-input and release by hitting [Enter]:
can you implement some runtime-command like oh=#.##
where users can (re)set overheat protection for testing without stopping the BTCMiner?
Changing pool (using -host and -b) at runtime
Same thing like the other runtime-option:
perhaps via: pool=2
could change to 1st -b and: pool=1
back to the one given by -host
Thanks for now..
June 12, 2012, 10:26:37 AM
Some other modification:
* new option -nolog to not write a logfile (I have only a super small and slow ssd)
* new option -ac to auto reset error and performance counter after given seconds (I'm using a 1 hour interval)
* and the modified frequency change logging
Here's the link to the patch file:
http://www.file-upload.net/download-4438741/BTCMiner.patch.html
To apply the patch:
* new option -nolog to not write a logfile (I have only a super small and slow ssd)
* new option -ac
* and the modified frequency change logging
Here's the link to the patch file:
http://www.file-upload.net/download-4438741/BTCMiner.patch.html
To apply the patch:
Code:
> cd bitminer-src
> patch -p1 < BTCMiner.patch
June 12, 2012, 08:46:06 AM
In which features you are interested. A new release which contains new logging functions and minor changes (typos and so) is scheduled for June.
one very very simple request: make it run at 300MH
No wait.. just that: Could you include a parameter (option) to enable it to blink when a share was found? I know this is utterly useless but i would love to see this *G*
I like this too!
June 12, 2012, 03:08:22 AM
one very very simple request: make it run at 300MH
No wait.. just that: Could you include a parameter (option) to enable it to blink when a share was found? I know this is utterly useless but i would love to see this *G*
No wait.. just that: Could you include a parameter (option) to enable it to blink when a share was found? I know this is utterly useless but i would love to see this *G*
Can be implemented easily for 1.15x boards :-), but not for 1.15y board because these have not general purpose LED.
Well since i have a 15x i owuld be happy for it to get implemented
...but i suppose you didnt mean the 300mh idea?
June 12, 2012, 02:58:07 AM
one very very simple request: make it run at 300MH
No wait.. just that: Could you include a parameter (option) to enable it to blink when a share was found? I know this is utterly useless but i would love to see this *G*
No wait.. just that: Could you include a parameter (option) to enable it to blink when a share was found? I know this is utterly useless but i would love to see this *G*
Can be implemented easily for 1.15x boards :-), but not for 1.15y board because these have not general purpose LED.
June 12, 2012, 02:56:15 AM
Make fmax configurable to underclock the fpgas;)
I wrote it several times before: If the frequency is limited of overheat detection mechanism does not work anymore. This feature is unsafe and will not be implemented.
June 11, 2012, 02:11:06 PM
And I would like to see a "die hard" software forcing the limping FPGA to mine at 200 MHz
June 11, 2012, 01:40:45 PM
Make fmax configurable to underclock the fpgas;)
June 11, 2012, 01:13:19 PM
In which features you are interested. A new release which contains new logging functions and minor changes (typos and so) is scheduled for June.
one very very simple request: make it run at 300MH
No wait.. just that: Could you include a parameter (option) to enable it to blink when a share was found? I know this is utterly useless but i would love to see this *G*
June 11, 2012, 04:18:19 AM
Is Ztex the only one developing the Java BTCMiner?
Could it be run from source code or does one need to package it into the .jar file?
Is there anyone here who could give me a quick rundown what's required to get this to work after I made some changes to the source code (mostly to the logging functions for now)? I can donate some BTC in return! (I'd like to do this on my Windows box for now)
Could it be run from source code or does one need to package it into the .jar file?
Is there anyone here who could give me a quick rundown what's required to get this to work after I made some changes to the source code (mostly to the logging functions for now)? I can donate some BTC in return! (I'd like to do this on my Windows box for now)
Compiling tutorials (including windows) can be found at http://wiki.ztex.de/doku.php?id=en:software:tutorial_compiling. The only thing that need to be considered additionally is the adjustment of variable ''ZTEXPREFIX'' in the Makefile of the BTCMiner source package. It has to point to the directory where the ZTEX SDK is installed, see gr0bi42 postings.
In which features you are interested. A new release which contains new logging functions and minor changes (typos and so) is scheduled for June.
June 11, 2012, 02:13:24 AM
Anyone interested in this?
Good job gr0bi42! Are you using Ubuntu and what JDK are you using?Code:
001-1: ztex_ufm1_15y1-04A346BE51-2: Change frequency from 208.00MHz to 212.00MHz
001-1: ztex_ufm1_15y1-04A346BE51-2: Change frequency from 212.00MHz to 216.00MHz
001-1: ztex_ufm1_15y1-04A346BE51-2: Change frequency from 216.00MHz to 208.00MHz
Yes, I'm using ubuntu. It's version 11.04 (Natty). Further: openjdk-6 and java-common (ubuntu 11.04 default packages via Synaptic Package Manager).
June 10, 2012, 05:53:35 PM
I have been using the test mode with "-m t" a couple of times. I noticed that only FPGA1 gets warm. Is this supposed to test all 4 FPGAs or only FPGA1?
Jump to: