Bitcoin Forum
November 21, 2017, 04:11:28 PM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030 2031 2032 2033 2034 2035 2036 2037 2038 2039 2040 2041 2042 2043 2044 [2045] 2046 2047 2048 2049 2050 2051 2052 2053 2054 2055 2056 2057 2058 2059 2060 2061 2062 2063 2064 2065 2066 2067 2068 2069 2070 2071 2072 2073 2074 2075 2076 2077 2078 2079 2080 2081 2082 2083 2084 2085 2086 2087 2088 2089 2090 2091 2092 2093 2094 2095 ... 2138 »
  Print  
Author Topic: Swedish ASIC miner company kncminer.com  (Read 3009267 times)
GenTarkin
Legendary
*
Offline Offline

Activity: 2170


View Profile
August 12, 2015, 03:16:39 AM
 #40881

A list of changes in my next build:
Proper handling of soft vs hard die resets(if soft reset fails then proceeds to do hard reset via cube power cycling & BFGminer restart)
Custom 92/93C added to dropdown list
A scaling down of dies who's VRM (DCDC) temps cross over threshold

Future build to do:
Add auto clock scaling up for dies which were previously scaled down due to VRM overheating.


sounds great!

Thanks =), Im uploading hopefully a working img now.

I also changed back the login password to admin/admin for both ssh & webgui
*I attempted to anyways...haha will need testing =)

Once you test out this build TXSteve, please send .5btc my way =) I would greatly appreciate it =) ... That will get me rollin on auto reupping the clocks of Dies that have been declocked due to DCDC overheat.
(this will be more difficult to code cuz now I gotta keep track of original settings n do lots of comparing while running =P )

GenTarkin's MOD Kncminer Titan custom firmware! v1.0.4! <--- CLICK HERE
Donations: bitcoin- 1Px71mWNQNKW19xuARqrmnbcem1dXqJ3At || litecoin- LYXrLis3ik6TRn8tdvzAyJ264DRvwYVeEw
1511280688
Hero Member
*
Offline Offline

Posts: 1511280688

View Profile Personal Message (Offline)

Ignore
1511280688
Reply with quote  #2

1511280688
Report to moderator
1511280688
Hero Member
*
Offline Offline

Posts: 1511280688

View Profile Personal Message (Offline)

Ignore
1511280688
Reply with quote  #2

1511280688
Report to moderator
Join ICO Now A blockchain platform for effective freelancing
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1511280688
Hero Member
*
Offline Offline

Posts: 1511280688

View Profile Personal Message (Offline)

Ignore
1511280688
Reply with quote  #2

1511280688
Report to moderator
1511280688
Hero Member
*
Offline Offline

Posts: 1511280688

View Profile Personal Message (Offline)

Ignore
1511280688
Reply with quote  #2

1511280688
Report to moderator
1511280688
Hero Member
*
Offline Offline

Posts: 1511280688

View Profile Personal Message (Offline)

Ignore
1511280688
Reply with quote  #2

1511280688
Report to moderator
TXSteve
Sr. Member
****
Offline Offline

Activity: 340


View Profile
August 12, 2015, 03:33:11 AM
 #40882

A list of changes in my next build:
Proper handling of soft vs hard die resets(if soft reset fails then proceeds to do hard reset via cube power cycling & BFGminer restart)
Custom 92/93C added to dropdown list
A scaling down of dies who's VRM (DCDC) temps cross over threshold

Future build to do:
Add auto clock scaling up for dies which were previously scaled down due to VRM overheating.


sounds great!

Thanks =), Im uploading hopefully a working img now.

I also changed back the login password to admin/admin for both ssh & webgui
*I attempted to anyways...haha will need testing =)

Once you test out this build TXSteve, please send .5btc my way =) I would greatly appreciate it =) ... That will get me rollin on auto reupping the clocks of Dies that have been declocked due to DCDC overheat.
(this will be more difficult to code cuz now I gotta keep track of original settings n do lots of comparing while running =P )

no problem I'll check it out & take care of it tomorrow, about ready to call it a day here

thx again
GenTarkin
Legendary
*
Offline Offline

Activity: 2170


View Profile
August 12, 2015, 03:42:09 AM
 #40883

https://github.com/GenTarkin/Titan/releases/tag/v.93

New release published!!

---details---

Login through SSH & webgui is now: admin/admin        (should be anyways LOL! Hope I updated it correctly) =P test it peoples! =)

If soft die reset fails then initiate hard reset sequence (power off cube, restart bfgminer)
Instead of setting Dies w/ overheating DCDC's to OFF, now scales down 25mhz each check until DCDC's are under temp threshold.. If goes to 100 then sets die to OFF.
Added more temps to temp threshold setting, including all numbers between 90 & 95

