If you tell me exactly what you need, I can get it in about 2 weeks. Running on a VPS is not a problem, assuming Blockchain.com hasn't changed scraping restrictions.
The problem now is that some members want to know the time difference between empty blocks and the block that came before them, to analyze this kind of data Blockchain.com is not enough as it doesn't show the full timestamp, it's missing the last two digits the represent the seconds, the only explorer I am aware of which provides the full timestamp is https://blockstream.info. for this study, I will need the following columns. Height TimeStamp Transactions (only the number) If possible (depends on how you scrape the data, you could exclude all blocks that are not followed by a block which has 1 transaction (empty block), this will reduce the data by a tremendous amount, if you can't filter the results, it's okay, I can do it. Now in regards to a similar study in the OP but with longer data, all I need is Miner Timestamp Transactions ( number of transactions) You still can't use blockchain.com because it doesn't show the timestamp, so really blockchain.com is no use, and you will need to use blockchair for that, here is a permalink of what I need https://blockchair.com/bitcoin/blocks?q=transaction_count(1)#f=time,guessed_miner,transaction_countI think these following indicators are enough (choose them from the General section):
Height
Mined on
Miner
Generation (BTC)
Reward (BTC)
Three of those are not needed for the study, please refer to my explanation above I tried but it only narrows down time window and only 10 lines of result are displayed.
Exactly, that's the problem, Imagine how time-consuming that was when I had to do that manually for 5 years of empty blocks  , but I can only think that there is a way to automate this. |
|
|
|
[...]
I am happier to know you fixed your miner than knowing I was right , all credit goes to zeusbtc for taking the time to write the article, the owner of that company is very helpful and very friendly and never hesitates to help, so really I shouldn't take any credit for his work. I reflashed the firmware on the new problem unit, and it has been running all 3 boards properly for 2 hours 28 minutes and counting. Fingers crossed 🤞
Good to know you got yours fixed too, hope it stays this way.
So now as far as the temp sensor issue is concerned here are my recommendations to fix it. 1- Flash the recovery firmware using a Sdcard, and then flash the latest firmware. 2-If 1 fails, your next suspect is the PSU, check the screws, tighten them well, clean any dust and try. 3-If 2 fails, try a different PSU because there is a possibility the PSU is bad and cleaning it won't do any good. 4-if all the above fails, then it's safe to assume that one of the chips on the hashboard is bad, it's usually the first chip, refer to this image to identify the chip, sometimes the heatsink is a bit loose and by pressing it down ( applying some pressure using your fingers) could fix the problem, if not then you will need to remove it and glue it back. |
|
|
|
|
اولا شكرا على المجهود الجبار, الا انه يوجد شي اساسي مفقود في الموضوع الذي قمت حضرتك بالاستعانة به, اعتقد ان القاري الذي لم يقرا عن توقيع شنور في السابق سيعتقد ان ميزة هده التواقيع هي فقط منحصرة في عناوين ال Multisig او على الاقل هدا مايظهر سواء في الشرح او الصور بينما الواقع هوا ان الهدف الاساسي والميزة الاكبر هي جمع التوقيعات عند محاولة الارسال من اكثر من عنوان لعنوان واحد.
مثلا: نحن نعلم ان محفظة البتكوين تعطينا عنواين عديدة صح؟ قد نستعمل كل عنوان لغرض معين, ينتهي بك المطاف الى امثلاك مثلا ماقيمته 100$ بتكوين موزعة في 5 عنواين (استقبلتها على 5 عنواين في نفس المحفظة) ولكن كلها تظهر لك في المحفظة نفسها, الان تريد شراء شي ما وتريد تحويل المبلغ كامل مثلا,يعني انك ستقوم بالتحويل من 5 عنواين , تذكر ان البلوك تشين لا يعرف ان صاحب المحفظة شخص واحد فهو يعامل كل عنوان على ان له مالك خاص وتوقيع خاص, مما يعني انك عندما ترسل ستقوم المحفظة بتوقيع 5 عنواين مختلفة والارسال 5 مرات, مما يترتب تكاليف عالية, باستخدام شنور ستتمكن من "دمج" تلك التواقيع وتخفيض الحمل على الشبكة والتكلفة في الارسال.
اتمنى ان اكون اوضحت النقطة بشكل كافي, ان كان هناك اي اشكالية تفضل بالسؤال, شكرا مجددا على مجهوداتك اخي هيوج.
|
|
|
|
that number makes no sense at all.
Well, you can complain to "Antonopoulos" who mentioned the 2000%, or you can prove him wrong, or I can save you the trouble and explain to you why he is right. Here is the calculation from whattomine.com for a single miner that does 10th and consumes 1000w ( pretty much similar efficiency to the most famous miner Antminer S9 taking the average rate of 6 cents per Kwh the miner earns exactly $ 0.02. Now running the miner with Asicboost which can achieve up to 30% decrease in power consumption, the miner now uses only 700 wats and makes 0.46$ a day that's a 23 times more profit aka 2200% more profit, and by the way, I am not even trying to tweak any numbers to get to these results, i am using the average gear with the average power rate, results can be a lot better for many other miners. in any case let me ask you this, since you claim the reason for empty blocks is ASIC boost how do you explain lack of it nowadays? 2000% increased profit seems to be an excellent incentive to always use ASIC boost and mine empty blocks.
Bitmain still uses Asicboost, I personally use Asicboost, almost everyone and their grandmother uses ASICboost nowadays and get 20-30% saving on the power cost aka 2000% more profit, what you must understand is that there are TWO types of ASICboosts, the COVERT used previously by bitmain which bitmain then denied, that type of ASICboost has to do with empty blocks, the community opposed it because it's patented and it's not easy to detect and is not compatible with SegWit. The OVERT Asicboost is a whole different story, it's the one we use now, has no effect on empty blocks, easily detectable, etc. I hope that by now the confusion is gone. |
|
|
|
The B-D line will form the upper bound of the triangle, and Wave D hasn't completed yet. We could even see some short-lived shenanigans above the $10.5K pivot and still come down to build out Wave E.
Nice chart as usual. I draw the triangle a little differently, and I don't see us going to 10.5k, in fact, we got rejected by the downtrend at 9.5k, and the only way, for now, is a correction to the south, somewhere around 8.2k  Anyway, do you mind explaining what does your chart suggests anyway? edited: exstasie's explanation on the dragonfly candles is correct and sufficient. |
|
|
|
I have all my miners pointed at the 3333 address, what is the point of the 4334 and the 3335 ones?
4334 is for rental services, you showed a status of your miners working and hashrate is reported so 3333 works for you, ignore the rest. And i know its like a year or 2 odds with luck to find a block but if i find one how will I know?
2 years is not even close, based on your 1hr hashrate of 122 you are looking at 18 years to hit a block assuming your luck is 100%, you can use this website to estimate the odds > http://solochance.com/Also is there a way to look up random blocks in the chain and see how much hashing power was used to find it for the sake of curiosity?
Only the pool itself has this data, nobody else does, to everyone else, it's a single hash that could have come from the use of an old CPU, the pool has the data, I don't know if CK saves them and show them somewhere, but you shouldn't bother with it, i remember someone hitting a block mining with 2*S9s ( 24th or so) not too long ago, but those things mean NOTHING to your chances of finding a block, you are simply taking a long shot, just like trying to hunt a mosquito in the woods using a crossbow while being blindfolded at 3 am, in a nutshell, you need a ton of luck and that's all about it. |
|
|
|
as for ASIC boost, it is an optimization that could only makes sense financially. using this optimization to the algorithm with which a miner computes the block hash will only give a very small "boost" that small boost could only make sense if mempool was empty or had very low paying fees.
What do you mean by a small boost? using Asicboost yields up to 2000% more profit, even now with overt Asicboost mining gears run with 20% less power, giving the fact the profitability margin is too small a 20% savings on the power bill is a dozen time more profit, miners rather mine empty blocks using Asicboost than including your transactions even if you think you were paying high, overt Asicboost, however, does not have the tendency of generating empty blocks, so miners still use the boost and include your transactions, but the former is more important to them than the latter 99% of the time. As far as May 2017, I did point that Aside from Covert Asicboost, there is a good possibility that some mining pools were purposely refusing to include transactions in the blocks they mined, causing a delay in transactions confirmation probably to give the impression of bitcoin "block is too small and we must increase it", this perfectly coincides with the spam attacks on the blockchain which happened in 2017, to be more accurate, May 2017 as shown in the chart below.
p.s. why does all your charts say number of "blocks" instead of "empty blocks"? Sorry, I forget to add the word "empty", figured that out later but then I thought that shouldn't be so confusing given the blocks number is too small and the obvious topic title and content which focuses on empty blocks, thanks for pointing that out anyway. |
|
|
|
2020-05-03 01:52:08 temperature.c:450:temp_statistics_show: pcb temp 42~56 chip temp 65~80
2020-05-03 02:22:09 thread.c:204:calc_hashrate_avg: avg rate is 27625.39 in 30 mins
2020-05-03 02:22:09 temperature.c:450:temp_statistics_show: pcb temp 42~56 chip temp 64~79 Your temps are pretty high, chain 2 does show less ASICs than it should but that's not your only issue, your temps are pretty high forcing the miner to lower the voltage/frequency which may cause it to be unstable and then reboot/stop mining. When you remove the third board (Chain 2) the other two boards will cool down and there is a good chance they will mine on without an issue and you will think that chain 2 was the only problem when actually you have a heat problem. I suggest you set the fans at 100% and see if the miner works more stable with these settings if you don't know how to set a fixed speed for those fans let me know I'll show you. |
|
|
|
That probability explains the seconds difference in the timestamp but those "few seconds block" that are empty can't be a coincidence.
Because if it's just luckily mined, then it shouldn't be empty unless it's purposely made empty.
Nop, the probability explains exactly the chances of actually finding a block the very next second, it has nothing to do with the timestamp, in other words, if you were mining your own blockchain with 0 verifications needed, the chances of hitting a block in that very next second is always 0.166% (provided the mean time is 600 seconds), empty blocks are found in a very short time anywhere from => 1 second and < the time needed to validate with the previous block. We could also be talking about different things here, but the use of the word "purposely" creates confusion, miners want nothing more than extra profit, they have every interest in the world to NOT mine empty blocks WHEN they can fill them with transactions, but they have no problem with mining empty blocks when they happen to find one BEFORE being able to download the previous block, validate the transactions, clear the memepool, reconstruct the block and then propagate it, so this is not really "purposely" mining empty blocks, because "purposely" means they "CAN SAFELY" include transactions but they chose not to, which is not the case at all because nobody is mining empty blocks for the sake of it. |
|
|
|
Great analysis. Could you factor in the timestamp/the timing received by blockchair into the graph? It would be a lot clearer to see the timings between the empty blocks and the block before it.
I could but there are two problems, the first one is scraping the data of blockchain,took me forever to extract the data for empty blocks which is nothing compared to the total number of blocks, but if someone has a better way of getting those data, put them in a table format like excel and send them to me, I can do it and even more perhaps. The second problem is that time-stamping isn't exactly accurate, they are accurate enough to be used to adjust the difficulty, but not accurate enough in a sense that we can use them to reach to any conclusions, maybe if we find empty blocks coming after a long enough time (enough to actually validate the transactions of the previous block) and still come in empty, we would confirm that a certain pool did actually have enough time but did not include transactions on purpose, however, since the time-stamp is actually put in the header of the block by whoever mines it, they can manipulate it, say I find a block 60 seconds after the last block was propagated (nobody knows about it yet), I need 30 seconds to validate the previous transactions and reconstruct the pool, but I decide not to include any transactions, I can conveniently lie and say I found the block in 10 seconds, who is going to stop me from doing so? JUST a fast check of three shows a big difference in time 6 to 32 seconds.
I don't think anyone knows exactly how long it takes a mining pool to fully download and validate the previous block, but I am pretty sure it's less than 32 seconds, of course, more complex blocks take slightly longer, but 32 seconds can't be it, why do I think so? Applying cumulative distribution function, the probability of blocks being found between 1 and 32 seconds can be derived by: exp(−1/600)−exp(−32/600) = 5.36% of blocks would be empty, in other would we would "in general" have an empty block every 18.6 blocks, that's nearly 8 blocks a day which would result in 2920 blocks per year, which never happened even when was well-intended. so really 32 seconds is more than enough to validate the previous block, deal with the memepool and reconstruct the next block WITH transactions in it, but where did the 32 seconds come from? 1- That node's memepool was empty. > very unlikely. 2- The time reported is actually "wrong" > Very likely. I would still do the analysis, but really the results will be meaningless
people scream empty blocks are pools being bad actors
is it simply the pools are really big?
The fact that the time to mine those blocks is within seconds and the number of transaction is '1' ( Coinbase TX) tell that those are probably mined with 'Covert ASICBoost'. Because not including any transaction is the easiest way to generate a Merkle Root Hash ( hashMerkleRoot) with fixed last 4 bytes. But there's no evidence so I'll leave it with " probably"  I don't think anybody uses Covert Asicboost anymore, finding blocks in the next second at any given time always has a probability of 0.166%, if everyone was mining with a pen and paper, people would probably still mine empty blocks. To explain even further, for the past 4 months of 2020 we had exactly 14 empty blocks every month, that's a bit less than 0.5 blocks a day, this is below normal as far as statistics and probability are concerned, applying the above formula and assuming for the sake of it that 5 seconds is more than enough to validate the transactions it is still OKAY to mine an empty block once every day, I think the number of empty blocks for the past 2 years is pretty normal. |
|
|
|
Just today there was a fee free block.
Let me pull it up.
628428 came in 1 second after 628427
True block 628428 was empty and was mined by Antpool, there is a more recent empty block 628603, the block you mentioned was found yesterday unless of course, you are in the U.S or somewhere very west then it's "today". Below is a list of empty blocks for the past few days 628603 2020-05-02 18:22 1THash&58COIN 628428 2020-05-01 15:15 AntPool 628336 2020-04-30 22:30 BTC.com 628017 2020-04-28 15:34 BTC.com 627867 2020-04-27 14:53 F2Pool https://blockchair.com/
it's pretty normal to find 1 empty block every day. |
|
|
|
By "Wifi Adapter that was for Desktops" I assume you mean the little once that you plug into one of your desktop's USB ports? how do you plan on using that for a miner that doesn't have a USB port? and even if you somehow managed to connect it, you will still need to deal with the drivers, unless you know so much about these things, I don't think you will be able to do it. The closest alternative solution would be using Ethernet-to-Wi-Fi Adapter which functions like this:  source is amazon IOGEAR Ethernet-2-WiFi Universal Wireless Adapter. In a nutshell this device gives a non-wifi device the wifi-capabilities, pretty much the same as the regular Wifi adapter on your desktop, but this one is Ethernet to Wifi as opposed to USB to wifi, there are many other brands so pick whichever you want, keep in mind that you will still need to use a network cable cat5/cat6, the wire can be pretty short it doesn't matter, if you can't pick the signal, you can extend the cable length, once done make sure you test the quality of the link by pining the miner's IP from a PC connected to the main router using the following command Allow the ping operation to work for 5-10 minutes and then hit ctrl+c to stop it and get a report of the packet loss, rout-trip time, and all of that, alternatively you can use the miner's network tools to ping the pool directly from the miner, the only issue with that is that the miner is set up to perform a default ping of 3 packets which might not give you a very accurate result. |
|
|
|
I was trying to find a recent analysis of empty blocks and I couldn't find any, It seems like most of the analysis is outdated, so I decided to make one using blockchair explorer with some filters. The analysis is based on 5 years, starting from the first day of 2015 ending on the last day of 2019, I have purposely ignored 2020 since we don't have enough data for it. I started by analyzing the monthly empty blocks.  Chart 1: Numbers of blocks found per month (total of 60 months)Added a more detailed chart showing the total of empty blocks per year.  Chart 2: Numbers of blocks found per year 2015-2019The following figure is similar to figure 2 but in a pie chart, showing the exact number of blocks found per year  Chart 3: Number of blocks found per year between 2015-2019Now comes the interesting part, below is a chart of total empty blocks per mining pool.  Chart 4: Number of blocks per mining pool 2015-2019A different representation of the same chart  Chart 5: Number of blocks per mining pool 2015-2019Since we have a total of 26 mining pools, and most of them have a very small number of empty blocks, I have excluded 16 of them and kept only the top 10 mining pools, showing the number of empty blocks they found and the percentage (share)  Chart 6: Number of blocks and total share (%) per mining pool 2015-2019 for top 10 mining pools To get a better idea in regards to mining pools: time ratio, the chart below shows the number of blocks per year for each mining pool.  Chart 7: Number of blocks a per mining pool per the year 2015-2019 Excluding 16 mining pools and keeping only the top 10 we get a clearer chart.  Chart 8: Number of blocks a per mining pool per the year 2015-2019 top 10 mining pools.
My interpretation:
1- The unusual numbers of empty block found during certain periods based on chart 1 does show some evidence that "someone" did use Covert Asicboost, and based on the fact that Bitmain pools (Antpool+BTC.com) found nearly 55% of those empty blocks, I don't believe that bitmain only tried Covert Asicboost on Testnet. 2- Aside from Covert Asicboost, there is a good possibility that some mining pools were purposely refusing to include transactions in the blocks they mined, causing a delay in transactions confirmation probably to give the impression of bitcoin "block is too small and we must increase it", this perfectly coincides with the spam attacks on the blockchain which happened in 2017, to be more accurate, May 2017 as shown in the chart below.  Comparing this chart against chart number 1, you can clearly see that May 2017 had a huge spike in empty blocks, it had exactly 75 empty blocks which is twice as high compared to the average number of empty blocks around that period, the majority of those empty blocks were obviously mined by Antpool and BTC.com (Bitmain), while the transactions went from 10-50k to just a bit over 150k during that month, someone was really trying to "prove" something, it's most likely Bitmain wanting larger blocks. 3- The number of empty blocks is decreasing, and since there is no more obvious drama coming from Bitmain and the big-blockers, taking 2019 numbers which had a total of 314 empty blocks or 0.86 blocks every day or a block every 1.16 days, the numbers in 2020 look even better, so it seems like the mining infrastructure is improving in terms of routing protocols, block propagation time, the confirmation of the transactions in the last block, speed of constructing blocks, etc. 4- Judging based on the point above, it seems like the time needed to validate block transactions for miners is well below 10 seconds.
I would love to hear your interpretations/thoughts regarding the data shown in this topic. Mikey.
I could do a 10 years analysis instead of just 5, the only issue is scraping the data from blockchair.com, it took me very long to get 5 years worth of data, however, if someone (maybe LoyceV or DdmrDdmr) can help me scrape the data I'll be willing to make a 10 years analysis. |
|
|
|
... I don't have much knowledge of electronics and unfortunately I must trust what they tell me  Since they are authorized by zeusbtc then I would still trust them, what the main branch says does not really contradict with what the branch in your country told you, it only weakens the probability of the latter, also I must make clear that it's not just because I tend to trust the main branch more - I base my points on that alone, it's more like common sense, what the Chinese branch said has much higher probability of happening. ... but is it also possible that if one fails it will send incorrect information to the other 3?
Indeed, you are right, it's very possible, however, it's unlikely, the way the board is designed should not let a single sensor stop the other 3, the proof is we are aware of some hash boards that work with less than 4 sensors, which means the probability of a single sensor stopping all others is kind of low. In my case the 4 sensors of the 3 hashboards are failing, so I read this failure is related to the PSU?
Yup, your problem is power related, I am 99% sure it is, and let me explain why: Reason 1: You now have a total of 12 (3*4) broken sensors, does that make sense? NO Reason 2: You have at least 1 bad chip/heat sink on all 3 boards, how possible is this scnerio? i would give it 1% at best, provided they all failed at the same time. Reason 3: Something that has an effect on every aspect of the miner, we have two things, the control board and PSU, from the various reports and personal experience I doubt the control board will cause such an issue, so what is left? the power supply. I would still suggest that you flash the recovery file using an SDcard, and then flash another firmware, see if that helps, Something that also disconcerts me is that my T17 in the cooler hours of the day works normally. Which is why I thought it made sense that the temperature sensor.  This actually adds more strength to the power supply being the issue, the sensors are designed to work at temps between -40c to 125c, it doesn't make sense that 10 or 15 degrees change in the ambient temp will make them work or not work, however, a 10 degrees change makes a world of difference to the PSU and the chips, I am suspecting that your PSU is overheating at noontime and fails to deliver the DC voltage needed by the boards, also during peak hours the voltage at your house/farm might actually drop to below 200v and thus causes the miner to not hash, make sure you measure that too. If you have a spare PSU, I suggest you try it, or at least measure the DC voltage coming into the boards from the PSU you say you solved the problem by pressing on chip 1
Did your t17 fail on just one sensor or all of them like mine?
4 sensors 1 board, the other two boards were fine and reading all sensors, so it's a bit of a different issue from yours. This could actually be true. My 2nd T17+ got broken a minute after i tried to overclock it. Worked fine for 2 months before that. So please do not go over 800 Mhz on default cooling.
overclocking has more effect on the chips than on the temp sensor IMO, so it's more likely that some of the chips got toasted, you can test them with a multimeter by the way. try lowering the frequency.
That's an excellent idea, even when the PSU is having some issues, going with a lower frequency might fix it. |
|
|
|
The high price was because of shitcoin btcv. People were mining this coin, paying high prices and still making a profit. Everyone was dumping this coin on coineal and liquid exchange.
That's interesting, but look at the price of that shitcoin it seems like it hasn't gained much value during that period, nicehash payouts were crazy high around 18th to 20th of last April, it only went up about 25% from its price week prior to 18th, but even assuming for the sake of it that it did do a 100% jump, this doesn't really give miners the ability to pay 8 times higher the profit they would get mining bitcoin then.  I am not ruling out the rule this coin could have played in that period, I just don't think it's the primary cause, because, if its price had gone up 10 or 20 times, that would make sense but it has not, and based on that I still believe it was someone laundering his money as fast as they could. It's also worth mentioning that the volume of btcv was just about average during that period, it does not indicate any unusual selling/buying, I would like to hear more on how you arrived at that conclusion just in case there is something I missed. Btcv dev didn’t like this and made changes so only certain address could mine lol.
lol, so he just had to change the code and that's it? no hard fork nothing happened? probably just his node and the mining pool's node maintain this coin anyway. |
|
|
|
في الواقع السيرفر يمكنه ان يعرف فقط العناوين التي ترسلها له و ليس كل العناوين التي يمكن ان تنتجها المحفظة.
اخ خالد اعتقد ان الاخ اوميقا يقصد العنوان المكونة حتى التي لم يتم استعمالها وليس العنواين التي "يمكن" تكوينه او انشائها في المستقبل, طبعا لان ذلك يحتاج ل seed الخاص بك, ,ولان تقريبا كل HD wallet تقوم ب generate لعنوان جديد بمجرد الارسال من العنوان الذي سبقه, سيكون هناك دائما عنوان معروف ولم يتم استعماله. موضوع رائع مشكور على الجهد |
|
|
|
I got my extra coin from them yesterday they paid me in full.
Are you saying this to comfort yourself?  , sorry to spoil the moment, nicehash did not pay you, it was that dude over-paying for your hashrate, he paid you handsomely, nicehash escrowed the deal and TOOK their fees from you, Nicehack still owes you 18%, I hope they will repay it soon, the nicehash community should demand it, because if not they might just discard the repayment program altogether. |
|
|
|
لقد قام الموقع باضافة ال KYC... يعني أنه بمجرد وصول مجموع قيمة مشترياتك الى 15,000 أورو، سوف يتوجب عليك اثبات هويتك. لقد قمت بتحديث الموضوع واضافة تعليقك هدا فيه شكرا لك على التنبيه, على العموم اعتقد انهم يمسكون العصا من الوسط, لم يضيعو زبائنهم ولم يزعلو الحكومة, الحد الاقصى للمعاملات كبير جدا 10,000 يورو يوميا و 15,000 لكل حساب, سيقوم المستخدمين بانشاء حسابات جديدة ومتابعة الشراء, لا ادري ان كان الوضع سيستمر هكدا او سيقومو بفرض KYC قبل حتى محاولة الشراء, نتمنى ان يبقا الوضع كما هوا عليه. |
|
|
|
|
@fillippone, you brought up a very interesting point, one of the main reasons why miners would mine empty blocks is what you mentioned about the "transactions of the last/previous block", validating the transactions of the previous block can take some time probably 10-20 seconds, large blocks may take over 20 seconds to validate, miners pay a ton of money during those 20 seconds, and if they happen to solve the puzzle before they were done with validating the transactions they would broadcast an empty block to avoid invalidation, however, since every hash is independent from every other hash, they lose nothing by including transactions ONCE they have verified them, but if they happen to solve the block BEFORE that, i don't see why would anyone refer to them as selfish miners, of course ignoring spy mining I see no economical benefit of purposely mining an empty block.
I don't think empty blocks are exactly bad, and assuming the average validation time is 15 seconds, it's safe to assume that empty blocks have a probability of 1-exp(-1/600) - 1-exp(-15/600) = 2.3% or every 43 blocks / 3 times a day, as long as we are not way above that, I think we are good.
|
|
|
|
Thanks for your input, I did contact zeusbtc's main branch china, and they told me quite a different story, not saying yours is wrong, but I think this one actually makes a lot more sense. To summarize that article, they simply imply that if all temp sensors of all hash boards can't report their temp then it's a PSU problem ( not a very common issue), if however less than 3 boards 'normally 1' hash board shows the temp sensor error, then the problem is one of the chips/heatsinks and not actually the temp sensors. The reason why I am 99% positive about the chip theory is due to the fact that the chances of FOUR sensors going down at once are very very very unlikely, those sensors don't produce much heat if any, they are located across different areas, I am not saying they will not fail, but highly unlikely for one of them to fail, let alone FOUR of them. To strengthen this point further, based on the article sent to me by zeusbtc, they suspect that the bad chip is usually the first chip, so we tested a T17 board which was giving us the 4 sensors error by putting some pressure on the heatsinks of the 1st chip pushing them down really hard, i learned this method from a video on youtube on fixing S9s boards where he pushes his finger against the heat sink to see if it reports voltage, just kind of making sure the chip is actually in contact the board and the heatsink is in contact with the chip, as naive as it may sound to you, the board DID work and all temps are being read perfectly. I, of course, don't expect this to last forever, it's a matter of time before the heatsink becomes loose again and we go back to square zero, but at least we are now pretty close to determining the exact problem of this common problem, and once I have physical access to that boards, I will remove that heat sink and put it back, but for now, all of this is done remotely with the help of a friend. Anyone who has the same problem, please try the remedy, also keep in mind that it may not always be the 1st chip, but if you have a multimeter that reads diode's resistance you can easily identify the bad chip by measuring the heatsink against RST as shown here. |
|
|
|
|
Show Posts
