OLD: BFGMiner 3.10.0: modular ASIC+FPGA, GBT+Strtm, RPC, Mac/Lnx/W64, AntU1, DRB

[Trance104]

After using BFG miner on my SC Single, it eventually errored out. When I restarted it, it now only picks my graphics cards.

Has anyone experienced this? Is there any way I can trouble shoot it? I didn't alter anything. I can't figure it out.

[1714886563]

1714886563

[1714886563]

1714886563

[1714886563]

1714886563

[1714886563]

1714886563

[1714886563]

1714886563

[E-TARD]

I don't really care about scrypt.
If you (or anyone else) can bisect it, debug it, or provide a patch, I'll look into it...
If you use Windows, you can easily bisect by starting a new session on http://luke.dashjr.org/tmp/code/webisect/webisect.php

could you fix the pool diff in scrypt?
its always Diff 0/0   
that's the only thing that I can see needs fixing.

[Luke-Jr]

I don't really care about scrypt.
If you (or anyone else) can bisect it, debug it, or provide a patch, I'll look into it...
If you use Windows, you can easily bisect by starting a new session on http://luke.dashjr.org/tmp/code/webisect/webisect.php

could you fix the pool diff in scrypt?
its always Diff 0/0   
that's the only thing that I can see needs fixing.

That sounds correct. It's very hard to get diff 1 with scrypt.

[pengoau]

I have that specified.

Its reporting correctly with the stable release but not with the latest release. Is this due to cgminer dropping gpu support after 3.7.2? Or something else?

I've also tried v3.5.0 with the same command line as the stable release and it reports in Gh/sec. So only the stable release of v3.2.8 reports correctly for me.

Am I missing something for the latest version?

My command line is:

bfgminer --scrypt -o stratum+tcp://ctompo.dyndns.org:3332 -u pengo.0 -p x -I 20 --auto-fan --temp-overheat 80 --temp-cutoff 85 --temp-target 70

tldr: Reports correctly in kH/sec  in v3.2.8, newer versions tested v3.5.0 and latest release it reports in gH/sec (same cmd line)..

Thanks for your help if you can assist.

I don't really care about scrypt.
If you (or anyone else) can bisect it, debug it, or provide a patch, I'll look into it...
If you use Windows, you can easily bisect by starting a new session on http://luke.dashjr.org/tmp/code/webisect/webisect.php

Thanks for your response.

I don't code so thats not workable unfortunately, I was hoping someone here (if not the dev ie you) could get it to work in the latest build. As it seems to be broken in all builds except stable.

Tho since you don't care for it, you should disable it in the source like cgminer's dev? And have scrypt not supported past the stable release.

I'm not complaining as its free software.

[E-TARD]

I don't really care about scrypt.
If you (or anyone else) can bisect it, debug it, or provide a patch, I'll look into it...
If you use Windows, you can easily bisect by starting a new session on http://luke.dashjr.org/tmp/code/webisect/webisect.php

could you fix the pool diff in scrypt?
its always Diff 0/0   
that's the only thing that I can see needs fixing.

That sounds correct. It's very hard to get diff 1 with scrypt.

what your saying makes no sense


I mine on litecoinpool.org they start out with pool Diff 32 & if your hash is slow you will get kicked down to 16 or 8 but no lower
& when I use bfgminer what do I see Diff 0/0 so that tells me there is something worng with bfgminer when doing scrypt.
cgminer v3.7.2 works fine with scrypt 80/16
but I'm not a big fan of cgminer & cgminer has droped scrypt & GPU support.
So I had hoped that you would fix it but by the looks of things

I don't really care about scrypt

that's not going to happen, maybe someone will do a scrypt fork of bfgminer or cgminer
thanks for your time anyways

[jedimstr]

I don't really care about scrypt.
If you (or anyone else) can bisect it, debug it, or provide a patch, I'll look into it...
If you use Windows, you can easily bisect by starting a new session on http://luke.dashjr.org/tmp/code/webisect/webisect.php

could you fix the pool diff in scrypt?
its always Diff 0/0   
that's the only thing that I can see needs fixing.

That sounds correct. It's very hard to get diff 1 with scrypt.

what your saying makes no sense


I mine on litecoinpool.org they start out with pool Diff 32 & if your hash is slow you will get kicked down to 16 or 8 but no lower
& when I use bfgminer what do I see Diff 0/0 so that tells me there is something worng with bfgminer when doing scrypt.
cgminer v3.7.2 works fine with scrypt 80/16
but I'm not a big fan of cgminer & cgminer has droped scrypt & GPU support.
So I had hoped that you would fix it but by the looks of things

I don't really care about scrypt

that's not going to happen, maybe someone will do a scrypt fork of bfgminer or cgminer
thanks for your time anyways

The Litecoin Mining forum has forks of CGMiner already being alpha-tested.

[Taugeran]

i cannot for the life of me get a brand new beaglebone black to find hidapi when configuring bfgminer tried all solutions i could find and still nope :/

halp

[HellDiverUK]

i cannot for the life of me get a brand new beaglebone black to find hidapi when configuring bfgminer tried all solutions i could find and still nope :/

