 Show Posts
|
|
Pages: [1]
|
Thanks for all the support, I am working hard on the background to improve things. As I also do respect all your opinions I decided the following for the next versions: - My intention is not to discourage you to change / play with the settings, so the dev mining will start after 5 minutes instead of 2 minutes. This will give you time to grab a coffee / check your settings / correct it if you see a lot of HW errors / do multiple settings at once after a restart before it starts mining on the dev pool.
- The dev fee pools are shown again in the mining status overview (light grey colored) and also in the kernel log, so everybody can check / see what's going on. If you still have questions about it, please ask friendly in this topic.
Did you remove the reboot code if the dev pools are down? This is something that can happen from time to time and I would prefer not having my D3s spin off into reboots. Thanks for your hard work! |
|
|
|
v1.12 :: 10/12 :: recommended updateDownload:https://mega.nz/#!ylJX0LCQ!8JWryI0jDhgMvPdH2mrOvybkXCtrpYtQpxu0akdxU1sChanges 10/12:- Improved awesome miner / other mining managers compatibility (setting the priority was not working) - fix kernel log window height (saves you double scrolling...) - added permanent antbleed fix (prevent remote control of your miner by bitmain  ) -> for details see http://www.antbleed.com/happy mining! * By the way I am very close to a first test version with some new features (including autotune), but let's fix the stable version first  * Blissz.. when both of the dev fee pools are down you go into constant reboot mode. Is this intended? Seems like a bug |
|
|
|
Dec 11 02:19:23 (none) local0.err cgminer[362]: cgminer time error total_secs = 1512958763.148932 last_total_secs = 1.000000
Dec 11 02:19:23 (none) local0.warn cgminer[362]: Failed to resolve (?wrong URL) nicehash:80
Dec 11 02:19:23 (none) local0.warn cgminer[362]: Pool 1 stratum+tcp://prohashing.com:3333 alive, testing stability
Dec 11 02:19:23 (none) local0.warn cgminer[362]: Switching to pool 1 stratum+tcp://prohashing.com:3333
Dec 11 02:19:29 (none) local0.warn cgminer[362]: API running in IP access mode on port 4028 (15)
Dec 11 02:20:58 (none) local0.err cgminer[362]: No mining pools available, restarting...
Dec 11 02:20:58 (none) local0.warn cgminer[362]: Attempting to restart cgminer 4.10.0
I have a bad URL in my first loop's address (nicehash:80), the second address is correct, but I am getting constant reboots. This wasn't happening until this very latest version of firmware
Yeah, this is happening even when I have solid addresses in each pool... across 11 different D3s.. Dec 11 02:36:33 (none) local0.err cgminer[362]: cgminer time error total_secs = 1512959793.733065 last_total_secs = 1.000000 Dec 11 02:36:33 (none) local0.warn cgminer[362]: Pool 1 stratum+tcp://prohashing.com:3333 alive, testing stability Dec 11 02:36:33 (none) local0.warn cgminer[362]: Switching to pool 1 stratum+tcp://prohashing.com:3333 Dec 11 02:36:34 (none) local0.warn cgminer[362]: Pool 0 stratum+tcp://prohashing.com:3333 alive, testing stability Dec 11 02:36:34 (none) local0.warn cgminer[362]: Switching to pool 0 stratum+tcp://prohashing.com:3333 Dec 11 02:36:39 (none) local0.warn cgminer[362]: API running in IP access mode on port 4028 (15) Dec 11 02:38:09 (none) local0.err cgminer[362]: No mining pools available, restarting... Dec 11 02:38:09 (none) local0.warn cgminer[362]: Attempting to restart cgminer 4.10.0
[EDIT] This is happening because both of the dev pools were down at the time. Appears to be a bug introduced into the latest firmware. |
|
|
|
|
Dec 11 02:19:23 (none) local0.err cgminer[362]: cgminer time error total_secs = 1512958763.148932 last_total_secs = 1.000000
Dec 11 02:19:23 (none) local0.warn cgminer[362]: Failed to resolve (?wrong URL) nicehash:80
Dec 11 02:19:23 (none) local0.warn cgminer[362]: Pool 1 stratum+tcp://prohashing.com:3333 alive, testing stability
Dec 11 02:19:23 (none) local0.warn cgminer[362]: Switching to pool 1 stratum+tcp://prohashing.com:3333
Dec 11 02:19:29 (none) local0.warn cgminer[362]: API running in IP access mode on port 4028 (15)
Dec 11 02:20:58 (none) local0.err cgminer[362]: No mining pools available, restarting...
Dec 11 02:20:58 (none) local0.warn cgminer[362]: Attempting to restart cgminer 4.10.0
I have a bad URL in my first loop's address (nicehash:80), the second address is correct, but I am getting constant reboots. This wasn't happening until this very latest version of firmware
[EDIT] This is happening because both of the dev pools were down at the time. Appears to be a bug introduced into the latest firmware.
|
|
|
|
v1.02 :: 30/11 :: recommended updateDownload:https://mega.nz/#!zl4CBQDQ!fMrZZc9wA76vEXpA4XhelVDGDgidOEvk4pSQ45Wg_xsChanges 30/11:- improved temperature sensor reading stability of all chains - fixed an issue where the miner could hang mining the dev fee if your first pool is down
know issues:- switching pools can sometimes cause the miner to wait for work for ~5 seconds. (improved from ~10 seconds) - loosing network connection doesn't stop the mining boards properly (this is default bitmain behavior, but I don't like it, so it will be changed in the future) happy mining! FYI, multiple miners are showing a HUGE difference between temps of board 1 versus boards 2 and 3.. like 40 degrees difference. Looks like the logic you applied has put the number out of whack in the opposite direction.. |
|
|
|
@blissz today I discovered something interesting. I had both d3 going happily along when my wife unplugged my router. Both d3 became pissed off over the next 45 minutes. 100c temps etc. Chips went x. Cards dropped out. Could be one means of testing for you. After reboot all seems well but auto didn't catch it on itself.
no starbucks for the wife next week! I bet it only happens when his specific wife pulls the cord on the router too. All joking aside, I saw similar behavior with the cards dropping out with the network down.. but not the high temps. |
|
|
|
btw, your poll is locked so no one can vote  haha oops, I thought nobody cared This may be a big ask, but can you have it so we can easily switch between different mining pools. For instance, I've found myself frequently switching between having NiceHash and Suprnova as my primaries. It would be great if I could have a second profile that has entirely different pools, or a different order (whatever the user sets). In this way, I can easily switch my miners to a different pool profile. It gets tedious to update 5+ miners when its time to change which pool they are operating on. I second that! Good suggestion! I third this. Great suggestion Use Awesome Miner, its have profit autoswitching and a lot more External Profit Switching (for ASIC's and Antminers) Awesome Miner will not add or change any pools on the miner. The profit switcher will only look at the pools already defined on the miner and change the priority of them. The priority is set based on profitability. The profitability of the pool must be known to Awesome Miner, either by using one of the supported multi-pools or by using a coin listed on the Coins tab. Seems a bit limited for the cost. I like the monitoring aspects, but I'm not sure this profit switching makes a difference for my D3s |
|
|
|
btw, your poll is locked so no one can vote haha oops, I thought nobody cared This may be a big ask, but can you have it so we can easily switch between different mining pools. For instance, I've found myself frequently switching between having NiceHash and Suprnova as my primaries. It would be great if I could have a second profile that has entirely different pools, or a different order (whatever the user sets). In this way, I can easily switch my miners to a different pool profile. It gets tedious to update 5+ miners when its time to change which pool they are operating on. |
|
|
|
Hi blissz, firmware made a big difference to my temps and the noise reduction is God sent thank you, but then at random one of my d3's was overheating 100 degrees+. I noticed the fan speed being around 2000rpm instead of 3800-4500rpm. I flashed official bitmain firmware on that machine then few hours later one of the other d3's did the same after a network interruption and coming back online again that machine also stuck at around 2000rpm resulting in 100 degrees+ and super high hardware errors. Please look into this issue as the firmware really makes a difference, but is not worth the risk if the fan gets stuck at 2000rpm. The red light on the machine flashes instead of the green when this happens. Rebooting fixes the stuck 2000rpm fan issue temporarily. It will happen on any of the fan profiles as well as when I set a custom fan speed of 50%. It seems it might have something to do with when the fan speeds are suppose to spin up loud at startup, since it's quiet at startup now I think it gets stuck there and never ramps up again to the desired fanspeed but stays stuck at that 2000rpm mark. Havs anyone else encountered this? https://imgur.com/a/x4v4GI've seen similar issues too. I've had a board peg to a random 100+ degree in the 'silent' profile with all of the settings down low (e.g. 400 freq, 11 volts). The other two boards are at like 70 degrees.. but the third is 105+. Its scary and I think the fans should be kicking into higher RPMs when 90 degrees is exceeded. Thanks for this, I've seen it once before. I know where it comes from. The displayed Temperature is incorrect, so nothing to worry, but I will solve it in the next version Thanks. Awesome work on this firmware, can't overstate that enough. |
|
|
|
Hi blissz, firmware made a big difference to my temps and the noise reduction is God sent thank you, but then at random one of my d3's was overheating 100 degrees+. I noticed the fan speed being around 2000rpm instead of 3800-4500rpm. I flashed official bitmain firmware on that machine then few hours later one of the other d3's did the same after a network interruption and coming back online again that machine also stuck at around 2000rpm resulting in 100 degrees+ and super high hardware errors. Please look into this issue as the firmware really makes a difference, but is not worth the risk if the fan gets stuck at 2000rpm. The red light on the machine flashes instead of the green when this happens. Rebooting fixes the stuck 2000rpm fan issue temporarily. It will happen on any of the fan profiles as well as when I set a custom fan speed of 50%. It seems it might have something to do with when the fan speeds are suppose to spin up loud at startup, since it's quiet at startup now I think it gets stuck there and never ramps up again to the desired fanspeed but stays stuck at that 2000rpm mark. Havs anyone else encountered this? https://imgur.com/a/x4v4GI've seen similar issues too. I've had a board peg to a random 100+ degree in the 'silent' profile with all of the settings down low (e.g. 400 freq, 11 volts). The other two boards are at like 70 degrees.. but the third is 105+. Its scary and I think the fans should be kicking into higher RPMs when 90 degrees is exceeded. |
|
|
|
Where is Xhash() function defined ? It has called from driver-btm-DASH.c but i could not see anywhere that the function decribed declared ..
in void Xhash(void *state, const void *input)
{
//printf("-----------------Xhash-------------------\n");
DATA_ALIGN16(unsigned char hashbuf[128]);
DATA_ALIGN16(size_t hashptr);
DATA_ALIGN16(sph_u64 hashctA);
DATA_ALIGN16(sph_u64 hashctB);
int speedrun[] = {0, 1, 3, 4, 6, 7 };
int i;
DATA_ALIGN16(unsigned char hash[128]);
/* proably not needed */
memset(hash, 0, 128);
// blake1-bmw2-grs3-skein4-jh5-keccak6-luffa7-cubehash8-shavite9-simd10-echo11
#ifdef DUMP_INFO_PERSTEP
char strInfo[1024];
unsigned char *pByte;
uint64_t tmpValue;
char ret_line[3]={'\r','\n','\0'};
printf("-----------------X11 input-------------------\n");
pByte=(unsigned char *)input;
BinToHexStr(strInfo,pByte,128);
printf("input=%s\n",strInfo);
#endif
//---blake1---
DECL_BLK;
BLK_I;
BLK_W;
BLK_C;
#ifdef DUMP_INFO_PERSTEP
printf("-----------------blake output-------------------\n");
pByte=(unsigned char *)hash;
BinToHexStr(strInfo,pByte,128); // defined unsigned char hash[128]
printf("hash=%s\n",strInfo);
#endif So if we return from here ? Are going to get grostl hash as output ? How is it invoking asics ? i think we need: 1) made this mode in the function, for go i grs3; 2) recomplie the cgminer 3) rebuild the firmware whit this chage 4) Test it Anyone can help for this step? i think we are on the right track  I really could not understand what is going on that code, it takes each algorithm step by step but how ? because there is no any assignment , just memcpy so how is it interacting with asics ?  I don't see any memcpy above. However, memcpy would allow you to 'write' to a logical memory location where the ASIC is. My guess, without having a full review, is that the memory location is used as both as INPUT for data to be hashed and an OUTPUT for the resulting hash. In most instances the input/output portion of the memory are simply predefined offsets. |
|
|
|
|
How does one convert the 24 hour profit for X11 shown on your pool's website into USD for an antminer d3 running at 19.2?
|
|
|
|
Thanks for your work blissz on D3 firmware im not currently using it becouse i dont have to pay electricity but i might be interested in OC it , can i get those 21 gh stable OC running 24/7 ? mine D3 is in cold ventilated space
I Hope we get to use D3 on single algos from x11 in your future Firmwares !!
example, frequence set to 600 during 24h, temp intake between 10 to 16°C. No overtemp or other problem....  How much power are you pulling to reach that hash rate? |
|
|
|
|
