Bitcoin Forum
February 27, 2017, 09:01:29 PM *
News: Latest stable version of Bitcoin Core: 0.13.2  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 [17] 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 »
  Print  
Author Topic: BFGMiner 5.4.2: GBT+Stratum, RPC, Mac/Linux/Win64, Antminer S1-S5, solo stratum  (Read 526302 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
indigopsy
Member
**
Offline Offline

Activity: 61


View Profile
June 09, 2015, 05:56:19 PM
 #321

Code:
bfgminer -o stratum+tcp://stratum.f2pool.com:3333 -u indigopsy.antminer -p 1234 --set antminer:voltage=x830 --set antminer:clock=x982 --set antminer:timing=0.0054 -S antminer:all
1488229289
Hero Member
*
Offline Offline

Posts: 1488229289

View Profile Personal Message (Offline)

Ignore
1488229289
Reply with quote  #2

1488229289
Report to moderator
1488229289
Hero Member
*
Offline Offline

Posts: 1488229289

View Profile Personal Message (Offline)

Ignore
1488229289
Reply with quote  #2

1488229289
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1488229289
Hero Member
*
Offline Offline

Posts: 1488229289

View Profile Personal Message (Offline)

Ignore
1488229289
Reply with quote  #2

1488229289
Report to moderator
1488229289
Hero Member
*
Offline Offline

Posts: 1488229289

View Profile Personal Message (Offline)

Ignore
1488229289
Reply with quote  #2

1488229289
Report to moderator
Luke-Jr
Legendary
*
Offline Offline

Activity: 2114



View Profile
June 09, 2015, 06:55:42 PM
 #322

I wish 5.2.0 would at least start with my stick miners, I'm at a loss why 5.1.0 works for them but not 5.2.0.
Can you make a session with http://luke.dashjr.org/tmp/code/webisect/webisect.php and bisect the difference? Which stick miners?

Luke-Jr
Legendary
*
Offline Offline

Activity: 2114



View Profile
June 09, 2015, 06:57:09 PM
 #323

5.20 docs say this replaces the older "--no-opencl-binaries" command to ignore using CPU for mining.
These just disable caching of GPU binaries.
It has nothing to do with CPU mining, and has no effect unless you explicitly enable GPU mining.

Mikestang
Hero Member
*****
Offline Offline

Activity: 742



View Profile
June 09, 2015, 08:28:05 PM
 #324

I wish 5.2.0 would at least start with my stick miners, I'm at a loss why 5.1.0 works for them but not 5.2.0.
Can you make a session with http://luke.dashjr.org/tmp/code/webisect/webisect.php and bisect the difference? Which stick miners?
I'll give it a shot after lunch.  I am using Cryptorig HitchHikers, they use the nanofury chip.
Luke-Jr
Legendary
*
Offline Offline

Activity: 2114



View Profile
June 09, 2015, 08:31:31 PM
 #325

I wish 5.2.0 would at least start with my stick miners, I'm at a loss why 5.1.0 works for them but not 5.2.0.
Can you make a session with http://luke.dashjr.org/tmp/code/webisect/webisect.php and bisect the difference? Which stick miners?
I'll give it a shot after lunch.  I am using Cryptorig HitchHikers, they use the nanofury chip.
In that case, can you also try putting the libhidapi-0.dll from 5.1.0 into the 5.2.0 directory?
The hidapi update in 5.2.0 was supposed to only fix bugs, but maybe it introduced new problems too..

Mikestang
Hero Member
*****
Offline Offline

Activity: 742



View Profile
June 09, 2015, 10:19:40 PM
 #326

In that case, can you also try putting the libhidapi-0.dll from 5.1.0 into the 5.2.0 directory?
The hidapi update in 5.2.0 was supposed to only fix bugs, but maybe it introduced new problems too..
Running through the WeBisect now, never done it before so I'm just clicking the skip button each time and letting it crank through...

I tried replacing libhidapi-0.dll from 5.1.0 and still no luck.  I'm also trying both 32 and 64-bit 5.2.0, just in case.

When I start both 5.1.0 and 5.2.0 each stick lights up when "[DATE TIME] Started bfgminer 5.X.0" appears in the command line window, then the lights go out on the sticks.  In 5.1.0 a few seconds pass, then they light up again and bfg launches.  In 5.2.0 they remain dark and the command line window sits at "Started" indefinitely (I've left it alone for over an hour, just to be sure).

Will post up again when webisect is done.
Mikestang
Hero Member
*****
Offline Offline

Activity: 742



View Profile
June 09, 2015, 11:29:09 PM
 #327

Here's the end of the bisect, not sure if I did it correctly or no, please let me know if this is what you were looking for (by the way the "16 revisions left... 4 steps" displayed on every screen of the bisect, I expected the numbers to change but they didn't):

Code:
garbage
Luke-Jr
Legendary
*
Offline Offline

Activity: 2114



View Profile
June 10, 2015, 12:04:55 AM
 #328

You have to actually use it to expect any results... skipping is just a waste of time.
Test each build presented (they are all different) and determine if it's good or bad.
Use a new session name to start over.

Mikestang
Hero Member
*****
Offline Offline

Activity: 742



View Profile
June 10, 2015, 02:57:41 AM
 #329

You have to actually use it to expect any results... skipping is just a waste of time.
Test each build presented (they are all different) and determine if it's good or bad.
Use a new session name to start over.
It said to skip if I was unsure between the other two choices, so I did.  I obviously didn't understand the process. Cheesy

So it gives me a new build at each step, that's what those 32-bit 64-bit links are?  I get it, will try again.

When I am presented the working and non-working entries at the beginning I am changing the version numbers at the end to -5.1.0 and -5.2.0, is that step correct?
Luke-Jr
Legendary
*
Offline Offline

Activity: 2114



View Profile
June 10, 2015, 03:19:34 AM
 #330

It said to skip if I was unsure between the other two choices, so I did.  I obviously didn't understand the process. Cheesy

So it gives me a new build at each step, that's what those 32-bit 64-bit links are?  I get it, will try again.
Yep, exactly. Try to  be sure as often as possible Smiley

When I am presented the working and non-working entries at the beginning I am changing the version numbers at the end to -5.1.0 and -5.2.0, is that step correct?
Yes.

Mikestang
Hero Member
*****
Offline Offline

Activity: 742



View Profile
June 10, 2015, 05:51:31 AM
 #331


i saw in antminer u3 pdf file that there are column for preferred timing


so i take in my case 0.54 and divided it with 100 ms
0.54/100 = 0.0054


That makes sense.

But I wonder, then, where the value in the README "--set antminer:clock=x1286 --set antminer:timing=0.022421" came from. According the the U3 documentation the timeout for 1286 should be 0.0057.  Unfortunately for me, either value ends in the same result: my U3 starts, but rapidly the hash drops to 0 and the unit goes SICK.  By trying several combos I've gotten it to start hashing as high as 40GH/s, but it only lasts seconds.

BTW, this is a completely separate computer and location from my stick miners.


EDIT

Just started messing around with the timeout, using a voltage of x785 and freq of x1286.  When I entered 0.02 the U3 stayed alive!  It's hashing away at 48GH/s, which is about what I would expect for the volt/freq combo.  Could it be that timeout in the user guide is not the same as timing in bfg?  I need more insight into how to determine the timing value...


EDIT 2

It's sick again.  Well, getting somewhere at least.
Luke-Jr
Legendary
*
Offline Offline

Activity: 2114



View Profile
June 10, 2015, 10:37:10 AM
 #332

But I wonder, then, where the value in the README "--set antminer:clock=x1286 --set antminer:timing=0.022421" came from. According the the U3 documentation the timeout for 1286 should be 0.0057.
It came from weeks of statistical measurement. In theory, you could leave timing out and BFGMiner will autodetect it, but setting it correctly gets better performance, at least at the start.
The U3 PDF (which I didn't see until after release) is giving you a "Prefer timeout" time, which is not the same thing.
The timing option is measured in microseconds per hash, while the timeout would be per 232 hashes and probably cut-off early to give some breathing room.

It's sick again.  Well, getting somewhere at least.
I saw that a few months ago, but never figured out what caused it... before I released, it had run fine for at least a month straight, so I didn't really have any way to troubleshoot further. Sad

Mikestang
Hero Member
*****
Offline Offline

Activity: 742



View Profile
June 10, 2015, 05:01:50 PM
 #333

It came from weeks of statistical measurement. In theory, you could leave timing out and BFGMiner will autodetect it, but setting it correctly gets better performance, at least at the start.

I did try leaving it out and got the same result as having a, for lack of better term, bad value plugged in - start about 10GH/s and decline toward 0.

I do not have the means to make statistical measurements, and from what I've been told and experienced with 3 U3s myself is that each one is different and will react to volt/freq settings uniquely, so I wouldn't be surprised if each machine had a slightly different timing value that it preferred.  I do have the brute force method, so I'll keep playing with the timing on one unit and see if I can keep it alive for more than a few minutes.  0.021, for example, would error out and only 2 of the 4 chips would be seen by bfg.  I'll start at 0.020001 and work my way up, hopefully there's a sweet spot in there somewhere.
Mikestang
Hero Member
*****
Offline Offline

Activity: 742



View Profile
June 10, 2015, 08:34:57 PM
 #334

Brought one U3 to the same location as my stick miners, stopped 5.1.0 that was running the sticks, started 5.2.0 for the U3 like I did at home and it just hangs at the "Started" line.  So that issue is not related to the stick miners, it's related to this machine.  I'll run through bisect this afternoon and see if I can't find a build that works on this box.

Here are the bisect results, several builds worked (meaning the launched and started hashing with the sticks), several did not (they just hung at the "Started..." line):

Code:
d50810f29f9a91e3303d512e8b16ef3945c51b4f is the first bad commit
commit d50810f29f9a91e3303d512e8b16ef3945c51b4f
Author: Luke Dashjr
Date:   Thu Feb 26 09:07:01 2015 +0000

    icarus: Replace decisecond-precision read_count with read_timeout_ms (millisecond precision) to handle faster devices like the Antminer U3 that complete works in under 1ds

:100644 100644 7575642899d830643cc4e1501ce9f551e707338b 2466fffdc896fbbcf834545fa7088a17eb470f04 M driver-antminer.c
:100644 100644 cf0d204e21412dcf141099ff1d16931110bb05e8 5c81a397e619339e16c72ce243d0a0ad17d60c06 M driver-cairnsmore.c
:100644 100644 90df94dc10fbce615610e8fe0776298592d55cea 5600260971b094b9437b0b7c5126793094189a53 M driver-dualminer.c
:100644 100644 dcf715476bc3ea6461dec2eed9543b6d6268683a 4435d662abad17515c29b873b262bde821b06220 M driver-icarus.c
:100644 100644 7b1bf695cedf54d6b5d2f1ea74fa1693e3ffa67b 937eebaa82bc1748dd523f63355439af21b183ea M driver-icarus.h
:100644 100644 09be0f9d9ebca3af2c9363bada4e10d6de30017e 47b33dc50431f4dd6fb77916eb2969672aa12247 M driver-zeusminer.c

Would love to get 5.2.0 working at this location, as this is where I want to use my U3s.  Thanks!
johnsquared2
Newbie
*
Offline Offline

Activity: 14


View Profile
June 11, 2015, 03:03:45 PM
 #335

Hi, I am pretty new to this stuff and need some help...

I have 7 GAW Miner Furys (basically a 6 chip Blizzard it appears) and I was running BFGMiner 4.2.2 with zeus support.

I have it available for rent at Betarigs, but it started running into issues when pointed to some pools. The problem was the DIff would goto 2K on a pool that only had a 38 Diff. I guess there are 2 ways of putting out DIff, one needs to be divided by 8 (or some #...) and 4.2.2 was having issues identifying it.

So I changed to a newer CGMiner, but it does not produce the same HR as BFGminer did.

Can someone point me to where I can find a Win32/64 compiled executable that is Zeus compatible?

I've tried 5.2, but always get Device not found or similar error...

Thanks,
J
movellan
Full Member
***
Offline Offline

Activity: 232


View Profile
June 11, 2015, 03:45:41 PM
 #336

But I wonder, then, where the value in the README "--set antminer:clock=x1286 --set antminer:timing=0.022421" came from. According the the U3 documentation the timeout for 1286 should be 0.0057.
It came from weeks of statistical measurement. In theory, you could leave timing out and BFGMiner will autodetect it, but setting it correctly gets better performance, at least at the start.
The U3 PDF (which I didn't see until after release) is giving you a "Prefer timeout" time, which is not the same thing.
The timing option is measured in microseconds per hash, while the timeout would be per 232 hashes and probably cut-off early to give some breathing room.

It's sick again.  Well, getting somewhere at least.
I saw that a few months ago, but never figured out what caused it... before I released, it had run fine for at least a month straight, so I didn't really have any way to troubleshoot further. Sad

Luke-Jr,

We need some help here. A few of us here and over on the U3 support thread are having a devil of a time getting 5.20 to recognize the U3. I have tried about every combo possible and have also tried a new machine that has never had any BTC mining software installed. Had very good luck with the x64 version running the Antminer U1 and U2 units, but cannot get 5.20 to detect U3's. Any help appreciated. TIA.
movellan
Full Member
***
Offline Offline

Activity: 232


View Profile
June 11, 2015, 03:47:56 PM
 #337

Code:
bfgminer -o stratum+tcp://stratum.f2pool.com:3333 -u indigopsy.antminer -p 1234 --set antminer:voltage=x830 --set antminer:clock=x982 --set antminer:timing=0.0054 -S antminer:all

Thanks for the help. Unfortunately no cigar. U3's still not recognized.
Mikestang
Hero Member
*****
Offline Offline

Activity: 742



View Profile
June 11, 2015, 04:49:18 PM
 #338

Brought one U3 to the same location as my stick miners, stopped 5.1.0 that was running the sticks, started 5.2.0 for the U3 like I did at home and it just hangs at the "Started" line.  So that issue is not related to the stick miners, it's related to this machine.  I'll run through bisect this afternoon and see if I can't find a build that works on this box.

Here are the bisect results, several builds worked (meaning the launched and started hashing with the sticks), several did not (they just hung at the "Started..." line):

Code:
d50810f29f9a91e3303d512e8b16ef3945c51b4f is the first bad commit
commit d50810f29f9a91e3303d512e8b16ef3945c51b4f
Author: Luke Dashjr
Date:   Thu Feb 26 09:07:01 2015 +0000

    icarus: Replace decisecond-precision read_count with read_timeout_ms (millisecond precision) to handle faster devices like the Antminer U3 that complete works in under 1ds

:100644 100644 7575642899d830643cc4e1501ce9f551e707338b 2466fffdc896fbbcf834545fa7088a17eb470f04 M driver-antminer.c
:100644 100644 cf0d204e21412dcf141099ff1d16931110bb05e8 5c81a397e619339e16c72ce243d0a0ad17d60c06 M driver-cairnsmore.c
:100644 100644 90df94dc10fbce615610e8fe0776298592d55cea 5600260971b094b9437b0b7c5126793094189a53 M driver-dualminer.c
:100644 100644 dcf715476bc3ea6461dec2eed9543b6d6268683a 4435d662abad17515c29b873b262bde821b06220 M driver-icarus.c
:100644 100644 7b1bf695cedf54d6b5d2f1ea74fa1693e3ffa67b 937eebaa82bc1748dd523f63355439af21b183ea M driver-icarus.h
:100644 100644 09be0f9d9ebca3af2c9363bada4e10d6de30017e 47b33dc50431f4dd6fb77916eb2969672aa12247 M driver-zeusminer.c

Would love to get 5.2.0 working at this location, as this is where I want to use my U3s.  Thanks!

Did some more digging, I've determined it is the -S command in my batch file that causes 5.2.0 to hang.  If I remove the -S command it starts just fine.  If I try add the device from within bfg (M and +) and scan "all", the program hangs.  If I do M + and "auto", it gives No new devices found, which follows from the readme that says the U3 won't autodetect.  It seems the bug is related to scan all, whether done via batch file (-S all and/or -S antminer:all) or from within the program itself.

If I remove the -S/--scan command then 5.2.0 starts just find and hashes away with the nanofury sticks, they don't need to be scanned for apparently.

So something on this particular computer causes the device scan to go on and on and on and on and the U3 needs to be scanned to be seen... anyone have advice how to work around this?  Or how I could scan specifically for my U3 and not have to "scan all"?  Like how do I tell it to only scan the USB devices?

I wonder why -S all works in 5.1.0, but hangs in 5.2.0 on this box.  Weird and frustrating!
Mikestang
Hero Member
*****
Offline Offline

Activity: 742



View Profile
June 11, 2015, 06:58:55 PM
 #339

tl;dr How do I scan specifically for the usb U3, and not "scan all"?
Luke-Jr
Legendary
*
Offline Offline

Activity: 2114



View Profile
June 11, 2015, 09:28:56 PM
 #340

tl;dr How do I scan specifically for the usb U3, and not "scan all"?
-S antminer:all will probe all devices with only the antminer driver.
Unfortunately, Antminer still does not set the product name on their devices, so there is no way to identify what devices they are without probing.
By default, BFGMiner only probes identified devices, not "scan all"; if you want to turn even that off, use -S noauto

P.S. Due to more pressing issues (medical), I will may sporadically have less time to work on things. Please open GitHub issues for problems so I don't forget about them, and thanks for your patience.

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 [17] 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!