If you don't specify stratum+tcp:// cgminer will try a few different ways to connect first. Some pools might not like the multiple attempts to connect so it is always cleaner and faster to specify the stratum+tcp:// prefix.
Thanks for mentioning this! I'd been having a problem connecting to ghash.io, it would always take ~5 minutes after a miner restart. Specifying the stratum+tcp:// removed this delay. |
|
|
|
Ubuntu 13.10 checking for UDEV... no
configure: error: Missing required libudev dev
but libudev-dev is installed  Do you have pkgconf installed? Someone mentioned that libudev-dev doesn't get detected without it. On Debian the package name is pkg-config, dunno what it is on Ubuntu. |
|
|
|
|
I've already traded with 3 users on this thread, hendo420, Blazr2 & shakezula. All smooth transactions. Thanks!
Still got a few more, if anyone's interested. I'll likely not be able to answer PMs for a few hours, though.
|
|
|
|
Just installed my 3 new H-Boards with pencil mod... They ran at 25Gh, 25Gh, and 31Gh out of the box. Now they are doing 32Gh, 35Gh, and 35Gh... All around 1.72-1.73k Ohm resistance on that R02F resistor. So far, I'm very happy. Pictures here: http://imgur.com/a/45QmA#0Well I woke up all three of my new boards not hashing anymore... I think I want to vomit. Any suggestions to try to with my multi-meter? Get an IR thermometer and make sure the regulators aren't running too hot. I've had boards go dark like that, and usually a full poweroff is required to fix the situation. Also, this might be related: https://bitcointalk.org/index.php?topic=250249.msg3099676;topicseen#msg3099676 |
|
|
|
Guys Why is it that the returns we get from mining are not even 50% of exepcted ? Huh? I just mined 0.60353655 BTC during the last 24 hours with 250 GH/s. Expected reward was only 0.469607 BTC. Are you talking about some longer time period? |
|
|
|
I tried to run this on Jalapeno. I uncommented #define __PRODUCT_MODEL_JALAPENO__ in std_defs.h and compiled without any problem but after programing LED didn't flash.
It's likely not working because this firmware tries to activate engine 0 on all chips. Jalapenos don't support that. |
|
|
|
^^ perfect, thanks.. will go fix all my scripts.. Might want to update miner.php while you're at it to work with the API changes.
It already does. There is a $per_proc setting which controls how the data is displayed. |
|
|
|
I've heard of three people in the last 24 hours who received their miners with an empty file in place of the miner program. This will obviously prevent the miner from working, but fortunately it's easy to check & fix: An empty miner file looks like this: ls -la /opt/bitfury/chainminer/miner
-rwxr-xr-x 1 pi pi 0 Oct 2 10:05 /opt/bitfury/chainminer/miner
If your miner doesn't work and you can see an empty file like above, just run this and wait for the compilation process (~5 minutes): cd /opt/bitfury/chainminer && sudo make clean && sudo make |
|
|
|
There is a strange delay when connecting to the pool after restarting BFGMiner. It will take up to 5 minutes until the pool is marked alive. I'm curious if this happens with other miner software.
they have two pools to connect: us1.ghash.io and nl1.ghash.io, both supports stratum. Check the settings. (just ghash.io is only the web interface) I'm using nl1.ghash.io, but I just tried us1 and it has the same delay. |
|
|
|
2% or 3% fees. this is the only anecdote.
Where do you get that? They list the full block rewards including transaction fees in their block table. Unfortunately my hashrate is too low to calculate accurately whether there is a fee or not, since the percentage of my shares relative to total is truncated to two decimals. Someone with 1% or more of the pool's hashrate should be able to calculate how high the fee is with a low enough error margin. |
|
|
|
|
There is a strange delay when connecting to the pool after restarting BFGMiner. It will take up to 5 minutes until the pool is marked alive. I'm curious if this happens with other miner software.
|
|
|
|
This ghash.io keeps growing at an alarming rate. Who are they?
private bitfury chip based mining pool right? Bitfury is shipping chips now so they are bringing, from what I understand, a significant amount of hash rate online as their orders arrive. Private? Not exactly. Every Metabank's client received the credentials to access this pool with a miner unit (Metabank is a company that built the russian version of miner with Bitfury chips). I believe that FAN (Ukraine) also does the same. I have no idea if punin does. Also when you buy a hash power from the cex.io you get an account at ghash.io. As an option, you may contact this pool admin and ask for an account (I have no idea what reasons he has to accept or reject a request). As for hash power growth speed, the agreement between Bitfury and foundry is 25 wafers a month AFAIK (this is approximately 270Th per batch). However, due to different spontaneous delays in the whole production chain this not achievable, but still the growth is really high  I'm pretty sure you can just sign up to cex.io and forget buying hashpower entirely. The same account credentials will work on ghash.io. |
|
|
|
|
I received a new october card where the R02F resistor was 2.11k instead of 1.8k. Pencil modding it 2.05 boosted the valid hashrate from 32 GH/s to 34.5 GH/s, even though one chip dropped semi-dead after the modding.
|
|
|
|
Are others seeing this kind of error flood after a reboot with BFSB hardware?: [2013-10-17 22:19:55] BSB 2af: bitfury_init_oldbuf: Giving up after 4 tries
[2013-10-17 22:19:55] BSB 2ag: bitfury_init_oldbuf: Giving up after 4 tries
[2013-10-17 22:19:55] BSB 2aj: bitfury_init_oldbuf: Giving up after 4 tries
[2013-10-17 22:19:55] BSB 2aw: bitfury_init_oldbuf: Giving up after 4 tries
[2013-10-17 22:19:55] BSB 1a: bitfury_init_oldbuf: Giving up after 4 tries
I can see the device/proc counter slowly increase in the top area. During 3-4 minutes the errors gradually stop, and all chips start working. |
|
|
|
Hi
Are there any manual clock tuning options for use with the BFSB or is auto the only option atm ?
Thanks
From IRC (anajavi has been developing the code at least to some extent): <anajavi> bfgminer-rpc 'pgaset|0,help' gives a help, <anajavi> bfgminer-rpc 'pgaset|0,osc6_bits,54' sets speed for chip 0 I haven't tested this myself. I'm also unsure about the PGA numbering, since with the current device scheme there can be up to 4 devices corresponding to each bus on the M-board, and each of those devices can have up to 64 chips. EDIT: I tried this, and with the newest version you actually have to use procset instead of pgaset. But the option seems to be broken. Firstly, the help command doesn't work. And the actual speed setting doesn't work either: nc localhost 4028 <<< procset\|0,osc6_bits,55
STATUS=E,When=1382035802,Code=93,Msg=PGA 0 set failed: invalid setting,Description=bfgminer 3.3.0|#
nc localhost 4028 <<< procset\|0,osc6_bits
STATUS=E,When=1382035841,Code=93,Msg=PGA 0 set failed: Unknown option: osc6_bits,Description=bfgminer 3.3.0|#
But testing with a bogus option name, it looks like osc6_bits does indeed exist on some level: nc localhost 4028 <<< procset\|0,bogus,55
STATUS=E,When=1382035944,Code=93,Msg=PGA 0 set failed: Unknown option: bogus,Description=bfgminer 3.3.0|#
With osc6_bits and the desired speed value, I get an invalid setting error instead of Unkown option. EDIT2: The problem was with netcat, apparently the procset command is more strict about extra newlines at the end of the command. Thanks to Luke for pointing this out. Works fine when using bfgminer-rpc. |
|
|
|
|
I received my order #954 without any note via email or in the shop. It's still marked Processing. People, check your mailboxes!
|
|
|
|
|
How exactly is --submit-threads supposed to work?
bfgminer --submit-threads 128
[2013-10-17 04:14:27] bfgminer: --submit-threads: '@' is not a number
bfgminer --submit-threads=128
[2013-10-17 04:14:14] bfgminer: --submit-threads: doesn't allow an argument
bfgminer --submit-threads
[2013-10-17 04:14:51] bfgminer: --submit-threads: '@' is not a number
"submit-threads" : "128" in config file:
Invalid config option --submit-threads: Invalid value
|
|
|
|
Don't know what I'm doing, but messing around it looks like
\home\pi\bfgminer-3.2.1
ok that would be ~/bfgminer-3.2.1 insert this as your bfgminer startup script: #!/bin/bash screen -S bfgminer -d -m su - pi /home/pi/bfgminer-3.2.1/.bfgminer <YOUR OPTIONS HERE> -D 2>/home/pi/bfgminer-3.2.1/logs/activity.log try than and see if it works afterward you should be able to ssh in as pi@rpi.ipaddress and execute: this should bring up a bfgminer window with lots of debug info flying on screen. todo: figure out how to garbage collect every N time period (e.g. 24 hrs) to create a rolling log Try this to get the rolling log: cp /home/pi/bfgminer-3.2.1/logs/activity.log /home/pi/bfgminer-3.2.1/logs/activity-`date +%s`.log
echo > /home/pi/bfgminer-3.2.1/logs/activity.log
echo will flush the file contents without deleting it, and bfgminer will just keep appending to that same file like nothing happened. |
|
|
|
I've been using the cgminer API to get statistics about my mining devices.
One thing I can't seem to find is the current hashrate (or 5sec average hashrate). I see an average hashrate that appears to be since the machines was started but I don't see the current hashrate.
If this statistic is not available, how can I calculate it from what is available?
You can sum the 5s hashrate of each device from the devs reply. It's a good question though why this can't be included in the summary reply. |
|
|
|
|
That was scary! I set a buy order for 41 GH/s @ 0.158 and immediately someone cleared the whole buy side. Day's range: 0.0100 - 0.1849. After that the price rebounded really quickly to 0.17 with large buy orders.
|
|
|
|
|
Show Posts
