Pages:
Author

Topic: OLD: BFGMiner 4.10.0: GBT+Stratum, RPC, Mac/Linux/Win64, Spondoolies SP30 - page 10. (Read 308659 times)

legendary
Activity: 2576
Merit: 1186
It's possible the device cannot keep up at difficulty 1 (the default). Try using --set pxy:diff=128 or such.
I have been in the "market" for a proxy miner, and this can be my prayers answered since I already run bfgminer for my usb hashers, but would like to add my S3's to it to "focus" my mining might.

For the case of ghash, it is OK to have the option to set the difficulty on the command line with, e.g --set pxy:diff=128, since you can set your worker difficulty poolside to whatever you want (so long as it is above 32).

For other pools though, e.g slush, the difficulty is set dynamically dependent on your speed, so the question is: Is it possible to flag bfgminer in proxy mode to pass on the difficulty to the connected rigs dynamically too?
Not currently. However, if the upstream (pool) difficulty is lower than the one configured, it will be used to avoid losing shares.
So in effect, you'd get the behaviour you want with eg --set pxy:diff=100000000
I am possibly missing something very obvious, but wouldn't setting the proxy diff to a large abstract number then instruct the connected rigs to only submit shares larger than that number to the proxy, thus the rigs discarding (not sure whether that is the correct term) otherwise valid shares?
Yes, but BFGMiner actually uses the lower of the configured diff and the upstream diff.
So, if the pool wants 128 and you have configured 1000, BFGMiner will actually use 128.

On another but related note, I remember reading somewhere that the maximum diff size (due to a design oversight?) is 1024, or was that P2Pool only and now resolved?
Neither stratum nor GBT specify any maximum diff.
hero member
Activity: 518
Merit: 500
It's possible the device cannot keep up at difficulty 1 (the default). Try using --set pxy:diff=128 or such.
I have been in the "market" for a proxy miner, and this can be my prayers answered since I already run bfgminer for my usb hashers, but would like to add my S3's to it to "focus" my mining might.

For the case of ghash, it is OK to have the option to set the difficulty on the command line with, e.g --set pxy:diff=128, since you can set your worker difficulty poolside to whatever you want (so long as it is above 32).

For other pools though, e.g slush, the difficulty is set dynamically dependent on your speed, so the question is: Is it possible to flag bfgminer in proxy mode to pass on the difficulty to the connected rigs dynamically too?
Not currently. However, if the upstream (pool) difficulty is lower than the one configured, it will be used to avoid losing shares.
So in effect, you'd get the behaviour you want with eg --set pxy:diff=100000000
I am possibly missing something very obvious, but wouldn't setting the proxy diff to a large abstract number then instruct the connected rigs to only submit shares larger than that number to the proxy, thus the rigs discarding (not sure whether that is the correct term) otherwise valid shares?
On another but related note, I remember reading somewhere that the maximum diff size (due to a design oversight?) is 1024, or was that P2Pool only and now resolved?
legendary
Activity: 2576
Merit: 1186
Is there a cap on the speed of an individual device when running BFGMiner in proxy mode?  When I connect my S3 to the proxy, my speed runs at about 250 GH/s for the device, if I connect directly to GHASH it runs over 450 GH/s.
It's possible the device cannot keep up at difficulty 1 (the default). Try using --set pxy:diff=128 or such.
I have been in the "market" for a proxy miner, and this can be my prayers answered since I already run bfgminer for my usb hashers, but would like to add my S3's to it to "focus" my mining might.

For the case of ghash, it is OK to have the option to set the difficulty on the command line with, e.g --set pxy:diff=128, since you can set your worker difficulty poolside to whatever you want (so long as it is above 32).

