Innosilicon releases A9 Zmaster 50ksol/s Equihash miner at 620W

[minefarmbuy]

Saw on twitter they were having a ddos attach, but I'm pretty sure that nicehash isn't very stable with the asic. Could be wrong though.

[chinguyensg]

Saw on twitter they were having a ddos attach, but I'm pretty sure that nicehash isn't very stable with the asic. Could be wrong though.

Thank you, minefarmbuy !
I am living in asia and no pools of nicehash is available now.

[minefarmbuy]

Welcome, but not sure I'm that much help. We've struggled to get testing units from Inno. We would love to have better advice to give.

Other users have reported issues with connectivity with nicehash on equihash asics. That and the ddos attack news today, you might be able to select another country/region server without issue if you enjoy their service.

[chinguyensg]

Welcome, but not sure I'm that much help. We've struggled to get testing units from Inno. We would love to have better advice to give.

Other users have reported issues with connectivity with nicehash on equihash asics. That and the ddos attack news today, you might be able to select another country/region server without issue if you enjoy their service.

Yes, I understood, I will follow your advice

[katsapliasR]

I'm trying to send the command from a linux host:

Code:

echo "switchpool|1" | nc x.x.x.x 4028

and I get the response:

Code:

STATUS=E,When=1532879894,Code=45,Msg=Access denied to 'switchpool' command,Description=sgminer 4.4.2

I have already tried to add the options:

Code:

"api-groups": "H:switchpool:enablepool:addpool:disablepool:removepool:poolpriority",
"api-allow": "R:0/0,W:0/0",

or

Code:

"api-allow": "R:0/0,W:*",

with no luck

but from the same host I get response from the read-only command:

Code:

echo '{"command":"stats"}' | nc x.x.x.x 4028

any suggestions?

[sweeperAA]

I'm trying to send the command from a linux host:

Code:

echo "switchpool|1" | nc x.x.x.x 4028

and I get the response:

Code:

STATUS=E,When=1532879894,Code=45,Msg=Access denied to 'switchpool' command,Description=sgminer 4.4.2

I have already tried to add the options:

Code:

"api-groups": "H:switchpool:enablepool:addpool:disablepool:removepool:poolpriority",
"api-allow": "R:0/0,W:0/0",

or

Code:

"api-allow": "R:0/0,W:*",

with no luck

but from the same host I get response from the read-only command:

Code:

echo '{"command":"stats"}' | nc x.x.x.x 4028

any suggestions?

Do you have privileged access working? What does the "privileged" command return?

If you don't have privileged access working, the only way I've been able to get it working is to modify the cgminer.service script in /etc/systemd/system/multi-user.target.wants/ to add "--api-allow W:0/0".

[katsapliasR]

I'm trying to send the command from a linux host:

Code:

echo "switchpool|1" | nc x.x.x.x 4028

and I get the response:

Code:

STATUS=E,When=1532879894,Code=45,Msg=Access denied to 'switchpool' command,Description=sgminer 4.4.2

I have already tried to add the options:

Code:

"api-groups": "H:switchpool:enablepool:addpool:disablepool:removepool:poolpriority",
"api-allow": "R:0/0,W:0/0",

or

Code:

"api-allow": "R:0/0,W:*",

with no luck

but from the same host I get response from the read-only command:

Code:

echo '{"command":"stats"}' | nc x.x.x.x 4028

any suggestions?

Do you have privileged access working? What does the "privileged" command return?

If you don't have privileged access working, the only way I've been able to get it working is to modify the cgminer.service script in /etc/systemd/system/multi-user.target.wants/ to add "--api-allow W:0/0".

no, the "privileged" commands return the same error code, so I will try your suggestion
I couldn't find any documentation for the cgminer.service script, can I add the "--api-allow W:0/0" on the "[Service]" section?
BTW the cgminer.service is read-only and I cannot do any changes
 

[sweeperAA]

I'm trying to send the command from a linux host:

Code:

echo "switchpool|1" | nc x.x.x.x 4028

and I get the response:

Code:

STATUS=E,When=1532879894,Code=45,Msg=Access denied to 'switchpool' command,Description=sgminer 4.4.2

I have already tried to add the options:

Code:

"api-groups": "H:switchpool:enablepool:addpool:disablepool:removepool:poolpriority",
"api-allow": "R:0/0,W:0/0",

or

Code:

"api-allow": "R:0/0,W:*",

with no luck

but from the same host I get response from the read-only command:

Code:

echo '{"command":"stats"}' | nc x.x.x.x 4028

any suggestions?

Do you have privileged access working? What does the "privileged" command return?

If you don't have privileged access working, the only way I've been able to get it working is to modify the cgminer.service script in /etc/systemd/system/multi-user.target.wants/ to add "--api-allow W:0/0".

no, the "privileged" commands return the same error code, so I will try your suggestion
I couldn't find any documentation for the cgminer.service script, can I add the "--api-allow W:0/0" on the "[Service]" section?
BTW the cgminer.service is read-only and I cannot do any changes
 

You have to remount the filesystem as read/write: "mount / -o rw,remount"

