Of course the information is objective - but psychology rarely is  "with N out of M posts deleted" 'Don't trust OP! Look at this: "with N out of M posts deleted", lol! SCAMMER with something to hide!' ... "with N+1 out of M posts deleted"  I'm more than well aware of its limitations. Are you suggesting it's not worth adding though? To be honest - this will be a solution that goes from one extreme to the other. IMHO - The fact that there is a notice that the topic is self-moderated is sufficient. Knowing how many posts were moderated is irrelevant. It is actually more misleading than helpful. It can also be more damaging than helpful - you could easily get a few people exploiting that and trying to cause harm and defamation. In other words - I don't see any benefit of knowing the number of deleted posts. As soon as you see the notice you already know that this number could be more than zero. If anyone is really that bored to do such changes I would rather suggest that this notice be in a bit bigger letters and maybe bold and/or red color (so that it is really obvious!). Can't see how adding this information is helpful if they're also given the option: While we're at it, theoretically one could just choose "enable display of deleted posts" as a feature as well, leaving all subjectivity out of the moderators' responsibility.
Then if they're sceptical, they can see for themselves. |
|
|
|
|
While we're at it, theoretically one could just choose "enable display of deleted posts" as a feature as well, leaving all subjectivity out of the moderators' responsibility.
|
|
|
|
|
This forum is only for bitcoin mining discussion. If you want to discuss altcoins, go the the altcoin mining subforum.
|
|
|
|
Of course the information is objective - but psychology rarely is "with N out of M posts deleted" 'Don't trust OP! Look at this: "with N out of M posts deleted", lol! SCAMMER with something to hide!' ... "with N+1 out of M posts deleted" I'm more than well aware of its limitations. Are you suggesting it's not worth adding though? |
|
|
|
While the idea in general is fine, it doesn't really tell you anything about why the posts were removed.
Indeed, and I'm aware of the threads you speak of, but it is completely objective which absolves the forum moderators of any responsibility and once set up is zero maintenance effort. |
|
|
|
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. |
|
|
|
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.
|
|
|
|
|
Show Posts