Did you actually install hidapi?  You have to install it first, before installing BFGMiner.  Details are on the README.txt on the hidapi git page.

I tried to install it myself on Ubuntu Server 13.10, but it wouldn't compile, so I'm missing hidapi at the moment myself.

[Taugeran]

i cannot for the life of me get a brand new beaglebone black to find hidapi when configuring bfgminer tried all solutions i could find and still nope :/

Did you actually install hidapi?  You have to install it first, before installing BFGMiner.  Details are on the README.txt on the hidapi git page.

I tried to install it myself on Ubuntu Server 13.10, but it wouldn't compile, so I'm missing hidapi at the moment myself.

a quick issuance of

Code:

find / | grep libhidapi-*

showed hidraw and libusb were installed to /usr/local/lib

[juhakall]

I don't really care about scrypt.
If you (or anyone else) can bisect it, debug it, or provide a patch, I'll look into it...
If you use Windows, you can easily bisect by starting a new session on http://luke.dashjr.org/tmp/code/webisect/webisect.php

could you fix the pool diff in scrypt?
its always Diff 0/0    
that's the only thing that I can see needs fixing.

That sounds correct. It's very hard to get diff 1 with scrypt.

what your saying makes no sense


I mine on litecoinpool.org they start out with pool Diff 32 & if your hash is slow you will get kicked down to 16 or 8 but no lower
& when I use bfgminer what do I see Diff 0/0 so that tells me there is something worng with bfgminer when doing scrypt.
cgminer v3.7.2 works fine with scrypt 80/16

BFGMiner is showing the correct difficulty numbers. They are just so small they get rounded to 0. "Diff 32" is actually Diff 0.00048828125. cgminer is using the same conversion scheme that pools use, where all difficulties are multiplied by 65536. Except that even cgminer has now dropped that conversion in the block difficulty number. If only that conversion scheme had never been implemented, all this confusion could've been avoided.

I guess the conversion scheme was done because decimal numbers are thought of as inconvenient. Because scrypt mining is about a thousand times slower than sha256 on GPUs, it would take a thousand times longer to mine Diff 1 shares. Thus no pool would ever set a real target of even 1 for a worker. Then someone came up with the genius idea of multiplying everything by 65536 so it looks neater. Sheesh.

[rahlquist]

BFGMiner is showing the correct difficulty numbers. They are just so small they get rounded to 0. "Diff 32" is actually Diff 0.00048828125. cgminer is using the same conversion scheme that pools use, where all difficulties are multiplied by 65536. Except that even cgminer has now dropped that conversion in the block difficulty number. If only that conversion scheme had never been implemented, all this confusion could've been avoided.

I guess the conversion scheme was done because decimal numbers are thought of as inconvenient. Because scrypt mining is about a thousand times slower than sha256 on GPUs, it would take a thousand times longer to mine Diff 1 shares. Thus no pool would ever set a real target of even 1 for a worker. Then someone came up with the genius idea of multiplying everything by 65536 so it looks neater. Sheesh.

Thank you for explaining this. Makes a lot of sense.

[Trance104]

After using BFG miner on my SC Single, it eventually errored out. When I restarted it, it now only picks my graphics cards.

Has anyone experienced this? Is there any way I can trouble shoot it? I didn't alter anything. I can't figure it out.

[RicRock]

showed hidraw and libusb were installed to /usr/local/lib

https://bitcointalk.org/index.php?topic=137934.msg3879613#msg3879613

[prehistoric]

i cannot for the life of me get a brand new beaglebone black to find hidapi when configuring bfgminer tried all solutions i could find and still nope :/

Tried solution for ArchLinux on Raspberry-Pi:
1) wget https://aur.archlinux.org/packages/hi/hidapi-git/hidapi-git.tar.gz
2) tar -xf ./hidapi-git.tar.gz
3) cd ./hidapi-git
4) change in PKGBUILD file:
 a) arch=(i686 x86_64) to arch=(armv6h)
You might have to change arch=(armv**) to more appropriate for beaglebone (armv7?).
 b) depends=('systemd-tools' 'libusbx' 'fox') to depends=('systemd-tools' 'libusbx')
 c) ./configure --enable-testgui --prefix=/usr to ./configure --prefix=/usr
5) in hidapi-git directory run makepkg --asroot
6) pacman -U ./hidapi-git-354.1a42177-1-armv6h.pkg.tar.xz
This allows to install and remove hidapi as a package cleanly.
7) configure bfgminer < 3.8.1
./configure --disable-avalon --disable-opencl --disable-adl --disable-hashbuster --disable-hashbuster2 --disable-bitforce --disable-klondike --disable-modminer --disable-x6500 --disable-ztex --without-sensors --without-libmicrohttpd
In 3.8.1 hashbuster2 changed to hashbusterusb
UPD: yet configure option still the same - no need to change here.
UPD2: I'm wrong it has been changed, but not in README

HTH!

[Taugeran]

i cannot for the life of me get a brand new beaglebone black to find hidapi when configuring bfgminer tried all solutions i could find and still nope :/

