|
My gosh thats fucking sad =/
|
|
|
|
|
Whats going on w/ leaserig, seems down for me.... anyone else?!
|
|
|
|
Don't count your ROI in terms of fiat. BTC in vs. BTC out. The only relevance fiat has is if the unit is priced in $ and you need the conversion rate to evaluate the BTC in metric.
Spot on! ... should note that fiat also comes into play w/ power consumption. But, I consider power consumption my investment into Bitcoin, all that matters is can I turn BTC into more BTC ... mining. |
|
|
|
|
So, quick update again in my journey of discoving how this core shedding works:
noshed enabled: 8 cores(per hab) get disabled on start of mining.
noshed disabled: ALL cores enabled on start of mining, over 24hr period, one of my habs incremented "shed count" to 2
Theoretically, if ur cores arent complete shit, you will benefit from running w/o noshed!
It seems to be very common(as in Ive had several people report this to me) that using noshed...causes 8 cores to get disabled right from the start, per GN!!! why?! no fucking clue, but they work fine!
|
|
|
|
|
keep in mind, all current hardware will be dwarfed when AM brings its 1.4EH online =./
Thats if, they are able to still pull that off.... maybe they were just blowing shit out their ass, but yeah... something to ponder.
|
|
|
|
What are people thinking for the cheapest power supply having 4 PCIe with enough juice for overclocking?
DIY dell / hp 12-15$ server PSU's |
|
|
|
I love how bitmain is so transparent about how they fuck over the mining community, which is the practice amongst all ASIC manufactures ... but bitmain uses it as marketing =) quite clever.
-----
OK.. how exactly his he doing this? buy offering instock miners? that work? No, note I said every asic manufacture does it. Look at the pricing slope. These things cost a few hundred, if that. Yet they charge an astronomical amount more to ensure miners make only a tiny fraction of profit. Bitmain is smart though, they use that very fact as a marketing point to be like "look how our price curve allows miner to roi!!!" ... =P Which, I know is inevitable, but just goes to show how desperate the mining community continually desires to be "lead to the slaughter" and give power to these evil companies. |
|
|
|
|
I love how bitmain is so transparent about how they fuck over the mining community, which is the practice amongst all ASIC manufactures ... but bitmain uses it as marketing =) quite clever.
-----
|
|
|
|
|
To my current renter on my scrypt rig, yet again its having issues, of course when Im gonna be gone for 10+ hrs ... so, I will look into it later, will either extend lease by time / hashrate loss or refund u proportionally for the loss. Sorry for the inconvenience.
Thanks for understanding.
|
|
|
|
|
let hope these are priced how the S1's were, not the S2's ... S2's never fucking will roi and they were garbage. S1 otoh... a gem!
|
|
|
|
|
Get ready for another 25%+ diff increase =P
|
|
|
|
|
btw ... for me --hfa-noshed actually disables those 8 cores to begin with in cgminer
Leaving out --hfa-noshed ... activates all 768 cores from start...
I wonder, will the inflight value in the api ... change to reflect if a core gets disabled via firmware ... as its mining?
|
|
|
|
|
"don't order anything from them!!!"
That should have been a lesson learned for anyone thats preordered from them before...
|
|
|
|
We're all your runs long enough to let things settle? ~30mins
I remember flipping out very time if have to restart bfgminer on my bitfury rigs it'd occasionally show stupid high error rates for about 4-5 minutes while things settled down to normal 0.5-1.5%
Sorry to bring different hardware into the tread. Just sharing experience
Yep, Ive let it settled for sure. |
|
|
|
Welp, after doing some even further digging, Ive confirmed there are 8 cores being disabled upon startup by bfgminer. The resultant hashrate loss is nearly identical to what Im seeing in cgminer.
Some further things noticed & tested:
1. Ive confirmed that at least 1 of those disabled cores is able to do good work, by enabling it in bfgminer & watching it have a share accepted.
2. I couldnt believe it at first, thought I was going crazy, but the 8 cores that are being identical are 4 per hab, the id of the cores being EXACT between the 2 habs... WTF?!
0dr,0hj,0lb,0ot & 1dr,1hj,1lb,1ot - as seen in bfgminer
3. I went and hit the reset button on the board and noticed bfgminer re-detect the boards, each time a different core count was detected, ranging from min of 760 to a max of 766!(only 2 disabled)
4. I manually turned on those disabled cores in bfgminer, seeing my hashrate climb to what it should be, at least measured locally.
5. The state in which those 8 cores are upon bfgminer start is "RST"
Any ideas as to what could be going on?! =/
This is confusing the hell outta me....
are you running cgminer with --hfa-noshed ? HF chips can report to have babbling cores that just seem to do random stuff at times, its not clear and we where told it was fixed in .5 of the firmware but well take it with a grain of salt with that statement. Yeah, seems to have no effect =/ ... Whats odd is w/ noshed, the inflight count was 760, w/o noshed, at least this time, the inflight shows 768 =P ROFL! ... complete opposite of what it should be like, but I may verify those results. If only bfgminer supported setting fan speeds, Id be using it instead of cgminer for the habs, seems to have much more accurate hashrate readout & consistency ... not to mention poolside hashrate measurement is always nice to see, which cgminer doesnt show at all. Also, I dont know which miner to believe, because bfgminer shows upwards of 4% HW error on one of the habs, cuz its clocked a bit too high, whereas cgminer shows only 1.2% ... so which to believe, not sure, but the loss in hashrate would be consistent w/ the 4% HW ... but dropping clocks, even tho lowers HW%, doesnt affect the drop in hashrate. Its just allout confusing ... LOL |
|
|
|
|
Welp, after doing some even further digging, Ive confirmed there are 8 cores being disabled upon startup by bfgminer. The resultant hashrate loss is nearly identical to what Im seeing in cgminer.
Some further things noticed & tested:
1. Ive confirmed that at least 1 of those disabled cores is able to do good work, by enabling it in bfgminer & watching it have a share accepted.
2. I couldnt believe it at first, thought I was going crazy, but the 8 cores that are being identical are 4 per hab, the id of the cores being EXACT between the 2 habs... WTF?!
0dr,0hj,0lb,0ot & 1dr,1hj,1lb,1ot - as seen in bfgminer
3. I went and hit the reset button on the board and noticed bfgminer re-detect the boards, each time a different core count was detected, ranging from min of 760 to a max of 766!(only 2 disabled)
4. I manually turned on those disabled cores in bfgminer, seeing my hashrate climb to what it should be, at least measured locally.
5. The state in which those 8 cores are upon bfgminer start is "RST"
Any ideas as to what could be going on?! =/
This is confusing the hell outta me....
|
|
|
|
|
Think I just figured it out and how can this be fixed....?
I ran bfgminer and immediately on startup it shows a total of 8 lines showing "disabled" .. like cores or something... it goes by to fast to see exactly what its saying.
Ugh... why would it be disabling shit? =/
|
|
|
|
|
Quick update, I looked at miner.php api output and it just shows inflight_target at 760
Also shows "sequence modules" at 2048, if that means anything to figuring this all out =/
|
|
|
|
Yeah, this sucks, I guess they are damaged now somehow, no idea, Ive upped the voltage plenty on the 875mhz one and, temps are till under 100C but hashrate are still stuck at 645-650GH
Even tried next mv setting up for the one at 850mhz and it has no effect, just runs hotter ... ugh, its hashrate still at 630-635GH
So, somewhere Im losing 3% on each one =*(
What do the 3 buttons do? more specifically the reconfig one, does that restore firmware defaults or allow firmware installation?
Also, like in my original post, any way to see the status of each 96 cores?
Thanks
Sorry to hear about your issues, as far as a status of each core cgminer does not provide this information, BFGMiner does but I haven't had the time or energy to work on porting the Pepper App to use BFG, and while BFG is a great miner its missing some of the functionality currently that you can do with cgminer for HF/HAB products. One thing is to check your inflight value per board, now this isnt displayed in the pepper app, I could prob make a build with a debug option at the bottom of each page, this should be around 760ish.. if you have damaged a die this value gets lower. Mr Teal could maybe elaborate a bit on this if he has time. Also while these things can be fun to play with and tweak to maximum performance their are times where damage *could* happen. I have busted a few boards just doing this and killed off a die so just be careful with them. I think I saw the inflight field in my miner.php, will look for that. I would like an explanation about this value and how to make heads or tails about the condition of the cores. Also, I cant fathom how I would damage a board, Ive barely gone over stock (highest Ive put in hf-tool is 950mv and one one hab Ive not gone over stock period) in voltages and the dies have never seen over 104C - cgminer immediately drops them off. Most of the times my temps are under 100C I will look into bfgminer ... see if it can give me more info =) |
|
|
|
So, is it possible to see the status of the 96 cores per die?
Reason I ask is, when I got these, before I tweaked voltages / cooler mounting etc... I remember the MHav over a 10hr period was right around 650GH per hab @ 850mhz
Which, 850 * 96 * 2 * 4 = 652GH ... add the HW% and the 650GH sounds about right.
After tweaking the waterblock heads, voltages and messing w/ clocks ... I have the cooler hab running at 875mhz, 1mv higher than stock, it shows no dropouts(due to not enough voltage) in the pepper app .. after a few hours of mining, its only showing 645GHav ... it should be closer to 660-670 .. HW% is largely unchanged.
So, Im confused as hell, if I put it back to 850mhz, its right around 630GHav now =(
My other hab, Im not able to get it stable at 875mhz, so its at 850mhz ... its showing the same drop, down to 630GH now =/
So, Im wondering, is it possible for individual cores or an engine in a core just die / not work and go unnoticed? Hence why Im wondering if its possible to see the status?
I have no idea whats causing this random drop.
My temperatures are all well within range too.... help!
I have noticed this sometimes happens as well. It's a peculiarity of the chip, and a little more voltage usually cures it. Remember there are two kinds of hardware errors, one is where a share is submitted that shouldn't be; cgminer will see this and flag it as a HW error. The other is a dark HW error, where a specific bit of work should give a valid share but doesn't. This one won't get reported as a HW error, since cgminer doesn't know it's happened. There seems to be a small zone between where work stops noticeable enough to affect temperatures that you can see in the PepperApp, and normal operation where (probably) valid nonces don't get reported. As a general rule, we shipped the boards with the voltage set high enough to get the 650GH/s we advertised, and most will hit 875MHz at that voltage as well. It's a compromise between power consumption and overclocking ability. If your temperatures are still good, I'd try giving it another 10mV and see if the hashrate moves to what you expect. Yeah, this sucks, I guess they are damaged now somehow, no idea, Ive upped the voltage plenty on the 875mhz one and, temps are till under 100C but hashrate are still stuck at 645-650GH Even tried next mv setting up for the one at 850mhz and it has no effect, just runs hotter ... ugh, its hashrate still at 630-635GH So, somewhere Im losing 3% on each one =*( What do the 3 buttons do? more specifically the reconfig one, does that restore firmware defaults or allow firmware installation? Also, like in my original post, any way to see the status of each 96 cores? Thanks |
|
|
|
|
Show Posts