*default DCDC temp monitoring settings are: ENABLED / 90C

---details---


Please test everyone, Ill fix as issues arise. Please Please donate =) Helps fuel my motivation to continue improving upon stuff =)

GenTarkin's MOD Kncminer Titan custom firmware! v1.0.4! <--- CLICK HERE
Donations: bitcoin- 1Px71mWNQNKW19xuARqrmnbcem1dXqJ3At || litecoin- LYXrLis3ik6TRn8tdvzAyJ264DRvwYVeEw
Searing
Legendary
*
Offline Offline

Activity: 1540


Tips for help? 1BzbfMHCrTeLjc7eCGrYVhH3QXSRodSuke


View Profile
August 12, 2015, 05:28:56 AM
 #40884

https://github.com/GenTarkin/Titan/releases/tag/v.93

New release published!!

---details---

Login through SSH & webgui is now: admin/admin        (should be anyways LOL! Hope I updated it correctly) =P test it peoples! =)

If soft die reset fails then initiate hard reset sequence (power off cube, restart bfgminer)
Instead of setting Dies w/ overheating DCDC's to OFF, now scales down 25mhz each check until DCDC's are under temp threshold.. If goes to 100 then sets die to OFF.
Added more temps to temp threshold setting, including all numbers between 90 & 95

*default DCDC temp monitoring settings are: ENABLED / 90C

---details---


Please test everyone, Ill fix as issues arise. Please Please donate =) Helps fuel my motivation to continue improving upon stuff =)

heh you keep adding stuff I need before i can get to installing it due to work at the end of the month...heh all suggestions I needed heh Smiley

anyway gotta buy me some coin on coinbase and shoot you some again when i can get off work enough to test this and or at least get you some btc
(main hoard is in paper wallet in safety deposit box) Smiley

I'm sure there are more then a few of us that will trickle you some more btc Smiley

again i'm sure i include everyone we appreciate your efforts (by the by all my posts till the end of the month will be away from miners at work...no joy to play with toys)


       ▀
   ▄▄▄   ▄▀
   ███ ▄▄▄▄  ██
       ████
    ▄  ▀▀▀▀
▄▄
      ██    ▀▀
██▄█▄▄▄████████
▄▄▄▄▄▄▄▄▀▀███▀▀▀
██████████████████
████▄▀▄▀▄▀███▀▀▀▀▀
████▄▀▄▀▄▀███ ▀
████▄▀▄▀▄▀████████
▀█████████████████
]
CoinPayments
█████
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████
█████
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████
█████
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████
xstr8guy
Hero Member
*****
Offline Offline

Activity: 784


Glow Stick Dance!


View Profile
August 12, 2015, 08:42:30 AM
 #40885

Quote
I can check it out pretty quickly

btw, it doesn't seem like the max temp is working, I have it set for 90c and a die hit 92c, nothing happened


Testing a rearrangement & rewrite of hard reset detection. Will have to wait till mine actually needs resetting to see if it works. If it does, it should differentiate between soft reset success vs fail and then applying hard power reset to cube if needed.
My Titan doesnt experience successfull soft resets. So, will need someone to test it out once I verify the soft reset fail then hard reset works.
It doesnt happen instantly. Think it loops every 4 seconds. Ill test it here in a lil while. I dont see why it wouldnt work but Ill double check =)
Grr nevermind, somehow it stopped writing to the config file. Ill have to look into it later. Not sure how it broke =P
Probably a typo somewhere lol

well I had 1 hard reset work flawlessly  Smiley

I'll pledge .5 btc for your efforts, if you can just drop the MHz from 325 to 300, instead of turning the die off. Also can you add another temp cut-off 93c -- I manually turn them down around 92/93 - it's usually at those temps for only a few hours, and haven't had any problems
[/quote]

Hrm....ok well I found an issue w/ the changes but only as of this morning when I started editing the code again, these erronous edits did not make it into my latest release. I fixed the issues but the release u downloaded should still have worked properly.

Any chance you can paste the contents of /var/log/monitordcdc.log when the thermal trip doesnt work for you?
It would require ssh'n into the pi and copying the contents of that file to a text file.

The test works perfect on my box when I set the temp threshold to 70....(added as a testing temp =) )
I dont even have to hit refresh on the advanced settings page, I can see the dies get turned to 0's that go over threshold, after bfgminer restarts.

Also, yes when I have more time, now that I see how KNC updates clocks without needing to restart bfgminer, I will implement a soft clock scale down w/o needing a bfgminer restart. =) I will also put 92/93C in there for ya =)
[/quote]
[/quote]

Fix the damn broken quotes! It's unreadable.
TXSteve
Sr. Member
****
Offline Offline