My cgminer.service line looks like: "ExecStart=/bin/cgminer -c /etc/cgminer.conf --api-listen --api-network --api-allow W:0/0 -syslog --text only"

[wKiV7378U]

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.

[EK701]

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?

[battbot]

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?

I have the exact same issue.  Have not found a fix yet.

[Solsichu]

On top of a different firmware, If you can SSH in you can try

    "lowmem": true,

in config/cgminer.conf

[Solsichu]

Can anyone please post the number of cores reported when you miner initializes?  After PLL Clock and VID is set it comes up in the log.

or by SSH cgminer-api -o stats | sed 's/,/\n/g' | grep 'cores'

My 28ksol:
Num cores=370
Num cores=373
Num cores=373

My 50ksol:
Num cores=384
Num cores=375
Num cores=377


its not exactly a direct relation in performance to core count but im curious if the lower hashing units always have lower core counts.

I haven't Bought a new Oscilloscope yet as im still behind from buying my A9's. Dont even have a good multi meter here. But I see very little variation in 'cgminer-api -o stats' Min/Max voltage and nVol per chip. Its incredibly stable. I would suspect its not updating but I did see a very slight difference in reported value over time in performance mode. Think it was 0.001 Volts. lol.  Over and Under volt does nothing significant to performance. I may have gotten another 1ksol avg from overvolting, but i haven't done a comparison with hard data. Hardware Errors vs Valid Nounces seems to be what I need to compare. Whats crazy is underclocking down to 230Mhz didn't effect the error rate. And the errors are randomly spread across chips in a steady ratio.


cgminer-api -o stats | sed 's/,/\n/g' | grep -E 'found|HW'
00 HW errors=140
00 Nonces found=71
01 HW errors=146
01 Nonces found=74
02 HW errors=177
02 Nonces found=31
03 HW errors=89
03 Nonces found=117
04 HW errors=120
04 Nonces found=73
05 HW errors=103
05 Nonces found=112
06 HW errors=137
06 Nonces found=53
07 HW errors=104
07 Nonces found=118
08 HW errors=146
08 Nonces found=67
09 HW errors=77
09 Nonces found=121
10 HW errors=118
10 Nonces found=102
11 HW errors=61
11 Nonces found=136
00 HW errors=106
00 Nonces found=105
01 HW errors=113
01 Nonces found=107
02 HW errors=125
02 Nonces found=78
03 HW errors=54
03 Nonces found=149
04 HW errors=100
04 Nonces found=121
05 HW errors=100
05 Nonces found=122
06 HW errors=197
06 Nonces found=28
07 HW errors=84
07 Nonces found=138
08 HW errors=13
08 Nonces found=198
09 HW errors=156
09 Nonces found=35
10 HW errors=132
10 Nonces found=87
11 HW errors=179
11 Nonces found=22
00 HW errors=67
00 Nonces found=137
01 HW errors=80
01 Nonces found=135
02 HW errors=204
02 Nonces found=7
03 HW errors=55
03 Nonces found=159
04 HW errors=14
04 Nonces found=183
05 HW errors=63
05 Nonces found=139
06 HW errors=24
06 Nonces found=199
07 HW errors=102
07 Nonces found=98
08 HW errors=64
08 Nonces found=184
09 HW errors=42
09 Nonces found=175
10 HW errors=51
10 Nonces found=149
11 HW errors=68
11 Nonces found=155


So I don't know. My gut says these are bad chips and the supporting hardware is fine. But I cant really know that for sure until I get in there and do some measurements.

I was also playing around with
'bitmine-a1-options 0:0:390:0' to try and limit the spi speed - no idea if it did anything, took the command tho.
'bitmine-a1-options 0:0:0:6' to disable 6 chips in each chain. Workedm I got roughly 1/2 sols. but not exactly as poor hashing chips are randomly placed. Didnt really let it ramp up.

[wKiV7378U]

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

[xpulse]

Code:

[quote author=Solsichu link=topic=4432819.msg43172941#msg43172941 date=1532978697]
Can anyone please post the number of cores reported when you miner initializes?  After PLL Clock and VID is set it comes up in the log.

or by SSH cgminer-api -o stats | sed 's/,/\n/g' | grep 'cores'

My 28ksol:
Num cores=370
Num cores=373
Num cores=373

My 50ksol:
Num cores=384
Num cores=375
Num cores=377


its not exactly a direct relation in performance to core count but im curious if the lower hashing units always have lower core counts. 

I haven't Bought a new Oscilloscope yet as im still behind from buying my A9's. Dont even have a good multi meter here. But I see very little variation in 'cgminer-api -o stats' Min/Max voltage and nVol per chip. Its incredibly stable. I would suspect its not updating but I did see a very slight difference in reported value over time in performance mode. Think it was 0.001 Volts. lol.  Over and Under volt does nothing significant to performance. I may have gotten another 1ksol avg from overvolting, but i haven't done a comparison with hard data. Hardware Errors vs Valid Nounces seems to be what I need to compare. Whats crazy is underclocking down to 230Mhz didn't effect the error rate. And the errors are randomly spread across chips in a steady ratio.


cgminer-api -o stats | sed 's/,/\n/g' | grep -E 'found|HW'
00 HW errors=140
00 Nonces found=71
01 HW errors=146
01 Nonces found=74
02 HW errors=177
02 Nonces found=31
03 HW errors=89
03 Nonces found=117
04 HW errors=120
04 Nonces found=73
05 HW errors=103
05 Nonces found=112
06 HW errors=137
06 Nonces found=53
07 HW errors=104
07 Nonces found=118
08 HW errors=146
08 Nonces found=67
09 HW errors=77
09 Nonces found=121
10 HW errors=118
10 Nonces found=102
11 HW errors=61
11 Nonces found=136
00 HW errors=106
00 Nonces found=105
01 HW errors=113
01 Nonces found=107
02 HW errors=125
02 Nonces found=78
03 HW errors=54
03 Nonces found=149
04 HW errors=100
04 Nonces found=121
05 HW errors=100
05 Nonces found=122
06 HW errors=197
06 Nonces found=28
07 HW errors=84
07 Nonces found=138
08 HW errors=13
08 Nonces found=198
09 HW errors=156
09 Nonces found=35
10 HW errors=132
10 Nonces found=87
11 HW errors=179
11 Nonces found=22
00 HW errors=67
00 Nonces found=137
01 HW errors=80
01 Nonces found=135
02 HW errors=204
02 Nonces found=7
03 HW errors=55
03 Nonces found=159
04 HW errors=14
04 Nonces found=183
05 HW errors=63
05 Nonces found=139
06 HW errors=24
06 Nonces found=199
07 HW errors=102
07 Nonces found=98
08 HW errors=64
08 Nonces found=184
09 HW errors=42
09 Nonces found=175
10 HW errors=51
10 Nonces found=149
11 HW errors=68
11 Nonces found=155


So I don't know. My gut says these are bad chips and the supporting hardware is fine. But I cant really know that for sure until I get in there and do some measurements.

I was also playing around with 
'bitmine-a1-options 0:0:390:0' to try and limit the spi speed - no idea if it did anything, took the command tho.
'bitmine-a1-options 0:0:0:6' to disable 6 chips in each chain. Workedm I got roughly 1/2 sols. but not exactly as poor hashing chips are randomly placed. Didnt really let it ramp up.

[/quote]

Here is mine results:
Num cores=375
Num cores=376
Num cores=376

Num cores=375
Num cores=375
Num cores=380

00 HW errors=505
00 Nonces found=939
01 HW errors=207
01 Nonces found=1226
02 HW errors=215
02 Nonces found=1288
03 HW errors=387
03 Nonces found=1135
04 HW errors=186
04 Nonces found=1261
05 HW errors=172
05 Nonces found=1324
06 HW errors=379
06 Nonces found=1192
07 HW errors=214
07 Nonces found=1282
08 HW errors=1426
08 Nonces found=63
09 HW errors=739
09 Nonces found=739
10 HW errors=969
10 Nonces found=503
11 HW errors=589
11 Nonces found=933
00 HW errors=199
00 Nonces found=1335
01 HW errors=209
01 Nonces found=1353
02 HW errors=884
02 Nonces found=628
03 HW errors=549
03 Nonces found=974
04 HW errors=191
04 Nonces found=1338
05 HW errors=1066
05 Nonces found=437
06 HW errors=745
06 Nonces found=803
07 HW errors=207
07 Nonces found=1310
08 HW errors=1148
08 Nonces found=412
09 HW errors=1024
09 Nonces found=462
10 HW errors=583
10 Nonces found=976
11 HW errors=209
11 Nonces found=1271
00 HW errors=198
00 Nonces found=1340
01 HW errors=1158
01 Nonces found=449
02 HW errors=652
02 Nonces found=829
03 HW errors=691
03 Nonces found=817
04 HW errors=482
04 Nonces found=1087
05 HW errors=885
05 Nonces found=621
06 HW errors=207
06 Nonces found=1287
07 HW errors=209
07 Nonces found=1366
08 HW errors=559
08 Nonces found=983
09 HW errors=195
09 Nonces found=1294
10 HW errors=220
10 Nonces found=1290
11 HW errors=216
11 Nonces found=1308
#


Never get more than 41K on Nicehash or more than 42K on flypool

[Solsichu]

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.

[Solsichu]

Code:

Here is mine results:
Num cores=375
Num cores=376
Num cores=376

Num cores=375
Num cores=375
Num cores=380
...
# 

Never get more than 41K on Nicehash or more than 42K on flypool

Interesting to see the HW failure rate on some of your chips eh? That ratio will hold. Always giving roughly that ratio of HW errors to valid Nonce shares. I havent been able to affect this ratio significantly even running them at 20% clock speed.

I found the post about the guy lower his temp and loosing hashrate somewhat interesting. Ive done a bit of heat up testing and haven't gotten anything. I suspect he has a bad solder joint that is functional when hot. But that's a guess. If anyone with heat related hashrate changes wants todo this HW error rate print out before and after, that would be interesting.

[mexeri]

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!
 

[wKiV7378U]

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.

[wKiV7378U]

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.