 Show Posts
|
|
Pages: [1] 2 3 4 »
|
I'm getting lots of these errors frequently, it's always chip 1: Jul 31 09:31:15 InnoMiner sgminer[1313]: [ERRO:2018-07-31 09:31:15.547] ERROR - spi recv data invalid: 04|00
Jul 31 09:31:15 InnoMiner sgminer[1313]: chip 1 clear work failed
Jul 31 09:31:15 InnoMiner sgminer[1313]: [ERRO:2018-07-31 09:31:15.595] ERROR - spi recv data invalid: 04|00
Jul 31 09:31:15 InnoMiner sgminer[1313]: chip 1 clear work failed
Jul 31 09:31:15 InnoMiner sgminer[1313]: [ERRO:2018-07-31 09:31:15.644] ERROR - spi recv data invalid: 04|00
Jul 31 09:31:15 InnoMiner sgminer[1313]: chip 1 clear work failed Firmware is latest.Seems the firmware update didn't work altho it indicated success & rebooted. Version is still b29+_20180706_042116 I receive same ERROR, sent this to Innosilicon Support: Jul 31 16:20:58 InnoMiner sgminer[1717]: Got nonce for chain 0 / chip 1 / job_id 1 Jul 31 16:20:58 InnoMiner sgminer[1717]: Accepted 751fc454 Diff 0/95999 HLT 0 pool 0 Jul 31 16:21:00 InnoMiner sgminer[1717]: Stratum from pool 0 requested work restart Jul 31 16:21:00 InnoMiner sgminer[1717]: [ERRO:2018-07-31 16:21:00.945] ERROR - spi recv data invalid: 04|00 Jul 31 16:21:00 InnoMiner sgminer[1717]: chip 1 clear work failed Jul 31 16:21:00 InnoMiner sgminer[1717]: [ERRO:2018-07-31 16:21:00.974] ERROR - spi recv data invalid: 04|00 Jul 31 16:21:00 InnoMiner sgminer[1717]: chip 1 clear work failed Jul 31 16:21:01 InnoMiner sgminer[1717]: [ERRO:2018-07-31 16:21:01.031] ERROR - spi recv data invalid: 04|00 Jul 31 16:21:01 InnoMiner sgminer[1717]: chip 1 clear work failed support said Hashboard is bad, ship Hashboard back, no additional explanation? I see this pop up in my logs too...but my miner still hashes at advertised speeds. This could actually point to a SPI bus issue if Innosilicon said it was a bad hashboard. Anyone else see this in their logs? I've been hashing ZEC getting 48-55k/sols both sides so it's working correctly just intermittently receive ERROR in log? As much as I've been trying to fault the SPI as a possible problem on these unit. I've been ignoring this, since it always comes after a work restart request/New block found. Happens on my Good and Bad unit at the exact same time since they're in the same pool. But Maybe chip resetting relates to the slow units somehow. Im surprised Inno told the one guy to send it back when its hashing properly. Pretty sure that was a mistake. It could be a firmware error... |
|
|
|
Miners, I need help. I am going crazy.  Every single day 1 or 2 out of my 5 A9 miners goes offline and then I have to drive to the mining site to power it off and then turn it back on. Then it works fine. The worst is when this happens at night because then it's not mining for 8 hours until I wake up the next day. It's driving me bonkers because I never know when it will happen. Can anyone please help me and tell me why this keeps happening. It's completely random and not the same miner every time. It happens to all of them. Sometimes it's 1, other times it's 2 at the same time. Please help. Can anyone help with this? What do your miner logs say in the admin panel? No one can tell you whats going on without more information. |
|
|
|
I'm getting lots of these errors frequently, it's always chip 1: Jul 31 09:31:15 InnoMiner sgminer[1313]: [ERRO:2018-07-31 09:31:15.547] ERROR - spi recv data invalid: 04|00
Jul 31 09:31:15 InnoMiner sgminer[1313]: chip 1 clear work failed
Jul 31 09:31:15 InnoMiner sgminer[1313]: [ERRO:2018-07-31 09:31:15.595] ERROR - spi recv data invalid: 04|00
Jul 31 09:31:15 InnoMiner sgminer[1313]: chip 1 clear work failed
Jul 31 09:31:15 InnoMiner sgminer[1313]: [ERRO:2018-07-31 09:31:15.644] ERROR - spi recv data invalid: 04|00
Jul 31 09:31:15 InnoMiner sgminer[1313]: chip 1 clear work failed Firmware is latest.Seems the firmware update didn't work altho it indicated success & rebooted. Version is still b29+_20180706_042116 I receive same ERROR, sent this to Innosilicon Support: Jul 31 16:20:58 InnoMiner sgminer[1717]: Got nonce for chain 0 / chip 1 / job_id 1 Jul 31 16:20:58 InnoMiner sgminer[1717]: Accepted 751fc454 Diff 0/95999 HLT 0 pool 0 Jul 31 16:21:00 InnoMiner sgminer[1717]: Stratum from pool 0 requested work restart Jul 31 16:21:00 InnoMiner sgminer[1717]: [ERRO:2018-07-31 16:21:00.945] ERROR - spi recv data invalid: 04|00 Jul 31 16:21:00 InnoMiner sgminer[1717]: chip 1 clear work failed Jul 31 16:21:00 InnoMiner sgminer[1717]: [ERRO:2018-07-31 16:21:00.974] ERROR - spi recv data invalid: 04|00 Jul 31 16:21:00 InnoMiner sgminer[1717]: chip 1 clear work failed Jul 31 16:21:01 InnoMiner sgminer[1717]: [ERRO:2018-07-31 16:21:01.031] ERROR - spi recv data invalid: 04|00 Jul 31 16:21:01 InnoMiner sgminer[1717]: chip 1 clear work failed support said Hashboard is bad, ship Hashboard back, no additional explanation? I see this pop up in my logs too...but my miner still hashes at advertised speeds. This could actually point to a SPI bus issue if Innosilicon said it was a bad hashboard. Anyone else see this in their logs? |
|
|
|
HI All, 1. It might be a dumb question, but can someone give me a picture about the fault rate/reliability of the A9 compared to the Z9 for example? As I'm reading through the messages it seems that there are a lot of faulty units and the 50KSol/s is very far in many occassions. 2. I've heared rumors that they might be delays with the units that are advertised as ready to ship, is this for real? 3. Also it's still hard to believe, that this is their order page (it is not even a secure connection): http://www.innosilicon.com/html/a9-miner/index.html Can someone confirm it? Thanks a lot! I have had great experience with my A9. It hashes at around 51-52ksol/s depending on the pool Im connected to. Some pools work terribly with ASICs still and I think some of the people responding in this thread are using bad pools... Other people in here do seem to have legitimate issues with some of their cards, though Also, I purchased mine through a reseller so I cant help with your other questions...but yes I do believe that is the real innosilicon website as that is where I download my firmware from. |
|
|
|
Im using july 20th FW
regarding guy with bad hash unit. i dont know how much you can trust the reported voltage from the HW. its connected to an ADC which will have inaccuracies of its own. Best to measure VDD_CORE with a precise meter instead. I dont want to take my only unit apart, but for those people that do, I posted instructions on where to probe a few posts up. But, even if the ADC is innacurate, its good to see that whatever voltage it is measuring is very stable.
also, a few pages back, i went into why i dont think we will be able to overclock the A9's much more based on the information in the A9 chip datasheet.
if it were a spi issue, lowering the speed may or may not solve the problem because it could be a clocking issue (ie: setup and hold time for clock/data does not comply with spec (which is not listed in datasheet of course))....and it might also add more issues by itself
I Don't trust it, but like you said, its good to see its stable. I dont have a precise multi meter with me and it wouldnt give me enough information to make the teardown worthwhile. I need an good oscilloscope so I can see fluctuations and watch the spi data move down the chain. I'm not actually trying to overclock it. I'm trying to affect the HW error rate in anyway (under/overclocking and under/overvolting) to get a foot in the door on the nature of the problem. Same with SPI. I wanted to see if slowing it down affected HW error rate. Can you elaporate more on your POV regarding clocking issues? My Current understanding from the Datasheet and reading about other asics. These things need 3 things to function. 1. Good, stable levels. (VCore 0.9+/-10%, Spi/Reset 1.8V), 2. Clean Clock Source 3. functional SPI. Thats about it. Voltage levels and clock signal will be super easy to verify. Good Spi signals will be more tricky. Thats why im doing some testing. From what I gather, Spi commands are sent to chip1, passed from one chip to the other down to 12 and back up to the Controller. I honestly think SPI is working fine or there would be data reporting issues and SPI errors. Some chips are just returning no or bad results. But those same chips seem happy to pass SPI data along for good chips down the chain. Unless these arent setup in a SPI daisy chain. Pretty sure they are but it will be easy to verify when i teardown again. My guts telling me that some of these chips are just crap but we will see. It seems hashing rate is directly correlated to Vcore and PLL speed. There is a chart in the datasheet which shows 3 different level of voltages and PLL combos to hit a specific hashing rate. Vcore: I think the silicon would just have a spec for clean voltage ripple on Vcore. +/-10% is a HUGE margin on a vcore voltage spec. There is a chance the ADC is averaging samples which makes the voltage readout so clean, so yes, maybe you might want to get a cheapo scope to see what the voltage ripple looks like on Vcore. I want to say it wont be more than +/-20mV unless its a really badly designed board. I'm not sure how much high frequency noise affects Vcore vs PLL hashing power as long as the average voltage is stable and as long as you are not going over the VMAX limit (causing damage to the chip). I think a simple cheapo multimeter is actually perfectly fine to use for this exercise, but a scope would be nice to quantify voltage ripple. SPI: this is such a low speed bus the only thing you probably need to be concerned with is setup and hold timing. it looks like you are getting error readouts from every single chip in the miner, so I also agree with your statement that SPI is probably working fine...otherwise the system wouldnt be able to spit numbers back out at you. Clean clock: these chips have an internal PLL, and each chip's PLL will have slightly different clock speeds from the "ideal". If you are concerned with the signal that the PLL is taking to generate the clock, probe the CLOCK_L pin on the chip. I suspect its fine. Temperature: I havent found much of a correlation with temperature. Dropping my unit 20C from 70C to 50C didnt affect stability or hashing rate. Im also 99% sure the fan speed does not affect hashing power as the fan runs off of the 12V rail that is connected to the controller card, not the ASIC cards. If the increased current from faster fan speed was causing a voltage drop, it would be on the controller card which has no power connection to the ASICs. |
|
|
|
Hi,
Would like to report a crash/restart due to memory leak/ out of memory. This happens maybe once every few days so far, so its not too important, but may end up reducing my share for a certain block if it cuts out at a bad time.
What firmware version are you running? Im using july 20th FW regarding guy with bad hash unit. i dont know how much you can trust the reported voltage from the HW. its connected to an ADC which will have inaccuracies of its own. Best to measure VDD_CORE with a precise meter instead. I dont want to take my only unit apart, but for those people that do, I posted instructions on where to probe a few posts up. But, even if the ADC is innacurate, its good to see that whatever voltage it is measuring is very stable. also, a few pages back, i went into why i dont think we will be able to overclock the A9's much more based on the information in the A9 chip datasheet. if it were a spi issue, lowering the speed may or may not solve the problem because it could be a clocking issue (ie: setup and hold time for clock/data does not comply with spec (which is not listed in datasheet of course))....and it might also add more issues by itself |
|
|
|
Hi, Would like to report a crash/restart due to memory leak/ out of memory. This happens maybe once every few days so far, so its not too important, but may end up reducing my share for a certain block if it cuts out at a bad time. Anyone else get this? Jul 30 16:43:53 InnoMiner kernel: lowmem_reserve[]: 0 0 0
Jul 30 16:43:53 InnoMiner kernel: Normal: 112*4kB (UMEC) 57*8kB (UEC) 32*16kB (UEC) 11*32kB (EC) 11*64kB (UEC) 17*128kB (UEC) 2*256kB (C) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 5160kB
Jul 30 16:43:53 InnoMiner kernel: 3607 total pagecache pages
Jul 30 16:43:53 InnoMiner kernel: 0 pages in swap cache
Jul 30 16:43:53 InnoMiner kernel: Swap cache stats: add 0, delete 0, find 0/0
Jul 30 16:43:53 InnoMiner kernel: Free swap = 0kB
Jul 30 16:43:53 InnoMiner kernel: Total swap = 0kB
Jul 30 16:43:53 InnoMiner kernel: 65536 pages RAM
Jul 30 16:43:53 InnoMiner kernel: 0 pages HighMem/MovableOnly
Jul 30 16:43:53 InnoMiner kernel: 2895 pages reserved
Jul 30 16:43:53 InnoMiner kernel: 4096 pages cma reserved
Jul 30 16:43:53 InnoMiner kernel: [ pid ] uid tgid total_vm rss nr_ptes nr_pmds swapents oom_score_adj name
Jul 30 16:43:53 InnoMiner kernel: [ 747] 0 747 5973 458 7 0 0 0 systemd-journal
Jul 30 16:43:53 InnoMiner kernel: [ 750] 0 750 1521 100 5 0 0 -1000 systemd-udevd
Jul 30 16:43:53 InnoMiner kernel: [ 1268] 1007 1268 1584 63 5 0 0 0 systemd-resolve
Jul 30 16:43:53 InnoMiner kernel: [ 1269] 1008 1269 3827 66 6 0 0 0 systemd-timesyn
Jul 30 16:43:53 InnoMiner kernel: [ 1271] 0 1271 588 7 3 0 0 0 getty
Jul 30 16:43:53 InnoMiner kernel: [ 1272] 0 1272 13700 8556 23 0 0 0 dm-monitor
Jul 30 16:43:53 InnoMiner kernel: [ 1276] 0 1276 2924 269 8 0 0 0 php-fpm
Jul 30 16:43:53 InnoMiner kernel: [ 1277] 1000 1277 1179 59 5 0 0 -900 dbus-daemon
Jul 30 16:43:53 InnoMiner kernel: [ 1287] 0 1287 11091 95 12 0 0 0 swupdate
Jul 30 16:43:53 InnoMiner kernel: [ 1298] 0 1298 802 73 4 0 0 0 nginx
Jul 30 16:43:53 InnoMiner kernel: [ 1301] 33 1301 876 132 4 0 0 0 nginx
Jul 30 16:43:53 InnoMiner kernel: [ 1307] 0 1307 6225 102 8 0 0 0 swupdate
Jul 30 16:43:53 InnoMiner kernel: [ 1313] 0 1313 1138 68 5 0 0 -1000 sshd
Jul 30 16:43:53 InnoMiner kernel: [ 1322] 1006 1322 1531 69 5 0 0 0 systemd-network
Jul 30 16:43:53 InnoMiner kernel: [ 1921] 1003 1921 8250 120 10 0 0 0 systemd-journal
Jul 30 16:43:53 InnoMiner kernel: [11632] 0 11632 79135 44634 109 0 0 0 cgminer
Jul 30 16:43:53 InnoMiner kernel: Out of memory: Kill process 11632 (cgminer) score 692 or sacrifice child
Jul 30 16:43:53 InnoMiner kernel: Killed process 11632 (cgminer) total-vm:316540kB, anon-rss:178540kB, file-rss:0kB, shmem-rss:0kB
Jul 30 16:43:53 InnoMiner kernel: oom_reaper: reaped process 11632 (cgminer), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
Jul 30 16:43:53 InnoMiner cgminer[11632]: [865B blob data]
Jul 30 16:43:53 InnoMiner systemd[1]: cgminer.service: Main process exited, code=killed, status=9/KILL
Jul 30 16:43:53 InnoMiner systemd[1]: cgminer.service: Failed with result 'signal'.
Jul 30 16:43:53 InnoMiner systemd[1]: cgminer.service: Service hold-off time over, scheduling restart.
Jul 30 16:43:53 InnoMiner systemd[1]: cgminer.service: Scheduled restart job, restart counter is at 2.
Jul 30 16:43:53 InnoMiner systemd[1]: Stopped sgminer4a9.
Jul 30 16:43:53 InnoMiner systemd[1]: Starting sgminer4a9...
Jul 30 16:43:53 InnoMiner systemd[1]: Started sgminer4a9.
|
|
|
|
To help guide anyone a step further, based on the pictures the previous user showed, and the available chip footprint information (see my previous post), my best guess on where to probe VDD_CORE is right here  |
|
|
|
Guys I just bought one, and started to mine.
I saw around 40-42 K/SOLS all the time, not reaching 50. (I currently use nanopool)
I changed the performance mode still the same. Current Firmware is b29+_20180706_032013
6th of July 2018 03:20 AM , I haven't updated to new one yet.
First and second cards are ok at rate of 14-15 Kslols but third one stuck at 10Klsos.
Do you have any idea ? Thanks in advance.
Silicon lottery. Not much that you're able to do about that. I can tell you what hasn't worked. I have a bad unit that does 12ksol/8ksol/7ksols. I have: Used different firmwares Set fans 100% Changed controller board Changed Power supply Inspected board for visual issues -none Applied thermal paste Overclocked Overclocking has produced no noticeable gains. Under clocking works but does not reduce HW errors (only some firmware shows this). Tried 1250-1350mhz/VID 155-180 for overclock. Gunna compare per chip voltages from reported to reality and between my good and bad unit this weekend. Also trying to figure out how/if I can reduce the SPI speed. Kinda think it's bad chips but innosilicon vaguely said they didn't think so. I'll post more if I find anything. hey - based on the A9 chip datasheet, i think you are on the right track to debugging your slow cards. I would definitely try to probe your core voltages for each individual ASIC to see where they really are.  You wont be able to probe directly at the chip because its surface mount, but look for some big capacitors and probe across them. You should find some in the range of core voltage (0.8->0.9). There will probably be a bunch of caps connected to the core voltage pad (VDD_CORE). Its very large so it seems this is where the majority of the current sinks to. If you get some numbers I would be super interested in hearing what kind of measurements you found on your good and bad cards. Good luck and thanks in advance! |
|
|
|
I found weird thing on A9.
If you leave webpage open to miner, productivity for miner will be lower... Maybe because web-server is using a lot resources? I found with Nicehash, if web-page to miner opened it disconnects miner from pool very often.
I have never experienced pool disconnects with my A9, but I do not use nicehash. I will test the theory of the web page opening causing performance decrease, but i highly doubt it. The ASIC system is separate from the FPGA chip that allows networking/ssh/etc. <edit> i see no correlation here |
|
|
|
Took apart a bad (50%) Hash board. I was hoping for something obvious to stand out. Nothing did. The boards where quite nice. Solder looked nice. Heatsinks are screwed down and easy to work work. Thermal grease on the backside and Thubber, Thermal Rubber, on the tops. Replaced thubber with Arctic Silver, may have dropped 1C, hash rate wasn't noticeably better.
I'll post photos in 12 hours.
Probably will troubleshooting a bit in a few days when I'm free. Check th voltage to hashing Chips's, bypass some chips and see what happenes. Hopefully borrow a flir IR Camera and have a look. Any experience floating around that could send some ideas my way?
can you post a picture of the asic card? ive been wondering if off-the-shelf water cooling thermal blocks might fit on the chips also i dont see any correlation between asic temperature and hash rate speed. before modding my fan, my asic cards sat at 70C and still hash with the same efficiency sitting at 50C. |
|
|
|
A day of hashing zencash back at the autotuned performance mode shows more stable performance on my miner. No dips below 40ksol, whereas when I set the PLL clock higher before, I would dip in the 30s. Sometimes I see spikes into the higher 60s... The poster Hawkfish a few pages back has a much more stable A9 than I do...unless it has something to do with the pool I am mining on? Right now the only mod Im using is fan speedup, I think any overclock will need to optimize VID with PLL based on what I can see.  |
|
|
|
|
u'09 pllOptimal': False,
u'10 PLL': 354,
u'10 pllOptimal': False,
u'11 PLL': 354,
u'11 pllOptimal': False,
u'pllOptimal': True},
hmmmmmmmmmm...weirdness...not sure how to translate these numbers and why it says falsefalsefalse, but then true....
u'VoltageBalanced': False,
u'Voltage Avg': 860.0,
u'Voltage Max': 872.0,
u'Voltage Min': 850.0,
this is in volts... 0.872V is your max core voltage. like i posted before, the asic datasheet spec says optimal core voltage is 0.90V +/-10% so this can be bumped higher for the people who want to play mad scientist.
u'VoltageBalanced': False,
i think this indicates your 3 asic cards are running at different core voltages, so some tuning of the VID for each chain will be necessary.
try changing T1PLL to 1325 and see what the u'PLL #'s come back as.
Also, try bumping T1VID up to 175 to see where your core voltage sits.
if there is more to the printout can you please post the entire thing next time?
BTW you have a typo in your config,
"T1VID1": "170",
"T1VID1": "170",
"T1VID1": "170", you are setting the same variable 3 times
|
|
|
|
FYI, I'm on a D9, but most of the software interface is the same. Last night I found the "stats" cgminer api to obtain the details of each chip (e.g., nVol, Temp, PLL). I think the values that come back are not in the units that we'd like (e.g., temp = 505; maybe correlates to 67C), but I think it would be worthwhile if someone did this for the A9 and measured the values in each of the different modes. I plan on doing this (maybe tonight) on the D9. Hopefully there's something that correlates so that we can figure out if altering the .conf file is having any remaining effects.
can you please explain how you accessed the "stats" cgminer api? |
|
|
|
A little further down it says this... In the high performance hashing mode,
our recommended operation range is centered around 0.90V (+-10%) I take this to mean that there is headroom on the 0.9V max voltage spec. 10% gives us lets say 1.0V maximum. So since the hashing table shows core voltage jumps in steps of 30mV, we MIGHT have 4 more steps from 0.87V to 1V . (0.9, 0.93, 0.96, 0.99) The increase in hashing is probably not linear seeing as how 0.82V gives you 1210sol/s, 0.85 gives you 1320so/s (110sol difference), but 0.87 only gives you 1375sol/s (only 50sol difference). So lets be optimistic and say we get 40 sol, then 25, then 15, then 5 more sol at 0.99....thats maybe 85sol/s per chip. So (1375+85)*12*3 = 52560.... So about 2.56ksol/s extra per miner...and your reeeealy pushing the upper bounds. This would probably reduce lifetime of the miner. In my opinion, as I can see it right now, it doesnt seem like its worth it to try to overclock the A9....BUT, SOMEONE PLEASE PROVE ME WRONG!!!!!! IM JUST SOME STUPID GUY ON THE INTERNET |
|
|
|
Another really interesting blurb in the datasheet Configurable in SPI daisy chain for up to 128 ASICs under one MCU control This means, technically, they could build an equihash miner with 1 controller board and 128*1375=176Ksol/s. That would be 16 asics per card, and 8 inputs to their controller boards....which...oh look...there are 8 inputs into their controller board! That would be a 2048W miner.....cooling that would be a nightmare...unless you spaced them out a bit and water cooled them all with custom water cooling blocks........ |
|
|
|
Oh wow you found the chip datasheet! I didnt realize they had this.... Soooo, I see that table. I also see this blurb below it: Operating voltage: A9 Zmaster core voltage can be anywhere from 0.75V to 0.90V. This means the following: 1) if the 0.90V max is the ABSOLUTE maximum voltage, then 0.87 is probably the highest you want to go. But, if its just maximum OPERATING voltage range, that means there is some headroom. But, lets say we push it up to 0.9V (this chart proves we need to increase voltage in order to successfully increase PLL speed). We can extrapolate from that chart we would only get MAYBE 50sol/s more per chip. 12 chips per card, 3 cards...or only a 1.8ksol increase. If the chip datasheet itself doesnt specify absolute maximum voltage, again there may be some headroom here....but its expensive equipment and I dont know if a 1.8ksol boost is worth it. Its definitly not the 50%+ boost that the z9s can get. Maybe someone is brave enough to open up the A9 and try to find a capacitor to probe the actual core voltage...because the board design might be bad and it might not actually be delivering 0.87V. Im going to assume that the 166 setting means 0.87V since the miner logs says PLL is tuned for 1250MHz. |
|
|
|
I reconnected my bitmain PSU and will report back to see if my hashrates have stabilized more. In the meantime, can anyone else report that they see extremely high hashrates when turning the ASIC on, eventually dropping back to the 50ksol range?  Yes I do see high hash rates in the first couple minutes. Might it be an artifact of it submitting successful hashes at a lower difficulty? I also get the feeling that adjusting PLL speeds in cgminer.conf isn't properly taking effect or is somehow reverted. It's puzzling. With gpu mining and Equihash increasing core clock speed didn't make nearly as much difference in memory clock speed. At the same time the Bitmain Z9 seems easily amenable to overclock. However, one thing that points to the PLL clock settings working is the experience I had this weekend when trying 1450....Miner logs said error communicating with ASIC chips, so I went back down in speed. I swapped out the bitmain power supply and it didnt seem to make a difference in my widely fluctuating hash rates. So, I just tried reverting back to the original settings (auto tuned performance) but with fan set to 30%. Seems like my A9 is back to "normal" fluctuation rates. So I think the PLL and VID settings I had were actually causing some instability. Whether or not the fluctuating hashrates averaged out to a faster hash rate is very questionable because, as we can all see...there seems to be no solid hash measurement. Pools report something different than the A9, the A9 is widely varies itself. With the Z9 mini it seems people get a solid stable 16ksol when overclocking, and its repeatable. |
|
|
|
I also found a file I cannot touch called 99 environment which looks to be something valuable.
I dug deeper into the PHP and found there is an access or Profile called AutoTuneMode
yes there is an autotune mode (factory, balanced, performance, economy or whatever its called)....and if you look at the miner logs when the system is booting, everytime you reconnect to a pool or reboot your asic, it goes through that auto-retuning process. im not exactly sure what it is doing, but it looks as though its trying to calibrate the clocks of each of the 3 ASIC cards. It seems to sweep through low frequencies to high frequencies and comes up with a table of speeds that each card is possible of doing, for example set PLL to 1250 might set card A to 1249.89, card B to 1250.01, card C to 1249.88. however, once this is completed, i have never seen it touch pll clocks again during run time. the only thing i see it tune is the fan speed automatically. im wondering if we are actually doing anything when we manually set the PLL clocks because it hasnt actually calibrated the system for that speed in the tuning process i just tried to describe. |
|
|
|
I reconnected my bitmain PSU and will report back to see if my hashrates have stabilized more. In the meantime, can anyone else report that they see extremely high hashrates when turning the ASIC on, eventually dropping back to the 50ksol range? |
|
|
|
|
