Let me know if interested
Esadee: You have not responded to my PM's... we have business to complete. |
|
|
|
1. XFX 280x double dissipation, brand new used for 2 weeks. Bought 300 new, 200+ shipping.
Interested in this card, Escrow/required, PM me quote in BTC? |
|
|
|
|
please do other exchanges than just Gox.
|
|
|
|
I have 2x KNC Jupiter for sale.
14 BTC each escrowed. 28BTC for both. Offer good for 24 hours due to current market conditions. |
|
|
|
If you won't take escrow, credit cards, or paypal it's gonna smell like a scam to many people.  Agreed.. Credit Cards at a minimum. |
|
|
|
This kind of sale, if it was one, i would expect from Gox, but Bitmit had a functioning information policy and actually cared about their business and their customers.
Very strange closure/sale indeed.
liked the site a lot, sad to see it go. |
|
|
|
Thanks for the digging so far..appreciate the share. I have not yet succeeded in discovering how to change the hashing clocks. It appears possible.
The VRM voltages should be easy to adjust over I2C. Though I do not recommend it, yet.
They are easy to check/set, but like you, I wouldn't recommend it.. It can be a great way to try to keep your temps in the 'magic zone' but you need to watch the VRM amp loads and temps very carefully. The values are an offset from a 'full' voltage value, which is 0.950 volts. The higher the value, the less subtracted from 0.950 value, with FFFF being ZERO subtracted. Older codes (like 0.91) came with much higher volts, and the current code (0.98) sets 0xff67, which works out to about 0.797 volts.. But even that value appears to be a 'suggestion' since each core on a die will be some variance off THAT number. |
|
|
|
a = bus
b = channel
PMBus has redundant bus-system, which means here, that when you send data
to:
Bus 2 its enough
For bus 1 it differs, here has the bus 1 only on channel 24 valid data
So was that what you needed? |
|
|
|
I hacked up the monitordcdc script, tossing in a 'logger' line to write something to syslog each time it tries to restart a die.. (you have to start /etc/init.d/syslog.busybox as well, and then tail -f /var/log/messages)
yikes.. I"m curious if other people are seeing monitorDCDC having to light cores back up as often as I am.. Nov 7 23:28:38 knc2 user.notice dcdc: i2cset -y 2 0x20 0xe5 3
Nov 7 23:28:39 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 7 23:30:25 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 7 23:32:12 knc2 user.notice dcdc: i2cset -y 2 0x20 0xe5 3
Nov 7 23:32:12 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 0
Nov 7 23:32:12 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 1
Nov 7 23:32:12 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 7 23:32:12 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 3
Nov 7 23:33:59 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 7 23:35:46 knc2 user.notice dcdc: i2cset -y 2 0x20 0xe5 3
Nov 7 23:35:46 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 7 23:37:33 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 7 23:39:19 knc2 user.notice dcdc: i2cset -y 2 0x20 0xe5 3
Nov 7 23:39:20 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 7 23:41:07 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 7 23:42:54 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 7 23:44:41 knc2 user.notice dcdc: i2cset -y 2 0x20 0xe5 3
Nov 7 23:44:41 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 7 23:46:28 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 7 23:48:15 knc2 user.notice dcdc: i2cset -y 2 0x20 0xe5 3
Nov 7 23:48:15 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 7 23:50:02 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 7 23:51:48 knc2 user.notice dcdc: i2cset -y 2 0x20 0xe5 3
Nov 7 23:51:49 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 7 23:53:36 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 7 23:55:22 knc2 user.notice dcdc: i2cset -y 2 0x20 0xe5 3
Nov 7 23:55:23 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 7 23:57:10 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 7 23:58:57 knc2 user.notice dcdc: i2cset -y 2 0x20 0xe5 3
Nov 7 23:58:57 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 00:00:43 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 00:02:31 knc2 user.notice dcdc: i2cset -y 2 0x20 0xe5 3
Nov 8 00:02:31 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 00:04:18 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 00:06:05 knc2 user.notice dcdc: i2cset -y 2 0x20 0xe5 3
Nov 8 00:06:05 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 00:07:52 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 00:09:38 knc2 user.notice dcdc: i2cset -y 2 0x20 0xe5 3
Nov 8 00:09:38 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 00:11:26 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 00:13:12 knc2 user.notice dcdc: i2cset -y 2 0x20 0xe5 3
Nov 8 00:13:12 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 00:15:00 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 00:16:46 knc2 user.notice dcdc: i2cset -y 2 0x20 0xe5 3
Nov 8 00:16:47 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 00:18:33 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 00:20:20 knc2 user.notice dcdc: i2cset -y 2 0x20 0xe5 3
Nov 8 00:20:21 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 00:22:07 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 00:23:54 knc2 user.notice dcdc: i2cset -y 2 0x20 0xe5 3
Nov 8 00:23:55 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 00:25:41 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 00:27:29 knc2 user.notice dcdc: i2cset -y 2 0x20 0xe5 3
Nov 8 00:27:29 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 00:29:16 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 00:31:02 knc2 user.notice dcdc: i2cset -y 2 0x20 0xe5 3
Nov 8 00:31:03 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 00:32:50 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 0
Nov 8 00:32:50 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 1
Nov 8 00:32:50 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 00:32:50 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 3
Nov 8 00:34:36 knc2 user.notice dcdc: i2cset -y 2 0x20 0xe5 3
Nov 8 00:34:36 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 00:36:24 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 00:38:10 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 00:39:57 knc2 user.notice dcdc: i2cset -y 2 0x20 0xe5 3
Nov 8 00:39:57 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 00:41:44 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 00:43:31 knc2 user.notice dcdc: i2cset -y 2 0x20 0xe5 3
Nov 8 00:43:31 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 00:45:19 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 00:47:05 knc2 user.notice dcdc: i2cset -y 2 0x20 0xe5 3
Nov 8 00:47:05 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 00:48:52 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 00:50:39 knc2 user.notice dcdc: i2cset -y 2 0x20 0xe5 3
Nov 8 00:50:39 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 00:52:26 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 00:54:13 knc2 user.notice dcdc: i2cset -y 2 0x20 0xe5 3
Nov 8 00:54:13 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 00:56:00 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 00:57:47 knc2 user.notice dcdc: i2cset -y 2 0x20 0xe5 3
Nov 8 00:57:48 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 00:59:34 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 01:01:21 knc2 user.notice dcdc: i2cset -y 2 0x20 0xe5 3
Nov 8 01:01:21 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 01:03:09 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 01:04:55 knc2 user.notice dcdc: i2cset -y 2 0x20 0xe5 3
Nov 8 01:04:55 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 01:06:43 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 01:08:29 knc2 user.notice dcdc: i2cset -y 2 0x20 0xe5 3
Nov 8 01:08:30 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 01:10:16 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 01:12:03 knc2 user.notice dcdc: i2cset -y 2 0x20 0xe5 3
Nov 8 01:12:03 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 01:13:50 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 01:15:37 knc2 user.notice dcdc: i2cset -y 2 0x20 0xe5 3
Nov 8 01:15:38 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 01:17:24 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 01:19:10 knc2 user.notice dcdc: i2cset -y 2 0x20 0xe5 3
Nov 8 01:19:11 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 01:20:58 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 01:22:44 knc2 user.notice dcdc: i2cset -y 2 0x20 0xe5 3
Nov 8 01:22:45 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 01:24:32 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 01:26:18 knc2 user.notice dcdc: i2cset -y 2 0x20 0xe5 3
Nov 8 01:26:18 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 01:28:05 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 01:29:52 knc2 user.notice dcdc: i2cset -y 2 0x20 0xe5 3
Nov 8 01:29:52 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 01:31:39 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 01:33:26 knc2 user.notice dcdc: i2cset -y 2 0x20 0xe5 3
Nov 8 01:33:26 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 01:35:13 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 01:37:00 knc2 user.notice dcdc: i2cset -y 2 0x20 0xe5 3
Nov 8 01:37:00 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 01:38:46 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 01:40:33 knc2 user.notice dcdc: i2cset -y 2 0x20 0xe5 3
Nov 8 01:40:33 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 01:42:20 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 01:44:07 knc2 user.notice dcdc: i2cset -y 2 0x20 0xe5 3
Nov 8 01:44:07 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 01:45:54 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 01:47:41 knc2 user.notice dcdc: i2cset -y 2 0x20 0xe5 3
Nov 8 01:47:41 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 01:49:28 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 01:51:15 knc2 user.notice dcdc: i2cset -y 2 0x20 0xe5 3
Nov 8 01:51:15 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 01:53:01 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 01:54:49 knc2 user.notice dcdc: i2cset -y 2 0x20 0xe5 3
Nov 8 01:54:49 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 01:56:35 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 01:58:21 knc2 user.notice dcdc: i2cset -y 2 0x20 0xe5 3
Nov 8 01:58:22 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 02:00:09 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 02:01:56 knc2 user.notice dcdc: i2cset -y 2 0x20 0xe5 3
Nov 8 02:01:56 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 02:03:43 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 02:05:30 knc2 user.notice dcdc: i2cset -y 2 0x20 0xe5 3
Nov 8 02:05:30 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 02:07:18 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 02:09:04 knc2 user.notice dcdc: i2cset -y 2 0x20 0xe5 3
Nov 8 02:09:05 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 02:10:51 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 02:12:38 knc2 user.notice dcdc: i2cset -y 2 0x20 0xe5 3
Nov 8 02:12:38 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 02:14:25 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 02:16:12 knc2 user.notice dcdc: i2cset -y 2 0x20 0xe5 3
Nov 8 02:16:12 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 02:17:59 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 8 02:19:45 knc2 user.notice dcdc: i2cset -y 2 0x20 0xe5 3
Nov 8 02:19:45 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
|
|
|
|
No thats not right,
<snip>
I need as quick as possible the above dumps, to verify something.
Fubly: I ran this on a jupiter presently at 16/16. Wrote a quick script to grab what you wanted: for a in 1 2 3 4 5 6 7 8; do
for b in 20 21 22 23 24 25; do
echo "dumping ( $a : $b )"
i2cdump -y $a 0x$b
echo
done
done
Here's the output : http://pastebin.com/ZhzGZBuf |
|
|
|
Monitordcdc has more changes: Interval for checking VRMs that ouput zero current in monitordcdc was decreased from 15 minutes to 20 seconds (15 checks in 1minute vs 5 checks in 4secs). When VRM has more than 3 failures(=zero current output) in this 20 sec interval the die powered by this VRM is restarted (this was not present in 0.98). I am not sure why die 0 is restarted only when other dies have failed too (maybe die 0 is somehow connected to other dies?).
I hacked up the monitordcdc script, tossing in a 'logger' line to write something to syslog each time it tries to restart a die.. (you have to start /etc/init.d/syslog.busybox as well, and then tail -f /var/log/messages) like this: if [ "$failed1" = "1" ] ; then
i2cset -y 2 0x2$channel 0xe5 1
logger -t "dcdc" "i2cset -y 2 0x2$channel 0xe5 1 "
What I see looks like it's trying to restart individual dies, no matter which one it is. Nov 7 23:10:49 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 7 23:12:35 knc2 user.notice dcdc: i2cset -y 2 0x20 0xe5 3
Nov 7 23:12:35 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 7 23:14:23 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 7 23:16:09 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 7 23:17:57 knc2 user.notice dcdc: i2cset -y 2 0x20 0xe5 3
Nov 7 23:17:57 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
Nov 7 23:19:43 knc2 user.notice dcdc: i2cset -y 2 0x24 0xe5 2
0x20 = module 0 0x22 = module 1 0x24 = module 2 0x27 = module 3 (I think) 0, 1, 2, 3 = dies So that equates to 3rd module, 3rd core, then first module, 4th core, then repeatedly 3rd module, 3rd core. In my case, 0/4 can be restarted, and it does every few minutes when it stops, but 3/3 will never restart.. but the script tries repeatedly. |
|
|
|
[snip comments about 'waiting for pool issue'] On further investigation, I've found how this can happen, and have committed a fix for this into git so it should go into the next version. The actual issue goes back quite a way so backtracking versions will not avoid it.
Thanks, heard more comments about people running into it over the weekend from KNC users, who, of course in 0.98 firmware, went to cgminer 3.6.6. by the way, is this the fix: - Use a non blocking connect with a 1 second select timeout when initiating
stratum to allow us to iterate over all IPs returned by getaddrinfo in round
robin DNS pools.
I know I haven't said it for at least 1-2 versions, but thank you again for your continued commitment to CGMINER. It only seems to get better and better over time. It's a pity you didn't write a secret "send 0.1% to the author" into cgminer.. you'd be filthy rich by now from all of us mining with it. In all seriousness, perhaps you should put in a command-line switch.. don't make it default, but make it explicit, like --donate-author % |
|
|
|
Con, upgraded from 3.6.2 to 3.6.6 two days ago, and have twice run into a new issue. (5) different machines running 3.6.6 at (3) different physical locations, different carriers. each miner set up for (6) pool entries, (3) btcguild, (2) eligius, (1) deepbit, set to "failover" mode. I've now had (2) of them completely stall, no new work. here's the messages: [2013-11-01 17:10:07] Accepted 00cdfacd Diff 318/128 BAS 3 pool 0
[2013-11-01 17:10:07] Accepted 01f1c8fc Diff 131/128 BAS 0 pool 0
[2013-11-01 17:10:08] Accepted 01264c88 Diff 222/128 BAS 1 pool 0
[2013-11-01 17:10:09] Network diff set to 391M
[2013-11-01 17:10:19] Waiting for work to be available from pools.
and [2013-11-02 01:38:48] Accepted 009d365c Diff 416/256 BAS 2 pool 0
[2013-11-02 01:38:59] Accepted 000139c9 Diff 53.5K/256 BAS 2 pool 0
[2013-11-02 01:39:05] Network diff set to 391M
[2013-11-02 01:39:15] Waiting for work to be available from pools.
At that point ALL work in/out of cgminer stops..I get idle miner notifications from btcguild, but it doesn't fail down to eligius or deepbit. For now I'm going back to 3.6.2, but wanted you to know I'd seen something new. I'm sorry I don't have better logs. |
|
|
|
Two days in and 13 mill shares, bags covering 3/4 of the heat sinks still working great:
Can't bring myself to make them HOTTER... just.. can't.. do.. it... |
|
|
|
Time to update the thread.. 1PH.  |
|
|
|
Con, Are you seeing any of the error/hashing/fw issues all over the KNC boards? I'd sure love to not have a console full of this: [2013-10-29 01:49:01] KnC: accepted by FPGA 9 works, but only 0 submitted
[2013-10-29 01:49:01] KnC: accepted by FPGA 10 works, but only 0 submitted
[2013-10-29 01:49:01] KnC: accepted by FPGA 12 works, but only 0 submitted
[2013-10-29 01:49:01] KnC: accepted by FPGA 12 works, but only 0 submitted
[2013-10-29 01:49:01] KnC: accepted by FPGA 10 works, but only 0 submitted
[2013-10-29 01:49:01] KnC: accepted by FPGA 11 works, but only 0 submitted
[2013-10-29 01:49:01] KnC: accepted by FPGA 11 works, but only 0 submitted
[2013-10-29 01:49:01] KnC: accepted by FPGA 7 works, but only 0 submitted
[2013-10-29 01:49:01] KnC: accepted by FPGA 7 works, but only 0 submitted
[2013-10-29 01:49:01] KnC: accepted by FPGA 11 works, but only 1 submitted
[2013-10-29 01:49:01] KnC: accepted by FPGA 1 works, but only 0 submitted
|
|
|
|
CGMiner run, 2h20m [2013-10-27 23:44:53] Started at [2013-10-27 21:24:18]
[2013-10-27 23:44:53] Runtime: 2 hrs : 20 mins : 34 secs
[2013-10-27 23:44:53] Average hashrate: 62375.0 Megahash/s
[2013-10-27 23:44:53] Solved blocks: 0
[2013-10-27 23:44:53] Best share difficulty: 159K
[2013-10-27 23:44:53] Share submissions: 3869
[2013-10-27 23:44:53] Accepted shares: 3835
[2013-10-27 23:44:53] Rejected shares: 34
[2013-10-27 23:44:53] Accepted difficulty shares: 115140
[2013-10-27 23:44:53] Rejected difficulty shares: 522
[2013-10-27 23:44:53] Reject ratio: 0.9%
[2013-10-27 23:44:53] Hardware errors: 7871
[2013-10-27 23:44:53] Utility (accepted shares / min): 27.30/min
[2013-10-27 23:44:53] Work Utility (diff1 shares solved / min): 815.47/min
DEVICE: BitFORCE SC
FIRMWARE: 1.2.9
IAR Executed: NO
CHIP PARALLELIZATION: YES @ 16
QUEUE DEPTH:40
THEORETICAL MAX: 54219 MH/s
ENGINES: 239
FREQUENCY: 274 MHz
CRITICAL TEMPERATURE: 0
TOTAL THERMAL CYCLES: 0
XLINK MODE: MASTER
DEVICE: BitFORCE SC
FIRMWARE: 1.2.9
IAR Executed: NO
CHIP PARALLELIZATION: YES @ 16
QUEUE DEPTH:40
THEORETICAL MAX: 64887 MH/s
ENGINES: 255
FREQUENCY: 291 MHz
CRITICAL TEMPERATURE: 0
TOTAL THERMAL CYCLES: 0
XLINK MODE: MASTER
|
|
|
|
|
I, like others, have asked for this for a long time. .I'd originally proposed calling it "Mining Hardware" so I could actually browse NON-FPGA/ASIC hardware..
+1
|
|
|
|
|
Show Posts