For other pools though, e.g slush, the difficulty is set dynamically dependent on your speed, so the question is: Is it possible to flag bfgminer in proxy mode to pass on the difficulty to the connected rigs dynamically too?
Not currently. However, if the upstream (pool) difficulty is lower than the one configured, it will be used to avoid losing shares.
So in effect, you'd get the behaviour you want with eg --set pxy:diff=100000000
hero member
Activity: 518
Merit: 500
Is there a cap on the speed of an individual device when running BFGMiner in proxy mode?  When I connect my S3 to the proxy, my speed runs at about 250 GH/s for the device, if I connect directly to GHASH it runs over 450 GH/s.
It's possible the device cannot keep up at difficulty 1 (the default). Try using --set pxy:diff=128 or such.
I have been in the "market" for a proxy miner, and this can be my prayers answered since I already run bfgminer for my usb hashers, but would like to add my S3's to it to "focus" my mining might.

For the case of ghash, it is OK to have the option to set the difficulty on the command line with, e.g --set pxy:diff=128, since you can set your worker difficulty poolside to whatever you want (so long as it is above 32).

For other pools though, e.g slush, the difficulty is set dynamically dependent on your speed, so the question is: Is it possible to flag bfgminer in proxy mode to pass on the difficulty to the connected rigs dynamically too?
legendary
Activity: 2576
Merit: 1186
Is there a cap on the speed of an individual device when running BFGMiner in proxy mode?  When I connect my S3 to the proxy, my speed runs at about 250 GH/s for the device, if I connect directly to GHASH it runs over 450 GH/s.
It's possible the device cannot keep up at difficulty 1 (the default). Try using --set pxy:diff=128 or such.
sr. member
Activity: 361
Merit: 267
Is there a cap on the speed of an individual device when running BFGMiner in proxy mode?  When I connect my S3 to the proxy, my speed runs at about 250 GH/s for the device, if I connect directly to GHASH it runs over 450 GH/s.

9 hours connected to BFGMiner proxy mode:




Directly connected to GHASH for over 3 days:

hero member
Activity: 518
Merit: 500
Does anyone have an old win32 install zip that supports CPU mining?  Everything in the archive has been built without it I believe.

If you are unable to find a link, there are instructions for build for Windows (including CPU mining) here:

https://github.com/luke-jr/bfgminer/blob/bfgminer/windows-build.txt

Thanks.  The last time I built an executable it was 20 years ago :-).  I've never built a windows binary before and it looks quite involved!

If anyone does have a link or zip I would appreciate it.
I don't blame you for not wanting to build one as it is one heck of a task.
Having spent the better part of Saturday's first half of the evening trying to compile BFGMiner for windows (and having a complete MinGW environment), I made a fresh git download and all goes well until ...

Code:
make[2]: Entering directory `/home/User/bfgminer'
  CC     bfgminer-miner.o
In file included from ./miner.h:43:0,
                 from ./sha2.h:39,
                 from miner.c:68:
miner.c: In function 'have_block_height':
miner.c:2928:48: error: expected ')' before 'PRIx32'
  applog(LOG_DEBUG, "Learned that block id %08" PRIx32 " is height %" PRIu32, (u
int32_t)be32toh(block_id), blkheight);
                                                ^
miner.c: In function 'work_decode':
miner.c:3150:82: error: expected ')' before 'PRId64'
      applog(LOG_WARNING, "Cannot append template-nonce to coinbase on pool %u (
%"PRId64") - you might be wasting hashing!", work->pool->pool_no, (int64_t)ae);

  ^
miner.c:3161:107: error: expected ')' before 'PRId64'
      applog((appenderr ? LOG_DEBUG : LOG_WARNING), "Cannot append coinbase sign
ature at all on pool %u (%"PRId64")", pool->pool_no, (int64_t)ae);

                           ^
miner.c:3200:66: error: expected ')' before 'PRId64'
             "Pool %u truncating appended coinbase signature at %"PRId64" bytes:
 %s(%s)",
                                                                  ^
miner.c:3208:91: error: expected ')' before 'PRId64'
      applog((appenderr ? LOG_DEBUG : LOG_WARNING), "Error appending coinbase si
gnature (%"PRId64")", (int64_t)ae);

           ^
miner.c: In function 'hashmeter':
miner.c:8337:36: error: expected ')' before 'PRIu64'
   applog(LOG_DEBUG, "[thread %d: %"PRIu64" hashes, %.1f khash/sec]",
                                    ^
make[2]: *** [bfgminer-miner.o] Error 1
make[2]: Leaving directory `/home/User/bfgminer'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/User/bfgminer'
make: *** [all] Error 2