Activity: 340


View Profile
August 12, 2015, 09:41:23 AM
 #40886

https://github.com/GenTarkin/Titan/releases/tag/v.93

New release published!!

---details---

Login through SSH & webgui is now: admin/admin        (should be anyways LOL! Hope I updated it correctly) =P test it peoples! =)

If soft die reset fails then initiate hard reset sequence (power off cube, restart bfgminer)
Instead of setting Dies w/ overheating DCDC's to OFF, now scales down 25mhz each check until DCDC's are under temp threshold.. If goes to 100 then sets die to OFF.
Added more temps to temp threshold setting, including all numbers between 90 & 95

*default DCDC temp monitoring settings are: ENABLED / 90C

---details---


Please test everyone, Ill fix as issues arise. Please Please donate =) Helps fuel my motivation to continue improving upon stuff =)

instead of burning the new img file I tried doing a git pull:

cd knc-asic
git stash save --keep-index                (didn't need this line on all rigs)
git pull
cd
./update-webgui.sh

seems to work but did I miss anything??


helmax
Sr. Member
****
Offline Offline

Activity: 441



View Profile
August 12, 2015, 11:23:11 AM
 #40887

anyone have full image SD card 1.5 GB for neptune ?

looking job
jelin1984
Legendary
*
Offline Offline

Activity: 1582



View Profile
August 12, 2015, 01:13:00 PM
 #40888

Can you make your firmware
Work

With rasberry pi 2. Version?


That will be great

Titan firmware
GenTarkin
Legendary
*
Offline Offline

Activity: 2170


View Profile
August 12, 2015, 02:36:16 PM
 #40889

https://github.com/GenTarkin/Titan/releases/tag/v.93

New release published!!

---details---

Login through SSH & webgui is now: admin/admin        (should be anyways LOL! Hope I updated it correctly) =P test it peoples! =)

If soft die reset fails then initiate hard reset sequence (power off cube, restart bfgminer)
Instead of setting Dies w/ overheating DCDC's to OFF, now scales down 25mhz each check until DCDC's are under temp threshold.. If goes to 100 then sets die to OFF.
Added more temps to temp threshold setting, including all numbers between 90 & 95

*default DCDC temp monitoring settings are: ENABLED / 90C

---details---


Please test everyone, Ill fix as issues arise. Please Please donate =) Helps fuel my motivation to continue improving upon stuff =)

instead of burning the new img file I tried doing a git pull:

cd knc-asic
git stash save --keep-index                (didn't need this line on all rigs)
git pull
cd
./update-webgui.sh

seems to work but did I miss anything??




U would want to do the git pull from /home/pi (default dir that u log into via ssh) ... cuz otherwise the changed webpages wont download.
Then yeah, run the update-webgui.sh and u should ... *should* be set ... haha
(reapply desired temp threshold settings via webgui) .. mine defaults to ON/90

GenTarkin's MOD Kncminer Titan custom firmware! v1.0.4! <--- CLICK HERE
Donations: bitcoin- 1Px71mWNQNKW19xuARqrmnbcem1dXqJ3At || litecoin- LYXrLis3ik6TRn8tdvzAyJ264DRvwYVeEw
GenTarkin
Legendary
*
Offline Offline

Activity: 2170


View Profile
August 12, 2015, 02:36:52 PM
 #40890

Can you make your firmware
Work

With rasberry pi 2. Version?


That will be great

Titan firmware

I only have a pi to work on, so no.

GenTarkin's MOD Kncminer Titan custom firmware! v1.0.4! <--- CLICK HERE
Donations: bitcoin- 1Px71mWNQNKW19xuARqrmnbcem1dXqJ3At || litecoin- LYXrLis3ik6TRn8tdvzAyJ264DRvwYVeEw
TXSteve
Sr. Member
****
Offline Offline

Activity: 340


View Profile
August 12, 2015, 02:57:52 PM
 #40891

https://github.com/GenTarkin/Titan/releases/tag/v.93

New release published!!

---details---

Login through SSH & webgui is now: admin/admin        (should be anyways LOL! Hope I updated it correctly) =P test it peoples! =)

If soft die reset fails then initiate hard reset sequence (power off cube, restart bfgminer)
Instead of setting Dies w/ overheating DCDC's to OFF, now scales down 25mhz each check until DCDC's are under temp threshold.. If goes to 100 then sets die to OFF.
Added more temps to temp threshold setting, including all numbers between 90 & 95

*default DCDC temp monitoring settings are: ENABLED / 90C

---details---


Please test everyone, Ill fix as issues arise. Please Please donate =) Helps fuel my motivation to continue improving upon stuff =)

instead of burning the new img file I tried doing a git pull:

cd knc-asic
git stash save --keep-index                (didn't need this line on all rigs)
git pull
cd
./update-webgui.sh

seems to work but did I miss anything??




everything is upgraded and running fine so far,  just a couple observations:

-- the temp throttling is sweet, it doesn't even reboot bfgminer,  nice!!

-- you might want to implement a delay of a few min or so before triggering a hard reset because:
           a) a soft reset sometimes needs a few tries before it works and this will minimizes bfgminer restarts
               -- when the rig is rented and the customer is using an unstable pool that takes forever for vardif to adjust & stabilize,
                  frequent restarts are particularly troublesome
           b) a delay will be needed to optimize voltages & MHz, and/or to monitor which die is triggering the resets
 
anyway I'll send .5 btc to 1Px71mWNQNKW19xuARqrmnbcem1dXqJ3At   (sent)

thx again, nice work  Smiley


GenTarkin
Legendary
*
Offline Offline

Activity: 2170


View Profile
August 12, 2015, 03:31:48 PM
 #40892

https://github.com/GenTarkin/Titan/releases/tag/v.93

New release published!!

---details---

Login through SSH & webgui is now: admin/admin        (should be anyways LOL! Hope I updated it correctly) =P test it peoples! =)

If soft die reset fails then initiate hard reset sequence (power off cube, restart bfgminer)
Instead of setting Dies w/ overheating DCDC's to OFF, now scales down 25mhz each check until DCDC's are under temp threshold.. If goes to 100 then sets die to OFF.
Added more temps to temp threshold setting, including all numbers between 90 & 95

*default DCDC temp monitoring settings are: ENABLED / 90C

---details---


Please test everyone, Ill fix as issues arise. Please Please donate =) Helps fuel my motivation to continue improving upon stuff =)

instead of burning the new img file I tried doing a git pull:

cd knc-asic
git stash save --keep-index                (didn't need this line on all rigs)
git pull
cd
./update-webgui.sh

seems to work but did I miss anything??




everything is upgraded and running fine so far,  just a couple observations:

-- the temp throttling is sweet, it doesn't even reboot bfgminer,  nice!!

-- you might want to implement a delay of a few min or so before triggering a hard reset because:
           a) a soft reset sometimes needs a few tries before it works and this will minimizes bfgminer restarts
               -- when the rig is rented and the customer is using an unstable pool that takes forever for vardif to adjust & stabilize,
                  frequent restarts are particularly troublesome
           b) a delay will be needed to optimize voltages & MHz, and/or to monitor which die is triggering the resets
 
anyway I'll send .5 btc to 1Px71mWNQNKW19xuARqrmnbcem1dXqJ3At   (sent)

thx again, nice work  Smiley



AWESOME !!! Thanks a ton!!!
I just uploaded another change for webgui, it now shows bfgminer version in status screen.
Ill look into the delay for ya =)
Ill get to working on auto upscaling of cores that previously were downclocked. Have a busy schedule coming up so may not be released as quickly and this is fairly complex =)

Regarding the soft reset, do you know where the soft reset actually fails? during the waas -s command or when bfgminer is told to reconfigure...?
When u see this behaviour happen can you post the relevant contents of /var/log/monitordcdc.log? That way I can see exactly what needs delayed.(or tried a few times)

If I had to guess, soft resets I check to see when they fail the waas command. I base the success / fail of that on whether a hard reset needs to be issued. So, I could do a timed loop of say up to 5 soft resets(on like a couple second timer) via waas command and if they all fail then perform hard reset, the first one that passes it exits loop then proceeds to tell BFGminer to do its die reconfigure. *NOT: The waas command has to succeed before BFGminer will show a "die successfully configured" message.
How that sound?

GenTarkin's MOD Kncminer Titan custom firmware! v1.0.4! <--- CLICK HERE
Donations: bitcoin- 1Px71mWNQNKW19xuARqrmnbcem1dXqJ3At || litecoin- LYXrLis3ik6TRn8tdvzAyJ264DRvwYVeEw
TXSteve
Sr. Member
****
Offline Offline

Activity: 340


View Profile
August 12, 2015, 04:28:10 PM
 #40893

https://github.com/GenTarkin/Titan/releases/tag/v.93

New release published!!

---details---

Login through SSH & webgui is now: admin/admin        (should be anyways LOL! Hope I updated it correctly) =P test it peoples! =)

If soft die reset fails then initiate hard reset sequence (power off cube, restart bfgminer)
Instead of setting Dies w/ overheating DCDC's to OFF, now scales down 25mhz each check until DCDC's are under temp threshold.. If goes to 100 then sets die to OFF.
Added more temps to temp threshold setting, including all numbers between 90 & 95