Tried solution for ArchLinux on Raspberry-Pi:
1) wget https://aur.archlinux.org/packages/hi/hidapi-git/hidapi-git.tar.gz
2) tar -xf ./hidapi-git.tar.gz
3) cd ./hidapi-git
4) change in PKGBUILD file:
 a) arch=(i686 x86_64) to arch=(armv6h)
You might have to change arch=(armv**) to more appropriate for beaglebone (armv7?).
 b) depends=('systemd-tools' 'libusbx' 'fox') to depends=('systemd-tools' 'libusbx')
 c) ./configure --enable-testgui --prefix=/usr to ./configure --prefix=/usr
5) in hidapi-git directory run makepkg --asroot
6) pacman -U ./hidapi-git-354.1a42177-1-armv6h.pkg.tar.xz
This allows to install and remove hidapi as a package cleanly.
7) configure bfgminer < 3.8.1
./configure --disable-avalon --disable-opencl --disable-adl --disable-hashbuster --disable-hashbuster2 --disable-bitforce --disable-klondike --disable-modminer --disable-x6500 --disable-ztex --without-sensors --without-libmicrohttpd
In 3.8.1 hashbuster2 changed to hashbusterusb
UPD: yet configure option still the same - no need to change here.
UPD2: I'm wrong it has been changed, but not in README

HTH!

[E-TARD]

I don't really care about scrypt.
If you (or anyone else) can bisect it, debug it, or provide a patch, I'll look into it...
If you use Windows, you can easily bisect by starting a new session on http://luke.dashjr.org/tmp/code/webisect/webisect.php

could you fix the pool diff in scrypt?
its always Diff 0/0    
that's the only thing that I can see needs fixing.

That sounds correct. It's very hard to get diff 1 with scrypt.

what your saying makes no sense


I mine on litecoinpool.org they start out with pool Diff 32 & if your hash is slow you will get kicked down to 16 or 8 but no lower
& when I use bfgminer what do I see Diff 0/0 so that tells me there is something worng with bfgminer when doing scrypt.
cgminer v3.7.2 works fine with scrypt 80/16

BFGMiner is showing the correct difficulty numbers. They are just so small they get rounded to 0. "Diff 32" is actually Diff 0.00048828125. cgminer is using the same conversion scheme that pools use, where all difficulties are multiplied by 65536. Except that even cgminer has now dropped that conversion in the block difficulty number. If only that conversion scheme had never been implemented, all this confusion could've been avoided.

I guess the conversion scheme was done because decimal numbers are thought of as inconvenient. Because scrypt mining is about a thousand times slower than sha256 on GPUs, it would take a thousand times longer to mine Diff 1 shares. Thus no pool would ever set a real target of even 1 for a worker. Then someone came up with the genius idea of multiplying everything by 65536 so it looks neater. Sheesh.

Oh WoW I did not know that, thanks for the info juhakall 
It sure would have been nice for Luke-Jr to post that info somewhere on the bfgminer github page.

@Luke-Jr I can't get my USB block erupters to work on bfgminer.
I run Gentoo & they never show up in /dev/ttyUSB0 the way you keep saying it does, I have done everything I can think of & than some.
the only thing I ever find is this, here's the path to one of them /dev/bus/usb/01/016
& that's info that comes up with lsusb. I have CP210x all setup in my kernel
CONFIG_USB_SERIAL_CP210X=m   should it not be a module? should I bake it into the kernel?
well anyways they run ok on cgminer with no problems but I would love to have them to run on bfgminer someday. 

I only use bfgminer for my block erupter blades because my block erupter blades don't like "stratum-mining-proxy" but they like "bfgminer stratum-proxy" kind of odd but its all good. 

[Taugeran]

just curious for an explaination of this snippet of code from driver-bitfury.c:


in bitfury_init_oldbuf

Code:

        if (tried > 3)
        {
                applog(LOG_ERR, "%"PRIpreprv": %s: Giving up after %d tries",
                       proc->proc_repr, __func__, tried);
                bitfury->desync_counter = 99;
                return false;
        }

i have one NF1 that seems to throw it incessantly after a period of time if i set the osc6 above 52. this is on a BBB(independantly powered) linked into a dlink DUB-H7/B powered with a 2.5A supply.

also on the hub is another NF1(runs fine at 54 bits) and a pencil modded BPMC BF1.

for shits and giggles ive changed the supply to the dlink to a 3.5A to see if theres a difference.



TL;DR

is that tidbit of code an indication the chip is power starved for the frequency it is set at?

[poplolnman]

thanks for your hard work!!!

[HellDiverUK]

@Luke-Jr I can't get my USB block erupters to work on bfgminer.
I run Gentoo & they never show up in /dev/ttyUSB0 the way you keep saying it does, I have done everything I can think of & than some.

Well, there's something broken with your install, because they should appear as /dev/ttyUSB* - they do on any Linux/linux-based OS I've seen, even on OpenWRT.

Do you have the VCP drivers installed?

[bitcoinmining]

I've gained a lot with this method I would recommend to anyone to start winning start already miner