I could go into the code and add the odd bracket et all as the error suggests, but then that could spawn another error ....
Now that was from last nite .... and the repository was also downloaded last nite! I am not sure whether the *nix builds are OK, but  ....
Any insights?

EDIT:

Like I suspected, after posting I decided to go ahead and edit the errors out, did that, and now .... though some progress, more errors still!

Code:
make[2]: Entering directory `/home/User/bfgminer'
  CC     bfgminer-miner.o
  CC     bfgminer-deviceapi.o
  CC     bfgminer-util.o
In file included from winhacks.h:4:0,
                 from config.h:719,
                 from util.c:16:
c:\mingw\include\mstcpip.h:17:5: error: expected identifier or '(' before numeri
c constant
     _WSAIOW(IOC_VENDOR, 4)
     ^
In file included from deviceapi.h:10:0,
                 from lowl-vcom.h:9,
                 from util.c:60:
util.c: In function 'keep_sockalive':
util.c:327:46: error: expected expression before ',' token
  if (unlikely(WSAIoctl(fd, SIO_KEEPALIVE_VALS, &vals, sizeof(vals), NULL, 0, &o
utputBytes, NULL, NULL)))
                                              ^
miner.h:173:45: note: in definition of macro 'unlikely'
 #define unlikely(expr) (__builtin_expect(!!(expr), 0))
                                             ^
util.c: In function 'json_rpc_call_async':
util.c:505:44: error: expected ')' before 'PRIu64'
   sprintf(ghashrate, "X-Mining-Hashrate: %"PRIu64, (uint64_t)global_hashrate);
                                            ^
In file included from miner.h:43:0,
                 from deviceapi.h:10,
                 from lowl-vcom.h:9,
                 from util.c:60:
util.c: In function 'check_coinbase':
util.c:2485:44: error: expected ')' before 'PRIu64'
    applog(LOG_DEBUG, "Coinbase output: %10"PRIu64" -- %s%s", amount, s, ah ? "*
" : "");
                                            ^
logging.h:60:35: note: in definition of macro 'applog'
    snprintf(tmp42, sizeof(tmp42), fmt, ##__VA_ARGS__); \
                                   ^
util.c:2491:77: error: expected ')' before 'PRIu64'
   applogr(false, LOG_ERR, "Coinbase check: lopsided total output amount = %"PRI
u64", expecting >=%"PRIu64, total, cb_param->total);
                                                                             ^
logging.h:60:35: note: in definition of macro 'applog'
    snprintf(tmp42, sizeof(tmp42), fmt, ##__VA_ARGS__); \
                                   ^
util.c:2491:3: note: in expansion of macro 'applogr'
   applogr(false, LOG_ERR, "Coinbase check: lopsided total output amount = %"PRI
u64", expecting >=%"PRIu64, total, cb_param->total);
   ^
util.c:2495:74: error: expected ')' before 'PRIu64'
    applogr(false, LOG_ERR, "Coinbase check: lopsided target/total = %g(%"PRIu64
"/%"PRIu64"), expecting >=%g", (total ? (double)target / total : (double)0), tar
get, total, cb_param->perc);
                                                                          ^
logging.h:60:35: note: in definition of macro 'applog'
    snprintf(tmp42, sizeof(tmp42), fmt, ##__VA_ARGS__); \
                                   ^
util.c:2495:4: note: in expansion of macro 'applogr'
    applogr(false, LOG_ERR, "Coinbase check: lopsided target/total = %g(%"PRIu64
"/%"PRIu64"), expecting >=%g", (total ? (double)target / total : (double)0), tar
get, total, cb_param->perc);
    ^
util.c:2506:90: error: expected ')' before 'PRIu64'
   applog(LOG_DEBUG, "Coinbase: (size, pos, addr_count, target, total) = (%lu, %
lu, %d, %"PRIu64", %"PRIu64")", (unsigned long)cbsize, (unsigned long)pos, (int)
(HASH_COUNT(cb_param->scripts)), target, total);

          ^
logging.h:60:35: note: in definition of macro 'applog'
    snprintf(tmp42, sizeof(tmp42), fmt, ##__VA_ARGS__); \
                                   ^
make[2]: *** [bfgminer-util.o] Error 1
make[2]: Leaving directory `/home/User/bfgminer'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/User/bfgminer'
make: *** [all] Error 2
newbie
Activity: 57
Merit: 0
@nwoolls
Could you please update the WR703n firmware to BFGminer4.8. I cannot do it myself, got stuck on the size of the firmware.
Thanks
newbie
Activity: 27
Merit: 0
Additionally, I came across this message:

http://s28.postimg.org/9le3s52ml/BFGtemp_Copy.jpg

There was no way it hit any temp above 42c, yet BFG thought it hit 139.  This is the same RBox that gave the "Chip id out of range" messages from the previous post.  Any ideas?

B
hero member
Activity: 527
Merit: 500
HiveNet - Distributed Cloud Computing
Trying to run New R-Box 100 GH/s on BFG Miner 4.8.0 win 32.........it will detect device with .... rockminer:all    but I get message RKM0   chip  id:11 out of range.     any guesses?

The original Rboxes do that too.   Does it happen every 5 minutes or so?  Is the Chip ID number always the same or does it change to different numbers?

They do? I've never seen it...

Here is that screenshot I promised.  It finally happened while I was sitting in front of it.  This is running on Win8/64.



B

I just started using 4.8 yesterday and I've been seeing a ton of those messages. Running 10 of the 32 GH R-Boxes and 2 of the 110 gh ones.
newbie
Activity: 27
Merit: 0
Trying to run New R-Box 100 GH/s on BFG Miner 4.8.0 win 32.........it will detect device with .... rockminer:all    but I get message RKM0   chip  id:11 out of range.     any guesses?

The original Rboxes do that too.   Does it happen every 5 minutes or so?  Is the Chip ID number always the same or does it change to different numbers?

They do? I've never seen it...

Here is that screenshot I promised.  It finally happened while I was sitting in front of it.  This is running on Win8/64.

http://s30.postimg.org/qk8rv6nyp/BFGsnap_Copy.jpg

B
newbie
Activity: 37
Merit: 0
Any news on implementation of the Antminer S3's? Have quite a few of these that are pretty much useless as of right now for my purposes.
hero member
Activity: 527
Merit: 500
HiveNet - Distributed Cloud Computing
How do I find the serial numbers for them [ASICs]?

If you run BFGMiner with the -d? parameter it will list mining devices with their driver, path, and serial number.

e.g.

Code:
bfgminer -S all --scrypt -d?
 [2014-09-26 00:45:11] Started bfgminer 4.8.0-34-g9c71295
 [2014-09-26 00:45:14] Devices detected:
 [2014-09-26 00:45:14]  CP2102 USB to UART Bridge Controller by Silicon Labs (driver=zeusminer; procs=48; serial=0001; path=/dev/ttyUSB3)
 [2014-09-26 00:45:14]  CP2102 USB to UART Bridge Controller by Silicon Labs (driver=zeusminer; procs=48; serial=0001; path=/dev/ttyUSB1)
 [2014-09-26 00:45:14]  STM32 Virtual COM Port by STMicroelectronics (driver=gridseed; procs=5; serial=8D8513655551; path=/dev/ttyACM1)
 [2014-09-26 00:45:14]  STM32 Virtual COM Port by STMicroelectronics (driver=gridseed; procs=5; serial=8D801F885551; path=/dev/ttyACM0)
4 devices listed

Thanks!
hero member
Activity: 840
Merit: 1002
How do I find the serial numbers for them [ASICs]?

If you run BFGMiner with the -d? parameter it will list mining devices with their driver, path, and serial number.

e.g.

