You might want to lend support to this idea: Self moderated topics have the warning at the top: This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
One thing that may be of interest to someone reading such a topic would be to know some objective marker of how many posts were deleted that they can then make their own judgements about how reliable the content in it is. A simple change like this would be helpful: This is a self-moderated topic with 230 of 400 posts deleted. If you do not want to be moderated by the person who started this topic, create a new topic. |
|
|
|
Self moderated topics have the warning at the top: This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
One thing that may be of interest to someone reading such a topic would be to know some objective marker of how many posts were deleted that they can then make their own judgements about how reliable the content in it is. A simple change like this would be helpful: This is a self-moderated topic with 230 of 400 posts deleted. If you do not want to be moderated by the person who started this topic, create a new topic. |
|
|
|
or try bfgminer, its much more stable with the antminers... (no disrespect meant ck!)
Prove it? |
|
|
|
|
With cgminer adding "--anu-freq 275" will run them at 2.2GH, though most are stable only at 2GH which is "--anu-freq 250".
|
|
|
|
@ckolivas THX for the USB Fix! cgminer version 4.2.0 - Started: [2014-03-18 21:43:16]
--------------------------------------------------------------------------------------------------
(5s):11.83G (avg):12.65Gh/s | A:140096 R:2736 HW:8044 WU:127.0/m
ST: 3 SS: 1 NB: 132 LW: 357785 GF: 1 RF: 0
Connected to bitcoin.minerpool.de diff 16 with stratum as user 13gtAPBFkrTq5QEnyxxpBKF2wDWvdKd7mw/+16
Block: 4f8d22c7... Diff:4.25G Started: [16:20:44] Best share: 666K
--------------------------------------------------------------------------------------------------
[U]SB device management [P]ool management [S]ettings [D]isplay options [Q]uit
1: ANU 1: | 1.820G/1.808Gh/s | A:21484 R:400 HW:1124 WU: 18.0/m
3: ANU 3: | 1.726G/1.807Gh/s | A:19764 R:496 HW:1178 WU: 18.1/m
4: ANU 4: | 1.827G/1.808Gh/s | A:19880 R:192 HW:1109 WU: 17.9/m
5: ANU 5: | 1.826G/1.809Gh/s | A:19884 R:416 HW:1118 WU: 18.0/m
6: ANU 6: | 1.808G/1.807Gh/s | A:20184 R:464 HW:1209 WU: 18.6/m
7: ANU 7: | 1.743G/1.808Gh/s | A: 8400 R:128 HW: 487 WU: 18.2/m
8: ANU 8: | 1.826G/1.806Gh/s | A: 8784 R:160 HW: 537 WU: 18.7/m
--------------------------------------------------------------------------------------------------
[2014-03-19 08:22:19] ANU 2: Device failed to respond to restart
[2014-03-19 08:22:19] ANU 2 failure, disabling!
[2014-03-19 08:22:21] ANU 0: Device failed to respond to restart
[2014-03-19 08:22:21] ANU 0 failure, disabling! The miner start as new ANU 7 and 8 after "Device failure" new  regards Great, thanks for the feedback  |
|
|
|
No idea then. Heck hashfast weren't even looking for windows support from me, I just told them I could get it working on it as an afterthought. You're ALWAYS going to be better off mining with linux with cgminer but I might take a look at losedows soon to see if I can figure out what the problem is. What does it show with "cgminer.exe -n" ?
Yeah, I don't want to complain really. It's just the windows binaries/readme suggest hashfast devices will work with it and I wondered if maybe the problem is at my end. cgminer -n: [2014-03-19 10:46:24] USB all: found 6 devices - listing known devices
[2014-03-19 10:46:24] No known USB devices I can confirm the HF device is there, WinUSB installed, PID is correct in device manager. Ok that's suspicious of being plugged into a usb port that winusb doesn't recognise, such as a usb3 port. I suspect the earlier version of cgminer included a different libusb which probably did recognise it (though that libusbx is buggy in so many other ways which is why I dropped it). See if you have any usb2 ports anywhere or a usb2 hub to plug in and see if it's recognised. If it doesn't show up with cgminer.exe -n then it will never work. |
|
|
|
There are no known problems on windows, but then I have not tried running any hashfast devices on windows since my very first release. You did the WinUSB driver dance with zadig?
Yes I did the moonwalk with Zadig, and earlier releases of cgminer worked well with it! No idea then. Heck hashfast weren't even looking for windows support from me, I just told them I could get it working on it as an afterthought. You're ALWAYS going to be better off mining with linux with cgminer but I might take a look at losedows soon to see if I can figure out what the problem is. What does it show with "cgminer.exe -n" ? |
|
|
|
Try picking a valid collection of drivers to compile on your hardware ........
Actually the same collection worked for 4.1.0, and the error doesn't really seem to be caused by choice of hardware (of course you don't hit it if avalon2 disabled, but I still think this a bug if avalon2 just cannot be built...) Yes it is a bug if the avalon2 code can't be built; that will be fixed... however the avalon2 code doesn't even work if I recall correctly so there is no point any user building it just yet either. |
|
|
|
@ckolivas: Are there known issues with the newer CG miner versions with Hashfast devices on Windows(tm) or has anything changed prerequisite wise? I been trying all the cgminer releases since ~4.0 (The hashfast firmware update releases) and none of them works on windows. No devices detected. Only seems to show HID PID's in debug log. No problems whatsoever on Linux though There are no known problems on windows, but then I have not tried running any hashfast devices on windows since my very first release. You did the WinUSB driver dance with zadig? |
|
|
|
What about those blocks marked as "Unknown" taking up 23% of the hashing power? Are they really unknown or is that a blockchain.info bug?
That's precisely what this post, serious enough to warrant a sticky, is about: https://bitcointalk.org/index.php?topic=123726.0 |
|
|
|
|
Nice to see cgminer driver code up on a public repository as well. Clean up the patches into a neat low impact small set for a push to mainline cgminer for the best long term support to best benefit from cgminer improvements.
|
|
|
|
|
Main cgminer, not a fork, works fine with this hardware+software combination, but I'd suggest using a regular PC first to get familiar with it before embarking on getting it working on Pi.
Most U1s are reliable at 2GH, so the U2 should be similar. More than that is unlikely to be stable.
|
|
|
|
BTC Guild is approximately 1/6th - 1/5th the network. The entire network has periods with > 1 hour between blocks. A 6 hour block is not unexpected for 1/6th - 1/5th the network. It happens. As a matter of fact, it happens probably more than once a month (both for the whole network and for the pool).
See Eleuthria, this is what you're really paid for - explaining luck and variance at least 30 times per day. |
|
|
|
Ok so on starting with -o -p -u and --btc-address I saved a conf file and didn't see a difference between that and my previous one. All options had correct values but I didn't see an additional pool appended to my list. I didn't avoid loading my previous conf file.
Is the bitcoin address not saved into the config file? I assume it is and that my previous config loading messed things up.
Is it ok if I omit the -o -p and -u with the appropriate info in them and just keep --btc-address in my command line will it still mine paying to my address?
No, the write config from menu is really limited in what it stores at the moment, storing only about 1/3 of the options cos I never got around to updating it. You'll have to manually edit the file to add it or keep the address on your command line. |
|
|
|
|
Yes you have to specify a bitcoin address when mining GBT solo. When you were mining with getwork to bitcoind, bitcoind would randomly give you new addresses but no such option exists with GBT solo since you are building everything from scratch. Mind you, when you are mining to a pool with stratum, that pool is actually talking GBT solo to its own bitcoind anyway. The issue is that stratum itself, or a more comprehensive mining communication protocol could be built into bitcoind directly, but the bitcoind devs feel that as much mining code should be separated from bitcoind as possible, to not associate bitcoind with the concept of mining. Seems silly if you ask me but meh, I got tired of arguing that one, it's not like bitcoin exists without mining so there's no point pretending it has nothing to do with it.
|
|
|
|
My concern was existing solo miners. I have always had bitcoind running and I was mining with these options: cgminer -o http://127.0.0.1:8332 -u bitcoinrpc -p $PASSWORD cgminer was displaying this: Connected to 127.0.0.1 diff 4.25G without LP as user bitcoinrpc Given that the difficulty matched the network difficulty I always assumed it was solo mining, was it not? How was I not mining "in a meaningful way" ? =) Bitcoind would run out of work usually around 5GH. Lower hashrates would indeed mine solo but it was very cpu intensive and inefficient. Also I always assumed that cgminer would ask bitcoind for an address for the mined btc, in a similar way in which it asks for the difficulty.
The fact that it could have been sending the mined btc to some hard-coded address belonging to you really didn't cross my mind, and I still think it's a bit strange as a default. =/
So that's why when I read the 4.2.0 release notes I thought that this was a change in behaviour.
Were versions of cgminer previous to 4.2.0 already using your hard-coded address if one didn't specify --btc-address ?
Wouldn't it be possible to have the receiving address always displayed by cgminer while running? That would avoid any confusion, and would be quite an important piece of information to have. =)
Sure, next version. |
|
|
|
Thanks for the release.
However, I don't think it's the right thing to do to make solo miners mine by default to an address owned by you, unless they pay attention to the documentation and add the --btc-address option.
Some people like me mine solo even if they have a low hashing power. They do so because pool mining wouldn't provide a significant income, and they rather take their chance with the solo mining lottery. You shouldn't assume that somebody doing solo mining has millions worth of equipment so if they don't pay attention to your documentation it's only fair to punish them by ripping them off of their mining.
In any case, simply upgrading a piece of software shouldn't require the user to add an option in order to keep the previous behaviour. And in this case the change in behaviour is quite dramatic: all mining will go to your address instead of the one belonging to the user!
This is a bad default because it is most likely not what a user would want to do by default, and the most sensible default behaviour should be for cgminer to refuse to start and print an error.
The problem here is that obviously there are money involved, and I think this really reflects negatively on your reputation and the reputation of cgminer.
The fact that a piece of software is given away for free doesn't mean that the developer doesn't have to behave professionally and treat his users with respect.
Other high profile open source software like Linux or Apache certainly would never do anything like that.
No you're reading it wrong. It will not mine solo unless you go to the effort of setting up bitcoind AND adding it as a pool and NOT follow the instructions that discretely say to add a btc address. It does NOT change default behaviour one bit for existing miners with existing configurations. EDIT: Or is your concern existing solo miners? The previous versions of cgminer could not meaningfully mine solo so I didn't think anyone was trying to. |
|
|
|
|
New version of cgminer, 4.2.0, out with an important memory leak and other fixes for these devices.
|
|
|
|
|
Show Posts
