|
Related kinda to this pool, I sent a mining reward consolidation transaction manually to a different wallet and obviously calculated the fee to low. Its been unconfirmed for about 5 days now. When will it drop from the men pool and get returned or any other way to get it confirmed?
PS. Paid 0.00010039 per/kb
ID: e9b0fbc32d32f160fc7b746d929c8519d14ab9393aed3dd03ec422d15d59e408
Thanks,
|
|
|
|
Wish I found this thread before I sent them 13btc for s5 miners! Lesson learned. Maybe take up a collection for the victims fund! holy shit, you threw 13 bitcoins at them? almost feeling sorry for you... however, a hard lesson learned. Just remembered this post, yep 35k USD down the tubes. Someday that maybe 350K or even 3.5M. What a lesson..... |
|
|
|
|
Looking for ideas on obtaining 75K USD loan from trusted reputable source to finance a commercial property investment for 3yrs. Have ETH and BTC for collateral but don't want to sell as I believe the run is no even close to the top of the hill. Willing to put up 150K worth of coins, I talked to 2 banks but they have no ideas on how to collateralize digital assets.
Any suggestions?
|
|
|
|
Looking for advise or maybe Kano's help... I've been mining here close to 2 yrs and monthly transfer the 60-100 small payments to another address, mainly to consolidate so when I need to actually send BTC external it does not take 15m using my Trezor to sign and cost a fortune due to size. I usually do a low fee cause I don't care how long my consolidation transaction takes, usually costs me 50 cents to 3 bucks to do this, it did last month anyway.
With the huge men pool now, I tried to do this yesterday and even a low fee was 26 bucks and normal fee was over 60 bucks. again due to so many small inputs and thus transaction KB size. Thinking of ways to solve this issue, Since Kano uses our blocks to send out payments, maybe we would be able to select a payout threshold, .25 or .5 or something like that. That would help. Another thought is send it to network with a low standard fee of .0002 and then provide Kano the transaction ID so he can include in our next block, kind of a perk for mining here and getting a faster lane on the congested BTC highway. Again, only for addresses that he has in DB as payment addresses, so no abuse as input addresses need to match pool payment addresses. Anyway, looking for some suggestions with this consolidation issue, I'm sure I'm not the only one, as I have seen others here do the same thing monthly or weekly consolidation into a new address.
well if he did it every other sunday 2x a month with 100 sats per byte it would only affect a few blocks with lower payments. at 300 sats it is about .0006 per block at 100 sats it is about .0002 per block so 2 weeks is about 30 blocks or .0180 vs .0060 That's not much to give up pool wise to get the ability to bypass the congestion till something is done to resolve it. No real opinion on the solution. I think Kano has said in the past he did not want to allow us to set payment thresholds but back then this congestion problem did not exist. I also believe he does our payments with zero fees since its in our blocks. he could do it one weekend a month which might make it easy to track. Agreed, lets see if anyone else has suggestions and see if Kano can propose something..... If we are going to be hitting 55-65 blocks per month . One weekend could be 2-4 blocks it would be able to clear the multi payments . at 100 sats a byte the price is better then other places. and it does not crush the earnings for the month. the trick is how hard to code it. all the miners benefit 100 sats a byte vs 300 sats . and those blocks would be in the .9 btc for fees range which we get some of the time anyway. Could automate, from your account page could submit the transaction and have it sit there till the next weekend run. Either submit to network at 100 sats a byte and provide transaction ID via account page or just enter the entire transaction on the account page in RAW format. Few options here, but like you said depends on coding and testing time. @kano, not sure if you missed this post, but care to provide a comment? |
|
|
|
Heh I may as well ask  Anyone in Montreal? Take it you heading to Labrador , Looks like the node will be coming up there soon. If you going to the facility I think you going to ask go see my machines , just give them my pool handle. That way if you ever implement your idea of long term renting you at least have seen my machines. Enjoy your trip there man Ditto, I have 70+ TH there and they are building more capacity as its pretty full. I'd like to send more but will have to wait. Take some pics if you can, would be nice to see the layout. |
|
|
|
Looking for advise or maybe Kano's help... I've been mining here close to 2 yrs and monthly transfer the 60-100 small payments to another address, mainly to consolidate so when I need to actually send BTC external it does not take 15m using my Trezor to sign and cost a fortune due to size. I usually do a low fee cause I don't care how long my consolidation transaction takes, usually costs me 50 cents to 3 bucks to do this, it did last month anyway.
With the huge men pool now, I tried to do this yesterday and even a low fee was 26 bucks and normal fee was over 60 bucks. again due to so many small inputs and thus transaction KB size. Thinking of ways to solve this issue, Since Kano uses our blocks to send out payments, maybe we would be able to select a payout threshold, .25 or .5 or something like that. That would help. Another thought is send it to network with a low standard fee of .0002 and then provide Kano the transaction ID so he can include in our next block, kind of a perk for mining here and getting a faster lane on the congested BTC highway. Again, only for addresses that he has in DB as payment addresses, so no abuse as input addresses need to match pool payment addresses. Anyway, looking for some suggestions with this consolidation issue, I'm sure I'm not the only one, as I have seen others here do the same thing monthly or weekly consolidation into a new address.
well if he did it every other sunday 2x a month with 100 sats per byte it would only affect a few blocks with lower payments. at 300 sats it is about .0006 per block at 100 sats it is about .0002 per block so 2 weeks is about 30 blocks or .0180 vs .0060 That's not much to give up pool wise to get the ability to bypass the congestion till something is done to resolve it. No real opinion on the solution. I think Kano has said in the past he did not want to allow us to set payment thresholds but back then this congestion problem did not exist. I also believe he does our payments with zero fees since its in our blocks. he could do it one weekend a month which might make it easy to track. Agreed, lets see if anyone else has suggestions and see if Kano can propose something..... If we are going to be hitting 55-65 blocks per month . One weekend could be 2-4 blocks it would be able to clear the multi payments . at 100 sats a byte the price is better then other places. and it does not crush the earnings for the month. the trick is how hard to code it. all the miners benefit 100 sats a byte vs 300 sats . and those blocks would be in the .9 btc for fees range which we get some of the time anyway. Could automate, from your account page could submit the transaction and have it sit there till the next weekend run. Either submit to network at 100 sats a byte and provide transaction ID via account page or just enter the entire transaction on the account page in RAW format. Few options here, but like you said depends on coding and testing time. |
|
|
|
Looking for advise or maybe Kano's help... I've been mining here close to 2 yrs and monthly transfer the 60-100 small payments to another address, mainly to consolidate so when I need to actually send BTC external it does not take 15m using my Trezor to sign and cost a fortune due to size. I usually do a low fee cause I don't care how long my consolidation transaction takes, usually costs me 50 cents to 3 bucks to do this, it did last month anyway.
With the huge men pool now, I tried to do this yesterday and even a low fee was 26 bucks and normal fee was over 60 bucks. again due to so many small inputs and thus transaction KB size. Thinking of ways to solve this issue, Since Kano uses our blocks to send out payments, maybe we would be able to select a payout threshold, .25 or .5 or something like that. That would help. Another thought is send it to network with a low standard fee of .0002 and then provide Kano the transaction ID so he can include in our next block, kind of a perk for mining here and getting a faster lane on the congested BTC highway. Again, only for addresses that he has in DB as payment addresses, so no abuse as input addresses need to match pool payment addresses. Anyway, looking for some suggestions with this consolidation issue, I'm sure I'm not the only one, as I have seen others here do the same thing monthly or weekly consolidation into a new address.
well if he did it every other sunday 2x a month with 100 sats per byte it would only affect a few blocks with lower payments. at 300 sats it is about .0006 per block at 100 sats it is about .0002 per block so 2 weeks is about 30 blocks or .0180 vs .0060 That's not much to give up pool wise to get the ability to bypass the congestion till something is done to resolve it. No real opinion on the solution. I think Kano has said in the past he did not want to allow us to set payment thresholds but back then this congestion problem did not exist. I also believe he does our payments with zero fees since its in our blocks. he could do it one weekend a month which might make it easy to track. Agreed, lets see if anyone else has suggestions and see if Kano can propose something..... |
|
|
|
Looking for advise or maybe Kano's help... I've been mining here close to 2 yrs and monthly transfer the 60-100 small payments to another address, mainly to consolidate so when I need to actually send BTC external it does not take 15m using my Trezor to sign and cost a fortune due to size. I usually do a low fee cause I don't care how long my consolidation transaction takes, usually costs me 50 cents to 3 bucks to do this, it did last month anyway.
With the huge men pool now, I tried to do this yesterday and even a low fee was 26 bucks and normal fee was over 60 bucks. again due to so many small inputs and thus transaction KB size. Thinking of ways to solve this issue, Since Kano uses our blocks to send out payments, maybe we would be able to select a payout threshold, .25 or .5 or something like that. That would help. Another thought is send it to network with a low standard fee of .0002 and then provide Kano the transaction ID so he can include in our next block, kind of a perk for mining here and getting a faster lane on the congested BTC highway. Again, only for addresses that he has in DB as payment addresses, so no abuse as input addresses need to match pool payment addresses. Anyway, looking for some suggestions with this consolidation issue, I'm sure I'm not the only one, as I have seen others here do the same thing monthly or weekly consolidation into a new address.
well if he did it every other sunday 2x a month with 100 sats per byte it would only affect a few blocks with lower payments. at 300 sats it is about .0006 per block at 100 sats it is about .0002 per block so 2 weeks is about 30 blocks or .0180 vs .0060 That's not much to give up pool wise to get the ability to bypass the congestion till something is done to resolve it. No real opinion on the solution. I think Kano has said in the past he did not want to allow us to set payment thresholds but back then this congestion problem did not exist. I also believe he does our payments with zero fees since its in our blocks. |
|
|
|
|
Looking for advise or maybe Kano's help... I've been mining here close to 2 yrs and monthly transfer the 60-100 small payments to another address, mainly to consolidate so when I need to actually send BTC external it does not take 15m using my Trezor to sign and cost a fortune due to size. I usually do a low fee cause I don't care how long my consolidation transaction takes, usually costs me 50 cents to 3 bucks to do this, it did last month anyway.
With the huge men pool now, I tried to do this yesterday and even a low fee was 26 bucks and normal fee was over 60 bucks. again due to so many small inputs and thus transaction KB size. Thinking of ways to solve this issue, Since Kano uses our blocks to send out payments, maybe we would be able to select a payout threshold, .25 or .5 or something like that. That would help. Another thought is send it to network with a low standard fee of .0002 and then provide Kano the transaction ID so he can include in our next block, kind of a perk for mining here and getting a faster lane on the congested BTC highway. Again, only for addresses that he has in DB as payment addresses, so no abuse as input addresses need to match pool payment addresses. Anyway, looking for some suggestions with this consolidation issue, I'm sure I'm not the only one, as I have seen others here do the same thing monthly or weekly consolidation into a new address.
|
|
|
|
Hi
I have the EVGA SuperNOVA 1000W GOLD GQ (210GQ1000V2) power supply. It's a 80+ GOLD 1000W.
Is it safe to stay at 1070w from the wall all day long ? Can I go up to 1100w ?
That kind of load I would use a 1300w PSU, you are getting crap efficiency pushing it to 1070w and will not last long at that load. You want to be at 80% load so a 1000w PSU should be 800w. |
|
|
|
I seem to have an issue, well two issues. #1 the miner crashes/freezes after it exits or the watchdog restarts it and I can't figure out why. #2 here's a the log file of the GPUs halting and the miner restarting. Why did the GPUs stop, I can't figure out why? It crashed/froze after it restarted and I lost many hours of mining time. 00:23:58:748 3cff9700 parse packet: 236
00:23:58:748 3cff9700 ETH: job changed
00:23:58:748 3cff9700 new buf size: 0
00:23:58:748 3cff9700 ETH: 05/05/17-00:23:58 - New job from musicoin.nomnom.technology:9999
00:23:58:748 3cff9700 target: 0x0000000225c17d04 (diff: 2000MH), epoch #13
00:23:58:748 3cff9700 ETH - Total Speed: 98.703 Mh/s, Total Shares: 1080, Rejected: 2, Time: 06:02
00:23:58:748 3cff9700 ETH: GPU0 15.153 Mh/s, GPU1 19.916 Mh/s, GPU2 21.565 Mh/s, GPU3 21.514 Mh/s, GPU4 20.555 Mh/s
00:23:58:748 3cff9700 DCR - Total Speed: 5922.173 Mh/s, Total Shares: 1150, Rejected: 3
00:23:58:748 3cff9700 DCR: GPU0 909.169 Mh/s, GPU1 1194.958 Mh/s, GPU2 1293.899 Mh/s, GPU3 1290.819 Mh/s, GPU4 1233.328 Mh/s
00:23:58:888 68a84740 GPU0 t=62C fan=90%, GPU1 t=63C fan=84%, GPU2 t=61C fan=43%, GPU3 t=59C fan=40%, GPU4 t=62C fan=40%
00:23:58:888 68a84740 em hbt: 1, dm hbt: 1, fm hbt: 1,
00:23:58:888 68a84740 watchdog - thread 0, hb time 2758
00:23:58:888 68a84740 watchdog - thread 1, hb time 2794
00:23:58:888 68a84740 watchdog - thread 2, hb time 2801
00:23:58:888 68a84740 watchdog - thread 3, hb time 2775
00:23:58:889 68a84740 watchdog - thread 4, hb time 2775
00:23:58:889 68a84740 watchdog - thread 5, hb time 2799
00:23:58:889 68a84740 watchdog - thread 6, hb time 2771
00:23:58:889 68a84740 watchdog - thread 7, hb time 2796
00:23:58:889 68a84740 watchdog - thread 8, hb time 2809
00:23:58:889 68a84740 watchdog - thread 9, hb time 2783
00:23:59:318 3cff9700 ETH: checking pool connection...
00:23:59:318 3cff9700 send: {"worker": "", "jsonrpc": "2.0", "params": [], "id": 3, "method": "eth_getWork"}
00:23:59:352 3cff9700 got 237 bytes
00:23:59:352 3cff9700 buf: {"id":3,"jsonrpc":"2.0","result":["0xadeb49a0172a832df58961677253b80dbd44e1be76f0d1dc9743b9f55427fbe0","0x9b1ca7a86d339a3f175e48937848ac1cc012678e046b8c433a226d06f0f9bf9b","0x0225c17d04dad2965cc5a02a23e254c0c3f75d9178046aeb27ce1ca574"]}
00:23:59:352 3cff9700 parse packet: 236
00:23:59:352 3cff9700 ETH: job is the same
00:23:59:352 3cff9700 new buf size: 0
00:24:03:769 3dffb700 GPU4 DAG creation time - 5018 ms
00:24:03:769 3dffb700 Setting DAG epoch #121 for GPU4 done
00:24:03:769 3dffb700 DevFee: restart timer because of updating DAG
00:24:03:769 5544e700 Setting DAG epoch #121 for GPU1
00:24:07:855 3cff9700 send: {"id":6,"worker":"linux","jsonrpc":"2.0","method":"eth_submitHashrate","params":["0x139a9fb", "0x000000000000000000000000000000000000000000000000000000003a79d94e"]}
00:24:07:889 3cff9700 got 39 bytes
00:24:07:889 3cff9700 buf: {"id":6,"jsonrpc":"2.0","result":true}
00:24:07:889 3cff9700 parse packet: 38
00:24:07:889 3cff9700 new buf size: 0
00:24:08:763 5544e700 GPU1 DAG creation time - 4894 ms
00:24:08:763 5544e700 Setting DAG epoch #121 for GPU1 done
00:24:08:763 5544e700 DevFee: restart timer because of updating DAG
00:24:08:763 3f7fe700 Setting DAG epoch #121 for GPU2
00:24:09:319 3cff9700 ETH: checking pool connection...
00:24:09:319 3cff9700 send: {"worker": "", "jsonrpc": "2.0", "params": [], "id": 3, "method": "eth_getWork"}
00:24:09:354 3cff9700 got 237 bytes
00:24:09:354 3cff9700 buf: {"id":3,"jsonrpc":"2.0","result":["0xadeb49a0172a832df58961677253b80dbd44e1be76f0d1dc9743b9f55427fbe0","0x9b1ca7a86d339a3f175e48937848ac1cc012678e046b8c433a226d06f0f9bf9b","0x0225c17d04dad2965cc5a02a23e254c0c3f75d9178046aeb27ce1ca574"]}
00:24:09:354 3cff9700 parse packet: 236
00:24:09:354 3cff9700 ETH: job is the same
00:24:09:354 3cff9700 new buf size: 0
00:24:10:864 5544e700 ETH: put share nonce 289644a40270f06d
00:24:10:864 5544e700 DevFee: ETH round found 1 shares
00:24:10:864 3bff7700 DevFee: ETH: 05/05/17-00:24:10 - SHARE FOUND - (GPU 1)
00:24:10:864 3bff7700 send: {"id":4,"method":"eth_submitWork","params":["0x289644a40270f06d","0xd3fceb4972e2bb316d331c1ac07c817488888b6fbea6fca37f6bcce90a169121","0x479ed8ffc20b8e8989ea6ac9dd0d411f394bd07777174f2c774a65a4d2f5a815"]}
00:24:10:961 3bff7700 got 39 bytes
00:24:10:961 3bff7700 buf: {"id":4,"jsonrpc":"2.0","result":true}
00:24:10:961 3bff7700 parse packet: 38
00:24:10:961 3bff7700 ETH: Share accepted (96 ms)!
00:24:10:961 3bff7700 new buf size: 0
00:24:10:980 3bff7700 got 248 bytes
00:24:10:980 3bff7700 buf: {"id":0,"jsonrpc":"2.0","result":["0x2cf04207cd9afbc1e426cda6b5e286ca84d6986fe0f5aa063a7d398af9b661b5","0x064ef82d7269405eb06162f7d33f2b6aa2a23741c9a0d06a648460e17b48ab4c","0x0112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x37bf46"]}
00:24:10:980 3bff7700 parse packet: 247
00:24:10:980 3bff7700 ETH: job changed
00:24:10:980 3bff7700 new buf size: 0
00:24:10:980 3bff7700 DevFee: ETH: 05/05/17-00:24:10 - New job from us1.ethpool.org:3333
00:24:10:980 3bff7700 target: 0x0000000112e0be82
00:24:13:879 3f7fe700 GPU2 DAG creation time - 5017 ms
00:24:13:879 3f7fe700 Setting DAG epoch #121 for GPU2 done
00:24:13:879 3f7fe700 DevFee: restart timer because of updating DAG
00:24:13:879 3e7fc700 Setting DAG epoch #121 for GPU3
00:24:16:907 68a84740 Got incorrect temperature 511, ignore
00:24:16:907 68a84740 Got incorrect temperature 511, ignore
00:24:16:907 68a84740 Got incorrect temperature 511, ignore
00:24:16:908 68a84740 Got incorrect temperature 511, ignore
00:24:19:321 3cff9700 ETH: checking pool connection...
00:24:19:321 3cff9700 send: {"worker": "", "jsonrpc": "2.0", "params": [], "id": 3, "method": "eth_getWork"}
00:24:19:357 3cff9700 got 237 bytes
00:24:19:357 3cff9700 buf: {"id":3,"jsonrpc":"2.0","result":["0xadeb49a0172a832df58961677253b80dbd44e1be76f0d1dc9743b9f55427fbe0","0x9b1ca7a86d339a3f175e48937848ac1cc012678e046b8c433a226d06f0f9bf9b","0x0225c17d04dad2965cc5a02a23e254c0c3f75d9178046aeb27ce1ca574"]}
00:24:19:357 3cff9700 parse packet: 236
00:24:19:357 3cff9700 ETH: job is the same
00:24:19:357 3cff9700 new buf size: 0
00:24:19:494 3cff9700 got 237 bytes
00:24:19:495 3cff9700 buf: {"id":0,"jsonrpc":"2.0","result":["0x3c2c66c4303add4353de34af2e76d112c2907f95e17ebd94372d57484596e0e4","0x9b1ca7a86d339a3f175e48937848ac1cc012678e046b8c433a226d06f0f9bf9b","0x0225c17d04dad2965cc5a02a23e254c0c3f75d9178046aeb27ce1ca574"]}
00:24:19:495 3cff9700 parse packet: 236
00:24:19:495 3cff9700 ETH: job changed
00:24:19:495 3cff9700 new buf size: 0
00:24:19:495 3cff9700 ETH: 05/05/17-00:24:19 - New job from musicoin.nomnom.technology:9999
00:24:19:495 3cff9700 target: 0x0000000225c17d04 (diff: 2000MH), epoch #13
00:24:19:495 3cff9700 ETH - Total Speed: 0.000 Mh/s, Total Shares: 1080, Rejected: 2, Time: 06:03
00:24:19:495 3cff9700 ETH: GPU0 0.000 Mh/s, GPU1 0.000 Mh/s, GPU2 0.000 Mh/s, GPU3 0.000 Mh/s, GPU4 0.000 Mh/s
00:24:19:495 3cff9700 DCR - Total Speed: 0.000 Mh/s, Total Shares: 1150, Rejected: 3
00:24:19:495 3cff9700 DCR: GPU0 0.000 Mh/s, GPU1 0.000 Mh/s, GPU2 0.000 Mh/s, GPU3 0.000 Mh/s, GPU4 0.000 Mh/s
00:24:19:910 68a84740 Got incorrect temperature 511, ignore
00:24:19:910 68a84740 Got incorrect temperature 511, ignore
00:24:19:910 68a84740 Got incorrect temperature 511, ignore
00:24:19:910 68a84740 Got incorrect temperature 511, ignore
00:24:20:012 3bff7700 got 248 bytes
00:24:20:012 3bff7700 buf: {"id":0,"jsonrpc":"2.0","result":["0xe22b4abeb25b318936269369f09a2b7f3fee6ab4d84512e5d2490fc7444e1e5d","0x064ef82d7269405eb06162f7d33f2b6aa2a23741c9a0d06a648460e17b48ab4c","0x0112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x37bf47"]}
Same things happens to me so I used "-r 1" with a reboot. bat and the miner reboots my computer instead of restarting and hanging. Mind to share your reboot.bat file ? And- I had same "incorrect temp 511" log, riser was burning @ molex, yellow (12V ) pin... Your cards are overburdened. It is on the OP under the -r option. Claymore tells you what to put in the reboot.bat to execute a reboot. Just go to page 1 and the first post and look for it. so your reboot.bat contains "shutdown /r /t 5 /f" ? Because that is where you pointed me. See, I try to be helpful sharing my experience with you. From other side you tell me to read OP? Next time you ask for advice/help I will point you to page 1. @PPOC: Temps? Temp runs 88-92, warmer then I'd like but don't think it throttles till 95. Suprised on the temp with an EK block on it with a 3 fan Rad. I'd not bother mining Eth+DCR with a GTX 1080, you will get much better results mining ZCASH on that GPU. ZCASH also runs cooler and uses less power, so that may solve your temperature issue as well as bringing in more $. Turns out have a defective temp sensor on the GPU, I checked the liquid temps (with thermometer) and also CPU temp (via CPUz) in the same loop which is right after GPU and in the 60's while the GPU was going to 93 within minutes of miner starting. Did and RMA and should have new card next week, since I have to take apart the water block, will flush out and check for any buildup on the block also. Thank you for all the comments! |
|
|
|
I seem to have an issue, well two issues. #1 the miner crashes/freezes after it exits or the watchdog restarts it and I can't figure out why. #2 here's a the log file of the GPUs halting and the miner restarting. Why did the GPUs stop, I can't figure out why? It crashed/froze after it restarted and I lost many hours of mining time. 00:23:58:748 3cff9700 parse packet: 236
00:23:58:748 3cff9700 ETH: job changed
00:23:58:748 3cff9700 new buf size: 0
00:23:58:748 3cff9700 ETH: 05/05/17-00:23:58 - New job from musicoin.nomnom.technology:9999
00:23:58:748 3cff9700 target: 0x0000000225c17d04 (diff: 2000MH), epoch #13
00:23:58:748 3cff9700 ETH - Total Speed: 98.703 Mh/s, Total Shares: 1080, Rejected: 2, Time: 06:02
00:23:58:748 3cff9700 ETH: GPU0 15.153 Mh/s, GPU1 19.916 Mh/s, GPU2 21.565 Mh/s, GPU3 21.514 Mh/s, GPU4 20.555 Mh/s
00:23:58:748 3cff9700 DCR - Total Speed: 5922.173 Mh/s, Total Shares: 1150, Rejected: 3
00:23:58:748 3cff9700 DCR: GPU0 909.169 Mh/s, GPU1 1194.958 Mh/s, GPU2 1293.899 Mh/s, GPU3 1290.819 Mh/s, GPU4 1233.328 Mh/s
00:23:58:888 68a84740 GPU0 t=62C fan=90%, GPU1 t=63C fan=84%, GPU2 t=61C fan=43%, GPU3 t=59C fan=40%, GPU4 t=62C fan=40%
00:23:58:888 68a84740 em hbt: 1, dm hbt: 1, fm hbt: 1,
00:23:58:888 68a84740 watchdog - thread 0, hb time 2758
00:23:58:888 68a84740 watchdog - thread 1, hb time 2794
00:23:58:888 68a84740 watchdog - thread 2, hb time 2801
00:23:58:888 68a84740 watchdog - thread 3, hb time 2775
00:23:58:889 68a84740 watchdog - thread 4, hb time 2775
00:23:58:889 68a84740 watchdog - thread 5, hb time 2799
00:23:58:889 68a84740 watchdog - thread 6, hb time 2771
00:23:58:889 68a84740 watchdog - thread 7, hb time 2796
00:23:58:889 68a84740 watchdog - thread 8, hb time 2809
00:23:58:889 68a84740 watchdog - thread 9, hb time 2783
00:23:59:318 3cff9700 ETH: checking pool connection...
00:23:59:318 3cff9700 send: {"worker": "", "jsonrpc": "2.0", "params": [], "id": 3, "method": "eth_getWork"}
00:23:59:352 3cff9700 got 237 bytes
00:23:59:352 3cff9700 buf: {"id":3,"jsonrpc":"2.0","result":["0xadeb49a0172a832df58961677253b80dbd44e1be76f0d1dc9743b9f55427fbe0","0x9b1ca7a86d339a3f175e48937848ac1cc012678e046b8c433a226d06f0f9bf9b","0x0225c17d04dad2965cc5a02a23e254c0c3f75d9178046aeb27ce1ca574"]}
00:23:59:352 3cff9700 parse packet: 236
00:23:59:352 3cff9700 ETH: job is the same
00:23:59:352 3cff9700 new buf size: 0
00:24:03:769 3dffb700 GPU4 DAG creation time - 5018 ms
00:24:03:769 3dffb700 Setting DAG epoch #121 for GPU4 done
00:24:03:769 3dffb700 DevFee: restart timer because of updating DAG
00:24:03:769 5544e700 Setting DAG epoch #121 for GPU1
00:24:07:855 3cff9700 send: {"id":6,"worker":"linux","jsonrpc":"2.0","method":"eth_submitHashrate","params":["0x139a9fb", "0x000000000000000000000000000000000000000000000000000000003a79d94e"]}
00:24:07:889 3cff9700 got 39 bytes
00:24:07:889 3cff9700 buf: {"id":6,"jsonrpc":"2.0","result":true}
00:24:07:889 3cff9700 parse packet: 38
00:24:07:889 3cff9700 new buf size: 0
00:24:08:763 5544e700 GPU1 DAG creation time - 4894 ms
00:24:08:763 5544e700 Setting DAG epoch #121 for GPU1 done
00:24:08:763 5544e700 DevFee: restart timer because of updating DAG
00:24:08:763 3f7fe700 Setting DAG epoch #121 for GPU2
00:24:09:319 3cff9700 ETH: checking pool connection...
00:24:09:319 3cff9700 send: {"worker": "", "jsonrpc": "2.0", "params": [], "id": 3, "method": "eth_getWork"}
00:24:09:354 3cff9700 got 237 bytes
00:24:09:354 3cff9700 buf: {"id":3,"jsonrpc":"2.0","result":["0xadeb49a0172a832df58961677253b80dbd44e1be76f0d1dc9743b9f55427fbe0","0x9b1ca7a86d339a3f175e48937848ac1cc012678e046b8c433a226d06f0f9bf9b","0x0225c17d04dad2965cc5a02a23e254c0c3f75d9178046aeb27ce1ca574"]}
00:24:09:354 3cff9700 parse packet: 236
00:24:09:354 3cff9700 ETH: job is the same
00:24:09:354 3cff9700 new buf size: 0
00:24:10:864 5544e700 ETH: put share nonce 289644a40270f06d
00:24:10:864 5544e700 DevFee: ETH round found 1 shares
00:24:10:864 3bff7700 DevFee: ETH: 05/05/17-00:24:10 - SHARE FOUND - (GPU 1)
00:24:10:864 3bff7700 send: {"id":4,"method":"eth_submitWork","params":["0x289644a40270f06d","0xd3fceb4972e2bb316d331c1ac07c817488888b6fbea6fca37f6bcce90a169121","0x479ed8ffc20b8e8989ea6ac9dd0d411f394bd07777174f2c774a65a4d2f5a815"]}
00:24:10:961 3bff7700 got 39 bytes
00:24:10:961 3bff7700 buf: {"id":4,"jsonrpc":"2.0","result":true}
00:24:10:961 3bff7700 parse packet: 38
00:24:10:961 3bff7700 ETH: Share accepted (96 ms)!
00:24:10:961 3bff7700 new buf size: 0
00:24:10:980 3bff7700 got 248 bytes
00:24:10:980 3bff7700 buf: {"id":0,"jsonrpc":"2.0","result":["0x2cf04207cd9afbc1e426cda6b5e286ca84d6986fe0f5aa063a7d398af9b661b5","0x064ef82d7269405eb06162f7d33f2b6aa2a23741c9a0d06a648460e17b48ab4c","0x0112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x37bf46"]}
00:24:10:980 3bff7700 parse packet: 247
00:24:10:980 3bff7700 ETH: job changed
00:24:10:980 3bff7700 new buf size: 0
00:24:10:980 3bff7700 DevFee: ETH: 05/05/17-00:24:10 - New job from us1.ethpool.org:3333
00:24:10:980 3bff7700 target: 0x0000000112e0be82
00:24:13:879 3f7fe700 GPU2 DAG creation time - 5017 ms
00:24:13:879 3f7fe700 Setting DAG epoch #121 for GPU2 done
00:24:13:879 3f7fe700 DevFee: restart timer because of updating DAG
00:24:13:879 3e7fc700 Setting DAG epoch #121 for GPU3
00:24:16:907 68a84740 Got incorrect temperature 511, ignore
00:24:16:907 68a84740 Got incorrect temperature 511, ignore
00:24:16:907 68a84740 Got incorrect temperature 511, ignore
00:24:16:908 68a84740 Got incorrect temperature 511, ignore
00:24:19:321 3cff9700 ETH: checking pool connection...
00:24:19:321 3cff9700 send: {"worker": "", "jsonrpc": "2.0", "params": [], "id": 3, "method": "eth_getWork"}
00:24:19:357 3cff9700 got 237 bytes
00:24:19:357 3cff9700 buf: {"id":3,"jsonrpc":"2.0","result":["0xadeb49a0172a832df58961677253b80dbd44e1be76f0d1dc9743b9f55427fbe0","0x9b1ca7a86d339a3f175e48937848ac1cc012678e046b8c433a226d06f0f9bf9b","0x0225c17d04dad2965cc5a02a23e254c0c3f75d9178046aeb27ce1ca574"]}
00:24:19:357 3cff9700 parse packet: 236
00:24:19:357 3cff9700 ETH: job is the same
00:24:19:357 3cff9700 new buf size: 0
00:24:19:494 3cff9700 got 237 bytes
00:24:19:495 3cff9700 buf: {"id":0,"jsonrpc":"2.0","result":["0x3c2c66c4303add4353de34af2e76d112c2907f95e17ebd94372d57484596e0e4","0x9b1ca7a86d339a3f175e48937848ac1cc012678e046b8c433a226d06f0f9bf9b","0x0225c17d04dad2965cc5a02a23e254c0c3f75d9178046aeb27ce1ca574"]}
00:24:19:495 3cff9700 parse packet: 236
00:24:19:495 3cff9700 ETH: job changed
00:24:19:495 3cff9700 new buf size: 0
00:24:19:495 3cff9700 ETH: 05/05/17-00:24:19 - New job from musicoin.nomnom.technology:9999
00:24:19:495 3cff9700 target: 0x0000000225c17d04 (diff: 2000MH), epoch #13
00:24:19:495 3cff9700 ETH - Total Speed: 0.000 Mh/s, Total Shares: 1080, Rejected: 2, Time: 06:03
00:24:19:495 3cff9700 ETH: GPU0 0.000 Mh/s, GPU1 0.000 Mh/s, GPU2 0.000 Mh/s, GPU3 0.000 Mh/s, GPU4 0.000 Mh/s
00:24:19:495 3cff9700 DCR - Total Speed: 0.000 Mh/s, Total Shares: 1150, Rejected: 3
00:24:19:495 3cff9700 DCR: GPU0 0.000 Mh/s, GPU1 0.000 Mh/s, GPU2 0.000 Mh/s, GPU3 0.000 Mh/s, GPU4 0.000 Mh/s
00:24:19:910 68a84740 Got incorrect temperature 511, ignore
00:24:19:910 68a84740 Got incorrect temperature 511, ignore
00:24:19:910 68a84740 Got incorrect temperature 511, ignore
00:24:19:910 68a84740 Got incorrect temperature 511, ignore
00:24:20:012 3bff7700 got 248 bytes
00:24:20:012 3bff7700 buf: {"id":0,"jsonrpc":"2.0","result":["0xe22b4abeb25b318936269369f09a2b7f3fee6ab4d84512e5d2490fc7444e1e5d","0x064ef82d7269405eb06162f7d33f2b6aa2a23741c9a0d06a648460e17b48ab4c","0x0112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x37bf47"]}
Same things happens to me so I used "-r 1" with a reboot. bat and the miner reboots my computer instead of restarting and hanging. Mind to share your reboot.bat file ? And- I had same "incorrect temp 511" log, riser was burning @ molex, yellow (12V ) pin... Your cards are overburdened. It is on the OP under the -r option. Claymore tells you what to put in the reboot.bat to execute a reboot. Just go to page 1 and the first post and look for it. so your reboot.bat contains "shutdown /r /t 5 /f" ? Because that is where you pointed me. See, I try to be helpful sharing my experience with you. From other side you tell me to read OP? Next time you ask for advice/help I will point you to page 1. @PPOC: Temps? Temp runs 88-92, warmer then I'd like but don't think it throttles till 95. Suprised on the temp with an EK block on it with a 3 fan Rad. |
|
|
|
|
Running latest 9.3 miner on a GTX1080 liquid cooled rig with an i7700. Running dual ETH and DCR, Miner starts fine and does 21 Eth and 210 Dcr. Always seams to be a 10X relationship between ETH and DCR. After 5-10 min, its start dropping slowly and levels off around 11 ETH and 110 DCR. Anyone have anything similar with 1080, 1070 or 1060?
This also happens when I do ETH only, that starts out around 23 and slowly drops to 12 or so after 10m or so.
Any help greatly appreciated!
|
|
|
|
I'd like to try one out Why don't you just buy an Avalon741 instead? Already have a few 741's. if the E9 is for real, it's a bit better on power and cost so wanted to try one but looking for some trusted reviews first. |
|
|
|
Anyone buy a eBit miner from https://www.eastshore.xyz and have it shipped to US? I'd like to try one out but just don't see enough good reviews (from established trusted users) of EastShore or the eBit in the US. |
|
|
|
|
Tested v11 on 295x2, v10 had 300 per GPU, so 600-605 on the card which has 2 GPU's. V11 is getting me get 310 per GPU, so 620-625 per card. I'd say 4-5% improvement. But I had to downgrade driver to 15.12. Was running 16.11 before.
|
|
|
|
I'm seeing a decent improvement in v11. Nice job, about 15% |
|
|
|
|
v10 is a good improvement on 480's, getting 255mh stock. But I also have a bunch of 295x2's and no improvement there, getting 300mh with v10, just like 9.2 and 9.3. Anyone find similar results?
|
|
|
|
Nvidia people are beating us.
Almost 500 H/s with their overpriced 1070 and almost 600 H/s with the even more overpriced 1080.
What miner is getting 600 H/s on the 1080? |
|
|
|
|
Show Posts