*default DCDC temp monitoring settings are: ENABLED / 90C

---details---


Please test everyone, Ill fix as issues arise. Please Please donate =) Helps fuel my motivation to continue improving upon stuff =)

instead of burning the new img file I tried doing a git pull:

cd knc-asic
git stash save --keep-index                (didn't need this line on all rigs)
git pull
cd
./update-webgui.sh

seems to work but did I miss anything??




everything is upgraded and running fine so far,  just a couple observations:

-- the temp throttling is sweet, it doesn't even reboot bfgminer,  nice!!

-- you might want to implement a delay of a few min or so before triggering a hard reset because:
           a) a soft reset sometimes needs a few tries before it works and this will minimizes bfgminer restarts
               -- when the rig is rented and the customer is using an unstable pool that takes forever for vardif to adjust & stabilize,
                  frequent restarts are particularly troublesome
           b) a delay will be needed to optimize voltages & MHz, and/or to monitor which die is triggering the resets
 
anyway I'll send .5 btc to 1Px71mWNQNKW19xuARqrmnbcem1dXqJ3At   (sent)

thx again, nice work  Smiley



AWESOME !!! Thanks a ton!!!
I just uploaded another change for webgui, it now shows bfgminer version in status screen.
Ill look into the delay for ya =)
Ill get to working on auto upscaling of cores that previously were downclocked. Have a busy schedule coming up so may not be released as quickly and this is fairly complex =)

Regarding the soft reset, do you know where the soft reset actually fails? during the waas -s command or when bfgminer is told to reconfigure...?
When u see this behaviour happen can you post the relevant contents of /var/log/monitordcdc.log? That way I can see exactly what needs delayed.(or tried a few times)

If I had to guess, soft resets I check to see when they fail the waas command. I base the success / fail of that on whether a hard reset needs to be issued. So, I could do a timed loop of say up to 5 soft resets(on like a couple second timer) via waas command and if they all fail then perform hard reset, the first one that passes it exits loop then proceeds to tell BFGminer to do its die reconfigure. *NOT: The waas command has to succeed before BFGminer will show a "die successfully configured" message.
How that sound?

no, I don't know where the soft reset actually fails, I get the standard "die configuration failed" message and it tries again 20 or 30 sec later. If I can catch it I'll get the log file. I am using awesome miner to trigger hashrate alerts and can then monitor what's happening, but if the hard reset happens too quickly it doesn't trigger -- it instead triggers the rig offline alert, but then it's too late to see what happened

what you suggested sounds good to me
GenTarkin
Legendary
*
Offline Offline

Activity: 2170


View Profile
August 12, 2015, 04:51:50 PM
 #40894

https://github.com/GenTarkin/Titan/releases/tag/v.93

New release published!!

---details---

Login through SSH & webgui is now: admin/admin        (should be anyways LOL! Hope I updated it correctly) =P test it peoples! =)

If soft die reset fails then initiate hard reset sequence (power off cube, restart bfgminer)
Instead of setting Dies w/ overheating DCDC's to OFF, now scales down 25mhz each check until DCDC's are under temp threshold.. If goes to 100 then sets die to OFF.
Added more temps to temp threshold setting, including all numbers between 90 & 95

*default DCDC temp monitoring settings are: ENABLED / 90C

---details---


Please test everyone, Ill fix as issues arise. Please Please donate =) Helps fuel my motivation to continue improving upon stuff =)

instead of burning the new img file I tried doing a git pull:

cd knc-asic
git stash save --keep-index                (didn't need this line on all rigs)
git pull
cd
./update-webgui.sh

seems to work but did I miss anything??




everything is upgraded and running fine so far,  just a couple observations:

-- the temp throttling is sweet, it doesn't even reboot bfgminer,  nice!!

-- you might want to implement a delay of a few min or so before triggering a hard reset because:
           a) a soft reset sometimes needs a few tries before it works and this will minimizes bfgminer restarts
               -- when the rig is rented and the customer is using an unstable pool that takes forever for vardif to adjust & stabilize,
                  frequent restarts are particularly troublesome
           b) a delay will be needed to optimize voltages & MHz, and/or to monitor which die is triggering the resets
 
anyway I'll send .5 btc to 1Px71mWNQNKW19xuARqrmnbcem1dXqJ3At   (sent)

thx again, nice work  Smiley



AWESOME !!! Thanks a ton!!!
I just uploaded another change for webgui, it now shows bfgminer version in status screen.
Ill look into the delay for ya =)
Ill get to working on auto upscaling of cores that previously were downclocked. Have a busy schedule coming up so may not be released as quickly and this is fairly complex =)

Regarding the soft reset, do you know where the soft reset actually fails? during the waas -s command or when bfgminer is told to reconfigure...?
When u see this behaviour happen can you post the relevant contents of /var/log/monitordcdc.log? That way I can see exactly what needs delayed.(or tried a few times)

If I had to guess, soft resets I check to see when they fail the waas command. I base the success / fail of that on whether a hard reset needs to be issued. So, I could do a timed loop of say up to 5 soft resets(on like a couple second timer) via waas command and if they all fail then perform hard reset, the first one that passes it exits loop then proceeds to tell BFGminer to do its die reconfigure. *NOT: The waas command has to succeed before BFGminer will show a "die successfully configured" message.
How that sound?

no, I don't know where the soft reset actually fails, I get the standard "die configuration failed" message and it tries again 20 or 30 sec later. If I can catch it I'll get the log file. I am using awesome miner to trigger hashrate alerts and can then monitor what's happening, but if the hard reset happens too quickly it doesn't trigger -- it instead triggers the rig offline alert, but then it's too late to see what happened

what you suggested sounds good to me
Ok, cool yeah "die configuration failed" .. if I would have to assume, means the waas soft reset has failed. At least, when my rig requires a hard reset ... thats the message I get until doing the hard reset. Ill impliment the loop sometime either today or tonight =)
If other people could test out the firmware that would be great and any donations helps =)
Thanks again for ur generous donation TXSteve, I really appreciate it =)

GenTarkin's MOD Kncminer Titan custom firmware! v1.0.4! <--- CLICK HERE
Donations: bitcoin- 1Px71mWNQNKW19xuARqrmnbcem1dXqJ3At || litecoin- LYXrLis3ik6TRn8tdvzAyJ264DRvwYVeEw
GenTarkin
Legendary
*
Offline Offline

Activity: 2170


View Profile
August 12, 2015, 07:45:40 PM
 #40895

Came across a behviour issue on my Titan, I just now noticed it issues a soft reset via waas and that returns success yet it still fails to RECONFIGURE successfully in bfgminer. So, a hard reset would be inevitable and really theres no way to differentiate at this point between a soft reset full success vs failure =/
May have to reimpliment hard reset no matter what.

EDIT: yeah what a bummer, its attemping multiple soft resets w/ no success yet waas doesnt fail. I dont know if there is a way around that at this point, may have to revert just hard resets, bummer.

EDIT: rethinking it out, I may have another way to detect die status as a fallback. Coding that in will be tricky, will have to wait till later =)
Damn these things for failing so many different ways ROFL!

GenTarkin's MOD Kncminer Titan custom firmware! v1.0.4! <--- CLICK HERE
Donations: bitcoin- 1Px71mWNQNKW19xuARqrmnbcem1dXqJ3At || litecoin- LYXrLis3ik6TRn8tdvzAyJ264DRvwYVeEw
GenTarkin
Legendary
*
Offline Offline

Activity: 2170


View Profile
August 12, 2015, 08:41:48 PM
 #40896

TXSteve, so the way these things work is every loop of the monitoring script it scans how much current is going through the DCDC's and if under 5 amps is going through it basically incriments the value /var/run/dieXX
once /var/run/dieXX reaches over the threshold variable it takes action to reset the die. So...basically if the ASICs dont have work due to a shitty pool configuration like when renting... that /var/run/dieXX will get incrimented, if the pool is shitty enough and it increments over threshold ... no matter what... one of the reset actions will be taken.
Im not exactly sure whats a good way to recode this so it can differentiate between possible pool comm issues vs an actual die needing reset.
I could impliment maybe 2 thresholds, one being a lower one for the pool issues then another maybe being double of the first one?Huh and if thats reached then it performs a hard reset.
I dont know, what do you think?
Or anyone else care to chime in?
Im just kinda doing a ton of trial and error here LOL!


How this all was originally(the way KNC set it up) was on threshold and if that threshold was hit it just performed a soft reset for an eternity.



In the short term, I was thinking, pool issues aside. Now since we have this other stupid mode of failure where the waas command succeeds but it really doesnt bring the die back to life .... I could do another loop which would attempt soft resets up to say 5x sleep after each attempt, run the dcdc function to see if current is over 5A and each incriment its not, of course increase /var/run/dieXX ... then inside that same loop if /var/run/dieXX goes over the threhold then start a hard reset. I think that would solve the issue I ran into just today =)

GenTarkin's MOD Kncminer Titan custom firmware! v1.0.4! <--- CLICK HERE
Donations: bitcoin- 1Px71mWNQNKW19xuARqrmnbcem1dXqJ3At || litecoin- LYXrLis3ik6TRn8tdvzAyJ264DRvwYVeEw
TXSteve
Sr. Member
****
Offline Offline

Activity: 340


View Profile
August 12, 2015, 09:02:23 PM
 #40897

TXSteve, so the way these things work is every loop of the monitoring script it scans how much current is going through the DCDC's and if under 5 amps is going through it basically incriments the value /var/run/dieXX
once /var/run/dieXX reaches over the threshold variable it takes action to reset the die. So...basically if the ASICs dont have work due to a shitty pool configuration like when renting... that /var/run/dieXX will get incrimented, if the pool is shitty enough and it increments over threshold ... no matter what... one of the reset actions will be taken.
Im not exactly sure whats a good way to recode this so it can differentiate between possible pool comm issues vs an actual die needing reset.
I could impliment maybe 2 thresholds, one being a lower one for the pool issues then another maybe being double of the first one?Huh and if thats reached then it performs a hard reset.
I dont know, what do you think?
Or anyone else care to chime in?
Im just kinda doing a ton of trial and error here LOL!


How this all was originally(the way KNC set it up) was on threshold and if that threshold was hit it just performed a soft reset for an eternity.



In the short term, I was thinking, pool issues aside. Now since we have this other stupid mode of failure where the waas command succeeds but it really doesnt bring the die back to life .... I could do another loop which would attempt soft resets up to say 5x sleep after each attempt, run the dcdc function to see if current is over 5A and each incriment its not, of course increase /var/run/dieXX ... then inside that same loop if /var/run/dieXX goes over the threhold then start a hard reset. I think that would solve the issue I ran into just today =)

how about this? An "auto on/auto off" button & a "manual reset" button. On problematic rigs we turn auto reset off, & use manual reset as needed. It still beats physically powering down the rig, and restarting it ...just a thought

I only have one die with these flaky soft resets, so it may not be a huge overall problem
GenTarkin
Legendary
*
Offline Offline

Activity: 2170


View Profile
August 12, 2015, 09:13:57 PM
 #40898

TXSteve, so the way these things work is every loop of the monitoring script it scans how much current is going through the DCDC's and if under 5 amps is going through it basically incriments the value /var/run/dieXX
once /var/run/dieXX reaches over the threshold variable it takes action to reset the die. So...basically if the ASICs dont have work due to a shitty pool configuration like when renting... that /var/run/dieXX will get incrimented, if the pool is shitty enough and it increments over threshold ... no matter what... one of the reset actions will be taken.
Im not exactly sure whats a good way to recode this so it can differentiate between possible pool comm issues vs an actual die needing reset.
I could impliment maybe 2 thresholds, one being a lower one for the pool issues then another maybe being double of the first one?Huh and if thats reached then it performs a hard reset.
I dont know, what do you think?
Or anyone else care to chime in?
Im just kinda doing a ton of trial and error here LOL!


How this all was originally(the way KNC set it up) was on threshold and if that threshold was hit it just performed a soft reset for an eternity.



In the short term, I was thinking, pool issues aside. Now since we have this other stupid mode of failure where the waas command succeeds but it really doesnt bring the die back to life .... I could do another loop which would attempt soft resets up to say 5x sleep after each attempt, run the dcdc function to see if current is over 5A and each incriment its not, of course increase /var/run/dieXX ... then inside that same loop if /var/run/dieXX goes over the threhold then start a hard reset. I think that would solve the issue I ran into just today =)

how about this? An "auto on/auto off" button & a "manual reset" button. On problematic rigs we turn auto reset off, & use manual reset as needed. It still beats physically powering down the rig, and restarting it ...just a thought

I only have one die with these flaky soft resets, so it may not be a huge overall problem

Trying to keep this as automated as possible and least user invasive as possible =), its hard for me to code custom stuff for webgui since I dont have much experience w/ all the crazy shit they have going on involving it. LOL

GenTarkin's MOD Kncminer Titan custom firmware! v1.0.4! <--- CLICK HERE
Donations: bitcoin- 1Px71mWNQNKW19xuARqrmnbcem1dXqJ3At || litecoin- LYXrLis3ik6TRn8tdvzAyJ264DRvwYVeEw
TXSteve
Sr. Member
****
Offline Offline

Activity: 340


View Profile
August 13, 2015, 12:54:01 AM
 #40899

TXSteve, so the way these things work is every loop of the monitoring script it scans how much current is going through the DCDC's and if under 5 amps is going through it basically incriments the value /var/run/dieXX
once /var/run/dieXX reaches over the threshold variable it takes action to reset the die. So...basically if the ASICs dont have work due to a shitty pool configuration like when renting... that /var/run/dieXX will get incrimented, if the pool is shitty enough and it increments over threshold ... no matter what... one of the reset actions will be taken.
Im not exactly sure whats a good way to recode this so it can differentiate between possible pool comm issues vs an actual die needing reset.
I could impliment maybe 2 thresholds, one being a lower one for the pool issues then another maybe being double of the first one?Huh and if thats reached then it performs a hard reset.
I dont know, what do you think?
Or anyone else care to chime in?
Im just kinda doing a ton of trial and error here LOL!


How this all was originally(the way KNC set it up) was on threshold and if that threshold was hit it just performed a soft reset for an eternity.



In the short term, I was thinking, pool issues aside. Now since we have this other stupid mode of failure where the waas command succeeds but it really doesnt bring the die back to life .... I could do another loop which would attempt soft resets up to say 5x sleep after each attempt, run the dcdc function to see if current is over 5A and each incriment its not, of course increase /var/run/dieXX ... then inside that same loop if /var/run/dieXX goes over the threhold then start a hard reset. I think that would solve the issue I ran into just today =)

how about this? An "auto on/auto off" button & a "manual reset" button. On problematic rigs we turn auto reset off, & use manual reset as needed. It still beats physically powering down the rig, and restarting it ...just a thought

I only have one die with these flaky soft resets, so it may not be a huge overall problem

Trying to keep this as automated as possible and least user invasive as possible =), its hard for me to code custom stuff for webgui since I dont have much experience w/ all the crazy shit they have going on involving it. LOL

this v.93 seems to be running pretty good, even the flaky soft reset die seems to have stabilized after several hard resets

when bfgminer randomly shuts down I attribute that to hard resets

GenTarkin
Legendary
*
Offline Offline

Activity: 2170


View Profile
August 13, 2015, 01:01:48 AM
 #40900

TXSteve, so the way these things work is every loop of the monitoring script it scans how much current is going through the DCDC's and if under 5 amps is going through it basically incriments the value /var/run/dieXX
once /var/run/dieXX reaches over the threshold variable it takes action to reset the die. So...basically if the ASICs dont have work due to a shitty pool configuration like when renting... that /var/run/dieXX will get incrimented, if the pool is shitty enough and it increments over threshold ... no matter what... one of the reset actions will be taken.
Im not exactly sure whats a good way to recode this so it can differentiate between possible pool comm issues vs an actual die needing reset.
I could impliment maybe 2 thresholds, one being a lower one for the pool issues then another maybe being double of the first one?Huh and if thats reached then it performs a hard reset.
I dont know, what do you think?
Or anyone else care to chime in?
Im just kinda doing a ton of trial and error here LOL!


How this all was originally(the way KNC set it up) was on threshold and if that threshold was hit it just performed a soft reset for an eternity.



In the short term, I was thinking, pool issues aside. Now since we have this other stupid mode of failure where the waas command succeeds but it really doesnt bring the die back to life .... I could do another loop which would attempt soft resets up to say 5x sleep after each attempt, run the dcdc function to see if current is over 5A and each incriment its not, of course increase /var/run/dieXX ... then inside that same loop if /var/run/dieXX goes over the threhold then start a hard reset. I think that would solve the issue I ran into just today =)

how about this? An "auto on/auto off" button & a "manual reset" button. On problematic rigs we turn auto reset off, & use manual reset as needed. It still beats physically powering down the rig, and restarting it ...just a thought

I only have one die with these flaky soft resets, so it may not be a huge overall problem

Trying to keep this as automated as possible and least user invasive as possible =), its hard for me to code custom stuff for webgui since I dont have much experience w/ all the crazy shit they have going on involving it. LOL

this v.93 seems to be running pretty good, even the flaky soft reset die seems to have stabilized after several hard resets

when bfgminer randomly shuts down I attribute that to hard resets



Yeahp, bfgminer cant be running in order for a proper dcdc power down / up ... dont know if it has to do w/ bus traffic or what, but seems the dcdc power down / up does something but bfgminer will continually ignore them.

GenTarkin's MOD Kncminer Titan custom firmware! v1.0.4! <--- CLICK HERE
Donations: bitcoin- 1Px71mWNQNKW19xuARqrmnbcem1dXqJ3At || litecoin- LYXrLis3ik6TRn8tdvzAyJ264DRvwYVeEw
Pages: « 1 ... 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030 2031 2032 2033 2034 2035 2036 2037 2038 2039 2040 2041 2042 2043 2044 [2045] 2046 2047 2048 2049 2050 2051 2052 2053 2054 2055 2056 2057 2058 2059 2060 2061 2062 2063 2064 2065 2066 2067 2068 2069 2070 2071 2072 2073 2074 2075 2076 2077 2078 2079 2080 2081 2082 2083 2084 2085 2086 2087 2088 2089 2090 2091 2092 2093 2094 2095 ... 2138 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!