Pages:
Author

Topic: BFGMiner 5.5.0: CPU/GPU/FPGA/ASIC mining software, GBT+Stratum, RPC, Linux/Win64 - page 44. (Read 834576 times)

legendary
Activity: 2576
Merit: 1186
Can you pastebin a debuglog of the detection (output of bfgminer -d? -D)?

Maybe you can use the serial number (IIRC, always 0001 for U3s): -S antminer@0001


"-S antminer@0001" worked, 5.2.0 launched and saw the U3, however I cannot get it to hash greater than 1GH/s, and then it decrease to SICK rapidly (a result of freq/volt/timing settings I'm sure, still need to figure out some values there).

"bfgminer -d antminer" also worked, but since it only detects antminer machines that way it does not start my netfury sticks (as expected).

"bfgminer -D" runs in debug mode but I do not know if/where it creates an output file.  I assume you want me to run -D with "-S all" to see where the device scan hangs, correct?

Thanks again for the help.
The exact command is: bfgminer -d? -D -S all
Post the full output in a [ code] block here.
newbie
Activity: 16
Merit: 0
damn thats not usefull for me Sad
legendary
Activity: 1274
Merit: 1000
Can you pastebin a debuglog of the detection (output of bfgminer -d? -D)?

Maybe you can use the serial number (IIRC, always 0001 for U3s): -S antminer@0001


"-S antminer@0001" worked, 5.2.0 launched and saw the U3, however I cannot get it to hash greater than 1GH/s, and then it decrease to SICK rapidly (a result of freq/volt/timing settings I'm sure, still need to figure out some values there).

"bfgminer -d antminer" also worked, but since it only detects antminer machines that way it does not start my netfury sticks (as expected).

"bfgminer -D" runs in debug mode but I do not know if/where it creates an output file.  I assume you want me to run -D with "-S all" to see where the device scan hangs, correct?

Thanks again for the help.
legendary
Activity: 1405
Merit: 1001
Hello,
I have a KNC Titan with the latest 2.0 firmware installed.
This firmware includes bfgminer 5.1.
Is there a way to update this bfgminer version? Does it make any sense at all?

Would a freshly installed raspbian with a git clone compiled bfg miner be able to handle the cubes? Did anyone test this?
legendary
Activity: 1274
Merit: 1000
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.

-S antminer:all also causes 5.2.0 to hang.  Is there something I can put in place of 'all' that would direct the scan to look at, say, only USB devices?  It's something about the "all" that's freezing 5.2.0 on this system.
Probably best to just figure out what that is, and fix that.
Can you pastebin a debuglog of the detection (output of bfgminer -d? -D)?

I guess I'm looking for something like what's in the device manager "For example: erupter:\\.\COM40" that would be tailored toward the U3.  Something less encompassing than "all" that will id the U3.
Since the U3 doesn't identify itself, there isn't anything good for this.
Maybe you can use the serial number (IIRC, always 0001 for U3s): -S antminer@0001


Thanks for the suggestions, I won't be able to try them until Tuesday, though.  Will report back next week.

Hope your wife is ok, take care.
legendary
Activity: 2576
Merit: 1186

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.


I hope don't seem off base or insensitive by asking and hope your OK .



Any idea as to when we might see something for S5 with BFG, I do hope your ok and can do more for us.
 
Hope that happens for S5's .

I mean that . Smiley ...
Everyone is okay, but my wife has a medical condition that will need monitoring 1.5 hours away and possibly emergency surgery, so it's apt to be a bit time-consuming. Thanks for asking.

As for S5, there is still a lot of work before it is at a usable state, especially since I basically need to reverse-engineer Bitmain's code to understand what everything does (I miss the good documentation other now-defunct vendors, despite their other deficiencies, put out).
I would expect at least another month or two, depending on how much time I can spend on it.
legendary
Activity: 1274
Merit: 1000

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.


I hope don't seem off base or insensitive by asking and hope your OK .



Any idea as to when we might see something for S5 with BFG, I do hope your ok and can do more for us.
 
Hope that happens for S5's .

I mean that . Smiley ...
legendary
Activity: 2576
Merit: 1186
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.

-S antminer:all also causes 5.2.0 to hang.  Is there something I can put in place of 'all' that would direct the scan to look at, say, only USB devices?  It's something about the "all" that's freezing 5.2.0 on this system.
Probably best to just figure out what that is, and fix that.
Can you pastebin a debuglog of the detection (output of bfgminer -d? -D)?

I guess I'm looking for something like what's in the device manager "For example: erupter:\\.\COM40" that would be tailored toward the U3.  Something less encompassing than "all" that will id the U3.
Since the U3 doesn't identify itself, there isn't anything good for this.
Maybe you can use the serial number (IIRC, always 0001 for U3s): -S antminer@0001
legendary
Activity: 1274
Merit: 1000
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.

-S antminer:all also causes 5.2.0 to hang.  -S antminer in the bat file will launch, but bfg doesn't see the U3 with that.  Is there something I can put in place of 'all' that would direct the scan to look at, say, only USB devices?  It's something about the "all" that's freezing 5.2.0 on this system.

-S noauto in the bat file works in so far as bfg will launch with that command in the file, but then I have to use device manager in 5.2.0 to scan auto for the nanofury sticks, so really no point.  I tried "Enter target:antminer" in the device manager, but no luck.

I guess I'm looking for something like what's in the device manager "For example: erupter:\\.\COM40" that would be tailored toward the U3.  Something less encompassing than "all" that will id the U3.

I've never used GitHub, I'll see if I can't figure out how to report a problem there. Judging by my go with bisect, it may take me a round or two to figure it out.
legendary
Activity: 2576
Merit: 1186
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.
legendary
Activity: 1274
Merit: 1000
tl;dr How do I scan specifically for the usb U3, and not "scan all"?
legendary
Activity: 1274
Merit: 1000
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!
full member
Activity: 368
Merit: 100
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.
full member
Activity: 368
Merit: 100
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.
newbie
Activity: 15
Merit: 0
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
legendary
Activity: 1274
Merit: 1000
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!
legendary
Activity: 1274
Merit: 1000
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.
legendary
Activity: 2576
Merit: 1186
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
legendary
Activity: 1274
Merit: 1000

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.
legendary
Activity: 2576
Merit: 1186
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.
Pages:
Jump to: