Mikestang
Legendary
Offline
Activity: 1274
Merit: 1000
|
|
June 10, 2015, 02:57:41 AM |
|
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. 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 (OP)
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
June 10, 2015, 03:19:34 AM |
|
It said to skip if I was unsure between the other two choices, so I did. I obviously didn't understand the process. 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 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
Legendary
Offline
Activity: 1274
Merit: 1000
|
|
June 10, 2015, 05:51:31 AM Last edit: June 10, 2015, 06:10:53 AM by Mikestang |
|
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 (OP)
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
June 10, 2015, 10:37:10 AM |
|
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 2 32 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.
|
|
|
|
Mikestang
Legendary
Offline
Activity: 1274
Merit: 1000
|
|
June 10, 2015, 05:01:50 PM |
|
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
Legendary
Offline
Activity: 1274
Merit: 1000
|
|
June 10, 2015, 08:34:57 PM Last edit: June 10, 2015, 09:24:29 PM by Mikestang |
|
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): 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
Activity: 15
Merit: 0
|
|
June 11, 2015, 03:03:45 PM |
|
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
|
|
June 11, 2015, 03:45:41 PM |
|
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 2 32 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. 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
|
|
June 11, 2015, 03:47:56 PM |
|
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
Legendary
Offline
Activity: 1274
Merit: 1000
|
|
June 11, 2015, 04:49:18 PM Last edit: June 11, 2015, 05:12:18 PM by Mikestang |
|
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): 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
Legendary
Offline
Activity: 1274
Merit: 1000
|
|
June 11, 2015, 06:58:55 PM |
|
tl;dr How do I scan specifically for the usb U3, and not "scan all"?
|
|
|
|
Luke-Jr (OP)
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
June 11, 2015, 09:28:56 PM |
|
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 noautoP.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.
|
|
|
|
Mikestang
Legendary
Offline
Activity: 1274
Merit: 1000
|
|
June 11, 2015, 09:52:07 PM |
|
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 noautoP.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.
|
|
|
|
Luke-Jr (OP)
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
June 11, 2015, 09:58:49 PM |
|
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 noautoP.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
|
|
|
|
toptek
Legendary
Offline
Activity: 1274
Merit: 1000
|
|
June 11, 2015, 10:26:19 PM |
|
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 . ...
|
|
|
|
Luke-Jr (OP)
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
June 11, 2015, 10:39:02 PM |
|
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 . ... 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.
|
|
|
|
Mikestang
Legendary
Offline
Activity: 1274
Merit: 1000
|
|
June 12, 2015, 07:28:12 AM |
|
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 noautoP.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.
|
|
|
|
FlensGold
Legendary
Offline
Activity: 1405
Merit: 1001
|
|
June 15, 2015, 05:33:05 PM |
|
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?
|
|
|
|
Mikestang
Legendary
Offline
Activity: 1274
Merit: 1000
|
|
June 17, 2015, 03:47:45 PM |
|
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.
|
|
|
|
Malaki
Newbie
Offline
Activity: 16
Merit: 0
|
|
June 18, 2015, 02:28:24 PM |
|
damn thats not usefull for me
|
|
|
|
|