It would be really nice if you could remove workers...
(obviously not the ghash worker)
+1 I thought they already did disappear from the list automatically, but that doesn't seem to be the case. My .ghash worker did disappear once in the past, when I hadn't had any GHS for a few days. But now another temporary worker is still listed, even though it only mined for a short while 3-4 days ago. BTW, can anyone explain the worker grouping option on account preferences? I guess the email and phone number are for grouped alerts, but what about the read-only password? The grouped alerts would be useful, since I'm now getting a flood of text messages and emails on every downtime. |
|
|
|
Since someone is still answering messages here, could you please look up my case of suspended funds? It's been almost a year. No email goes through, and Tycho doesn't answer private messages. I have 0.4 BTC locked. How to proceed? Sorry, but I can't remember who you are. Possibly your e-mail was lost. Please send it again with mentioning your login name and reason for account blocking. To what email address? I already tried support@deepbit.net and Tycho@deepbit.net, mail was returned by the server. Did you try the one on the web page? Thanks, I'm not sure anymore where I even got those non-working addresses. pool@deepbit.net seems to work, at least it wasn't returned. |
|
|
|
Since someone is still answering messages here, could you please look up my case of suspended funds? It's been almost a year. No email goes through, and Tycho doesn't answer private messages. I have 0.4 BTC locked. How to proceed? Sorry, but I can't remember who you are. Possibly your e-mail was lost. Please send it again with mentioning your login name and reason for account blocking. To what email address? I already tried support@deepbit.net and Tycho@deepbit.net, mail was returned by the server. |
|
|
|
|
I flashed two singles which apparently had Rev1 chips with this firmware. After a cursory look at the code it seemed like it supports both Rev1 and Rev2 chips so I flashed away. No chips could be brought up with 16 engines on either one, so I assume they are Rev1.
Stock valid hashrates were 59 and 61. After flashing and manually tuning chip speeds I got the 59 unit to 61.5, and the 61 unit to 62.5 valid hashrate. However, one chip on the unit originally doing 59 now seems to produce 15% HW errors, no matter what speed it's set to. I even tried 5. I'll try tinkering around and maybe set all chips to speed 7 to figure out what's going on, it definitely wasn't even close to that amount of HW errors with the stock firmware (which AFAIK sets all chips to 7). Overall this is a definite improvement, but I'm wondering what's causing that one chip to have degraded performance now. Maybe increasing the speed of other chips can also cause some chips to generate more errors?
|
|
|
|
- Oh, and the null termination byte in API replies was removed from bfgminer for some reason. Incompatibility ftw!
Hey, I try to keep it compatible! Why no bug report? When did this change, and what null byte should there be? Hey Luke. I think this may be why I started getting the issues I communicated to you starting a month or two ago with invalid data coming across from the devs API call. cgminer terminates each API call with a NULL character so that API clients know once they'v received the full response. This was removed from bfgminer at some point. I'm sketchy on the details beyond that - just saw it discussed on IRC. The problem I've seen is that some scripts expect the null character \0 to be there, and don't recognize any response without it. I didn't even realize myself that there was a null character on cgminer's responses, because all my own custom-made scripts try to decode any responses after the connection is closed by the other end, and I guess the libraries I've used automatically trim the null character. It's not really needed because cgminer & bfgminer always close the connection after a response. But I can understand the reasoning why some programmers prefer to rely on a termination character on network communications. That way they don't have to rely on the other end closing the connection. The null character is trivial to trim from responses, working around a missing one if your code expects it is a bit harder. |
|
|
|
How much does this differ from cgminer ?
- Different syntax for some configuration options, like device selection.
- Different way of using USB devices - cgminer uses raw USB devices, bfgminer uses USB serial devices.
- More detailed device statistics, since in bfgminer you can view the statistics of individual chips. I heard this would be doable in cgminer, too, it's just not yet implemented there.
- Better GBT support compared to cgminer. Almost everyone uses stratum nowadays, though.
- GPU support! cgminer doesn't support GPUs anymore.
- Oh, and the null termination byte in API replies was removed from bfgminer for some reason. Incompatibility ftw! (On that note, cgminer and bfgminer developers are 100% incompatible)
|
|
|
|
I sent a scanned copy of my electricity bill as proof of residence, but Bitstamp refused it, saying "Proof of residence document does not meet our verification standards as we are unable to determine the validity of the document - additional verification required."
Just how does that scan not fall into the "utility bill for utilities consumed at your home address" category of accepted documents? The bill clearly stated my name, address and the date of issuance. Perhaps they are unable to translate Finnish? If that's the case, they should clearly state their language requirements too. The relevant words on the bill should be easy to pass through Google translate, though.
I got my account verified without having to submit any additional documents by just making a support ticket about it. Still no idea why it was denied at first. |
|
|
|
|
Since someone is still answering messages here, could you please look up my case of suspended funds? It's been almost a year. No email goes through, and Tycho doesn't answer private messages. I have 0.4 BTC locked. How to proceed?
|
|
|
|
|
I sent a scanned copy of my electricity bill as proof of residence, but Bitstamp refused it, saying "Proof of residence document does not meet our verification standards as we are unable to determine the validity of the document - additional verification required."
Just how does that scan not fall into the "utility bill for utilities consumed at your home address" category of accepted documents? The bill clearly stated my name, address and the date of issuance. Perhaps they are unable to translate Finnish? If that's the case, they should clearly state their language requirements too. The relevant words on the bill should be easy to pass through Google translate, though.
|
|
|
|
|
Thanks for adding MHS 5s to summary API response! BTW, I noticed that the devicescan API command isn't considered privileged. Shouldn't it be?
|
|
|
|
With the newest git commit, compiling without libusb doesn't seem to work. If I don't enable any USB device support, the following compile error happens: bfgminer-miner.o:miner.c:(.text+0x2f16): undefined reference to `__vcom_devinfo_findorcreate' EDIT: Fixed by new commit |
|
|
|
In this paste the summary 5s hashrate is zero because of a pool outage: bfgminer version 3.4.0 - Started: [2013-11-04 20:06:54] - [ 0 days 04:29:32]
[M]anage devices [P]ool management [S]ettings [D]isplay options [H]elp [Q]uit
Connected to nl1.ghash.io diff 128 with stratum as user juhakall.bfsb
Block: ...ba64262f33dfbc74 Diff:391M ( 2.80Ph/s) Started: [00:34:48]
ST:0 F:0 NB:34 AS:0 BW:[117/ 44 B/s] E:505.54 I: 9.25mBTC/hr BS:2.95M
4/80 | 0.10/185.3/171.1Gh/s | A:5074 R:13+0(.26%) HW:42536/6.2%
--------------------------------------------------------------------------------
BSB 0: | 37.69/37.43/34.62Gh/s | A:1040 R: 2+0(.19%) HW:10338/7.3%
BSB 1: | 38.66/38.48/35.02Gh/s | A:1039 R: 5+0(.48%) HW: 8681/6.1%
BSB 2: | 74.69/74.36/67.23Gh/s | A:1981 R: 3+0(.15%) HW:20221/7.4%
BSB 3: | 35.22/35.03/34.27Gh/s | A:1014 R: 3+0(.29%) HW: 3296/2.5%
--------------------------------------------------------------------------------
However, the device 5s hashrates are still normal, even though they aren't really hashing. I have two questions about this. Why not include the summary 5s hashrate in the API response? And what's up with the 5s device hashrates not dipping at all during an outage? |
|
|
|
|
Is there a good reason to show scrypt and sha256 coins on the same page anymore? It seems to me that in this current situation, having separate profitability pages for both algorithms would make more sense. The hardware used for mining these algorithms have completely diverged; there is no reason to mine sha256 with a GPU anymore, and ASICs can only mine sha256.
|
|
|
|
Is there any way to determine the BSB2ab style device names from API replies? I can't use ProcID, because the naming scheme differs when there are more chips. For example, I have BSB devices with 16 or 32 chips. ProcID 0 on BSB0 is BSB0a, but ProcID 0 on BSB2 is BSB2aa.
This would be useful because --set-device use the letter naming scheme as arguments when setting options for individual chips.
I realized that the stats reply has the naming scheme I desired, but curiously, using DEVS+STATS in a customsummarypage on miner.php results in all chips from BSB2 being left out completely from the tables. It's the only device I have with 32 chips instead of 16. So with just DEVS, I can see BSB0 (16 chips), BSB1 (16 chips), BSB2 (32 chips) & BSB3 (16 chips). If I change the DEVS to DEVS+STATS, for some reason BSB2 is skipped. Setting $per_proc to true or false makes no difference; either BSB2 or all chips from BSB2 are missing. I'm thinking there might be something wrong with the join_get_field function's ProcID -> lowercase letter conversion, when there are two letters instead of one. Looks like the code just converts the ProcID to a letter, but that won't match the naming scheme with two letters. Doesn't look like it's easy to fix, because you just can't know whether ProcID 0 should be converted to a or aa, until you know how many procs there actually are in that device. |
|
|
|
What could be causing these errors? I've been using eloipool without encountering this before. 2013-10-31 03:34:54,429 newBlockNotification INFO Received new block notification
2013-10-31 03:34:54,432 merkleMaker INFO New block: 000000000000e96483898230fc2b79ef42d1894391214abe45d37a5e3e24ade5 (height: 21821; bits: 1b00ff4b)
2013-10-31 03:34:54,435 JSONRPCServer INFO Nobody to longpoll
2013-10-31 03:34:54,525 BitcoinLink DEBUG Received block inv over p2p for 000000000000e96483898230fc2b79ef42d1894391214abe45d37a5e3e24ade5
2013-10-31 03:34:54,849 JSONRPCServer INFO Nobody to longpoll
2013-10-31 03:38:33,235 BitcoinLink DEBUG Received block inv over p2p for 0000000000007e562f51f86f48082895e82492d56774a62d3d6a3e7ec11fe6a5
2013-10-31 03:38:33,251 newBlockNotification INFO Received new block notification
Exception in thread newBlockNotification via signal 10:
Traceback (most recent call last):
File "/usr/lib/python3.2/threading.py", line 740, in _bootstrap_inner
self.run()
File "/usr/lib/python3.2/threading.py", line 693, in run
self._target(*self._args, **self._kwargs)
File "./eloipool.py", line 681, in newBlockNotification
MM.updateMerkleTree()
File "/home/juhakall/src/eloipool/merklemaker.py", line 560, in updateMerkleTree
self._updateMerkleTree()
File "/home/juhakall/src/eloipool/merklemaker.py", line 548, in _updateMerkleTree
self._updateMerkleTree_I()
File "/home/juhakall/src/eloipool/merklemaker.py", line 512, in _updateMerkleTree_I
r = self._updateMerkleTree_fromTS(TS)
File "/home/juhakall/src/eloipool/merklemaker.py", line 477, in _updateMerkleTree_fromTS
MP = self._CallGBT(TS)
File "/home/juhakall/src/eloipool/merklemaker.py", line 327, in _CallGBT
MP = access.getblocktemplate(self.GBTReq)
File "/home/juhakall/src/eloipool/bitcoinrpc/authproxy.py", line 112, in __call__
'Content-type': 'application/json'})
File "/usr/lib/python3.2/http/client.py", line 967, in request
self._send_request(method, url, body, headers)
File "/usr/lib/python3.2/http/client.py", line 995, in _send_request
self.putrequest(method, url, **skips)
File "/usr/lib/python3.2/http/client.py", line 850, in putrequest
raise CannotSendRequest(self.__state)
http.client.CannotSendRequest: Request-sent
2013-10-31 03:38:33,257 merkleMaker INFO New block: 0000000000007e562f51f86f48082895e82492d56774a62d3d6a3e7ec11fe6a5 (height: 21822; bits: 1b01325a)
2013-10-31 03:38:33,258 JSONRPCServer INFO Nobody to longpoll
2013-10-31 03:38:33,658 JSONRPCServer INFO Nobody to longpoll
2013-10-31 03:40:05,491 newBlockNotification INFO Received new block notification
2013-10-31 03:40:05,558 merkleMaker INFO New block: 000000000000d7cd0a17d0d7b271a2ec6e1d02f5256b65b7b4ca0699b054ccda (height: 21823; bits: 1b01325a)
2013-10-31 03:40:05,560 JSONRPCServer INFO Nobody to longpoll
2013-10-31 03:40:05,584 BitcoinLink DEBUG Received block inv over p2p for 000000000000d7cd0a17d0d7b271a2ec6e1d02f5256b65b7b4ca0699b054ccda
2013-10-31 03:40:05,911 JSONRPCServer INFO Nobody to longpoll
2013-10-31 03:40:47,580 newBlockNotification INFO Received new block notification
2013-10-31 03:40:47,583 merkleMaker INFO New block: 0000000000008bf8bbb1c66bbfb4898cc96af99e2a1c6c1543b410b80650af98 (height: 21824; bits: 1b01325a)
2013-10-31 03:40:47,586 JSONRPCServer INFO Nobody to longpoll
2013-10-31 03:40:47,679 BitcoinLink DEBUG Received block inv over p2p for 0000000000008bf8bbb1c66bbfb4898cc96af99e2a1c6c1543b410b80650af98
2013-10-31 03:40:47,974 JSONRPCServer INFO Nobody to longpoll
2013-10-31 03:40:51,674 newBlockNotification INFO Received new block notification
2013-10-31 03:40:51,678 merkleMaker INFO New block: 00000000000031ac074f8fb95c0a60f844095b25a7c8e23afa0503f201d78c89 (height: 21825; bits: 1b016f9f)
2013-10-31 03:40:51,680 JSONRPCServer INFO Nobody to longpoll
2013-10-31 03:40:51,770 BitcoinLink DEBUG Received block inv over p2p for 00000000000031ac074f8fb95c0a60f844095b25a7c8e23afa0503f201d78c89
2013-10-31 03:40:52,064 JSONRPCServer INFO Nobody to longpoll
2013-10-31 03:42:50,851 checkShare INFO BLKHASH: a410d33380efba2a037e7e7f0c7cebcc3ac9e845d00b2e8bd1d6
2013-10-31 03:42:50,852 checkShare INFO TARGET: 16f9f000000000000000000000000000000000000000000000000
2013-10-31 03:42:50,853 checkShare INFO Submitting upstream
2013-10-31 03:42:50,853 checkShare INFO Real block payload: 02000000898cd701f20305fa3ae2c8a7255b0944f8600a5cb98f4f07ac31000000000000bf7e467 c046ee191017e71cfc1dad3a5521678b8eba78f79de57bf2a7cf7a54f98b571529f6f011bb19127 c00101000000010000000000000000000000000000000000000000000000000000000000000000f fffffff10024155045271b59201000000e0010000ffffffff0100e1f505000000001976a9145590 411c5385c0afc54dc09235ee52db575719f788ac00000000
2013-10-31 03:42:50,855 merkleMaker INFO New block: 000000000000a410d33380efba2a037e7e7f0c7cebcc3ac9e845d00b2e8bd1d6 (height: 21826; bits: 1b016f9f)
2013-10-31 03:42:50,856 Waker for BitcoinNode DEBUG Read wakeup
2013-10-31 03:42:50,857 JSONRPCServer INFO Nobody to longpoll
2013-10-31 03:42:50,861 BitcoinNode INFO Sent `block' to 1 nodes
2013-10-31 03:42:50,879 blockSubmission DEBUG Upstream 'primary' accepted block
2013-10-31 03:42:50,889 newBlockNotification INFO Received new block notification
2013-10-31 03:42:51,282 JSONRPCServer INFO Nobody to longpoll
As you can see, it doesn't happen on every block notify. |
|
|
|
I've been having random problems where BFGMiner refuses to start mining on startup. It has happened with both BFL and BFSB hardware. Here's an example of what it looks like on BFL hardware: http://pastebin.com/ZixrFdrMBFGMiner will just sit there doing nothing for minutes. If I manually command it to switch to some other pool, and then back to pool 0, it will start working right away. Sometimes pool 0 is detected as dead upon startup (I think this is a ghash.io specific issue), but then BFGMiner might get similarly stuck on pool 1. |
|
|
|
|
Is there any way to determine the BSB2ab style device names from API replies? I can't use ProcID, because the naming scheme differs when there are more chips. For example, I have BSB devices with 16 or 32 chips. ProcID 0 on BSB0 is BSB0a, but ProcID 0 on BSB2 is BSB2aa.
This would be useful because --set-device use the letter naming scheme as arguments when setting options for individual chips.
|
|
|
|
Damn, youchdog returned and the pool started having communication errors. I guess it can only handle one large miner at a time. Should we take turns?  I only have 700k LPs left to redeem. |
|
|
|
|
There was a 5 hour block. Not unheard of even on a large pool like ghash.io.
|
|
|
|
I'd love to hear from anyone who dares to try CEX.IO's hardware redeeming service. Sure, it's overpriced, but don't let that stop you! I'm wondering how long is the delivery process going to be. https://cex.io/redeem |
|
|
|
|
Show Posts