Code:
bfgminer -S all --scrypt -d?
 [2014-09-26 00:45:11] Started bfgminer 4.8.0-34-g9c71295
 [2014-09-26 00:45:14] Devices detected:
 [2014-09-26 00:45:14]  CP2102 USB to UART Bridge Controller by Silicon Labs (driver=zeusminer; procs=48; serial=0001; path=/dev/ttyUSB3)
 [2014-09-26 00:45:14]  CP2102 USB to UART Bridge Controller by Silicon Labs (driver=zeusminer; procs=48; serial=0001; path=/dev/ttyUSB1)
 [2014-09-26 00:45:14]  STM32 Virtual COM Port by STMicroelectronics (driver=gridseed; procs=5; serial=8D8513655551; path=/dev/ttyACM1)
 [2014-09-26 00:45:14]  STM32 Virtual COM Port by STMicroelectronics (driver=gridseed; procs=5; serial=8D801F885551; path=/dev/ttyACM0)
4 devices listed
hero member
Activity: 527
Merit: 500
HiveNet - Distributed Cloud Computing
I have 10 of the original r-boxes and 2 of the new ones. Is there a way to get BFGMiner to run them all together, but set one frequency for the original ones and another for the new ones?

Thanks.

The --set parameter can be used to target specific devices by path or serial number:

Code:
--set rkm@/some/path:clock=XYZ
--set rkm@serial123:clock=ABC

If I understand correctly, the R-boxes generally have the same serial number, so this line would only have to be used signally?

--set rkm@serial123:clock=ABC

Hopefully the new R-boxes will have a different serial.

Sorry, kind of new at digging this deep into them.

If the devices have the same serial number (IOW manufacturer did not set proper information), you would either need to use the device path instead or use a tool to program a serial number on the device(s).

For CP210x-based devices the following tool is relatively painless: http://cp210x-program.sourceforge.net

Could I leave my current setup for the frequency on the older r-boxes and then use the serial frequency command on just the 2 new r-boxes?

Sure it should work.

Sweet. Thank you Sir.

How do I find the serial numbers for them?
legendary
Activity: 1820
Merit: 1001
SO as their been any updates in regards to antminer integration with firrmware or is this now on hold and no longer in coming soon? Would be nice to see a newer version of antminer firmware with bfg integration
full member
Activity: 150
Merit: 100
Does anyone have an old win32 install zip that supports CPU mining?  Everything in the archive has been built without it I believe.

If you are unable to find a link, there are instructions for build for Windows (including CPU mining) here:

https://github.com/luke-jr/bfgminer/blob/bfgminer/windows-build.txt

Thanks.  The last time I built an executable it was 20 years ago :-).  I've never built a windows binary before and it looks quite involved!

If anyone does have a link or zip I would appreciate it.
hero member
Activity: 840
Merit: 1002
Does anyone have an old win32 install zip that supports CPU mining?  Everything in the archive has been built without it I believe.

If you are unable to find a link, there are instructions for build for Windows (including CPU mining) here:

https://github.com/luke-jr/bfgminer/blob/bfgminer/windows-build.txt
full member
Activity: 150
Merit: 100
Does anyone have an old win32 install zip that supports CPU mining?  Everything in the archive has been built without it I believe.
hero member
Activity: 840
Merit: 1002
PMed luke with no reply, so throwing this in here. My test rig is reporting incorrect mhs in the bfgminer api.

http://puu.sh/bJlV6/5b42cc5027.png

Api reported data ^^


http://puu.sh/bJlX5/8539153d87.png

In bfgminer console ^^


any ideas?

What specifically do you see is wrong in the API data?
The MHS says 7,000. When it should say 150.

I'm not sure where you get 150 Mh/s from the output of BFGMiner?

Your BFGMiner screenshot shows you doing 7 Mh/s. That is also what the API is reporting.
The 0.15GH/s ?

That part looks like a bug - your 7 Mh/s of ASICs isn't doing 150 Mh/s unfortunately  Wink
Nah Wink Figured it out, if I didnt set the chip count it reports the wrong MHS. Was still getting the correct MHS on the pools side. --set zus:chips=128

Hoo-ha - nice! I only ever had the 6-chip devices, forgot about needing to set the chip count to get accurate estimates.
Pages:
Jump to: