Bitcoin Forum>Bitcoin>Mining>Hardware
Pages:
Author

Topic: Algorithmically placed FPGA miner: 255MH/s/chip, supports all known boards - page 25. (Read 119468 times)

eldentyrell
donator
Activity: 980
Merit: 1004
felonious vagrancy, personified
Re: Algorithmically placed FPGA miner: 255MH/s/chip, supports all known boards
June 28, 2012, 03:13:09 PM
#522

At 164/152/146 = 232MH/s we were getting 0.5% errors, so we downclocked to 162/150/146 = 230MH/s and let it run overnight -- 0% errors.  Here's the hashrate measured at Eligius: 225MH/s of shares and 2% stales is exactly 230MH/s.  We're working on improving the stales to something more like 1%.  Power consumption is 10.68W at the 12V input meaning efficiency is 21.17MH/J.





 

eldentyrell
donator
Activity: 980
Merit: 1004
felonious vagrancy, personified
Re: Algorithmically placed FPGA miner: 255MH/s/chip, supports all known boards
June 27, 2012, 06:34:30 PM
#521
TML 0.92 has been released.  Default frequencies are 164/152/146 for an expected 232MH/s; here's the CHANGELOG:

Code:
             Tolerate empty replies to Long-Poll GetWork()
             Add more intelligent code for clock muxing
             Change master ring to top ring after gateware v 0x4fe41753
             Add hack for bitstreams with broken DCM.DONE
             More verbose error messages for Ztex
             Add slow-start clock ramping
             Add triconemining.avoid_reprogramming
27.Jun.2012  Release v0.92, gateware 0x4fea1574 rated at 164/152/146 = 232MH/s


This version also lets you set the clock frequencies separately for the three rings; to run 100/101/102, type:

Code:
java … ztex:0:0@100 ztex:0:1@101 ztex:0:2@102


Planned features for 0.93:

  - fix the timing error in ring#2 so it can run above 146mhz
  - make the status line shorter and more informative
  - automatic clock frequency setting for optimal performance
  - ability to global-reset the chip if error rates get too high

Thanks to kakobrekla and punin for help testing!
eldentyrell
donator
Activity: 980
Merit: 1004
felonious vagrancy, personified
Re: Algorithmically placed FPGA miner: 255MH/s/chip, supports all known boards
June 27, 2012, 06:22:56 PM
#520
Quote from: punin on June 27, 2012, 04:58:41 PM
I can report 150MHz 0.0% errors with 0.92b. Unmodified 1.15x with standard Xilence heatsink. Temps ~40°C on heatsink, 45°C on underside. 26°C ambient.

Sweet, 0.92b will become the "official" 0.92.  We're dropping 0.92a.  Thank you for your help testing!
punin
hero member
Activity: 560
Merit: 500
Re: Algorithmically placed FPGA miner: 255MH/s/chip, supports all known boards
June 27, 2012, 04:58:41 PM
#519
I can report 150MHz 0.0% errors with 0.92b. Unmodified 1.15x with standard Xilence heatsink. Temps ~40°C on heatsink, 45°C on underside. 26°C ambient.
kakobrekla
hero member
Activity: 714
Merit: 500
Psi laju, karavani prolaze.
Re: Algorithmically placed FPGA miner: 255MH/s/chip, supports all known boards
June 27, 2012, 09:37:30 AM
#518
Heya,

so today i took the HS down and reapplied thermal paste also added a fan on the bottom of ztex board.
I ran the latest  ZtexBTCMiner-120622.jar and hashrate stabilized at 216 with sub 0.5% invalids.
Then I tested your bitstream at 144, which would be the same as ztex puts out, but everything was invalid from all rings.
@142, [ztex:0:1 ] setting clock to 140 Mhz, mult=44 div=15,  211MH/s theoretical, everything is valid and accepted from all rings.

I'm looking into vmod now, looks like your bitstream is more power hungry and im far from ztexes cap at 248mhz.

Can't wait for the working option to set individual cores speeds.
eldentyrell
donator
Activity: 980
Merit: 1004
felonious vagrancy, personified
Re: Algorithmically placed FPGA miner: 255MH/s/chip, supports all known boards
June 27, 2012, 03:12:30 AM
#517
Quote from: kakobrekla on June 26, 2012, 09:11:35 PM
Reporting a successful one hour run at 140mhz with 0% invalids
 ( 68MH/s   0.0 %  140Mhz)  ( 63MH/s   0.0 %  140Mhz)  ( 63MH/s   0.0 %  140Mhz) overall: 200MH/s   0.0 % ; 210MH/s theoretical
BTCguild was reporting ~ 200mhash.

Ok, not a bad start.

Unfortunately there is a bug that occasionally causes one of the rings to go from 0% errors to 50%-100% errors and get stuck there until it has been reset.  I think I know what it is and I have another build running with the fix, but it will not be done until late tomorrow night (~20hrs from this posting).

Again, big thanks to kakobrekla for being patient with the configuration issues.  I think we've figured out a way to "partition" all of the ztex-usb-specific issues people have been having: I've updated the download page to tell people they must first make sure their board works with ztex's miner in "cluster mode" (-m c) before attempting to use the TML.  This doesn't make the configuration/usb/eeprom issues go away, but it does make them a problem for the ztex forum Smiley.  If your board mines in ztex cluster mode, it will mine with the TML.  Unfortunately getting the ztex boards to work happily in cluster mode appears to involve magical incantations, jumpers, and the waving of dead chickens.
kakobrekla
hero member
Activity: 714
Merit: 500
Psi laju, karavani prolaze.
Re: Algorithmically placed FPGA miner: 255MH/s/chip, supports all known boards
June 26, 2012, 09:11:35 PM
#516
Reporting a successful one hour run at 140mhz with 0% invalids

 ( 68MH/s   0.0 %  140Mhz)  ( 63MH/s   0.0 %  140Mhz)  ( 63MH/s   0.0 %  140Mhz) overall: 200MH/s   0.0 % ; 210MH/s theoretical


BTCguild was reporting ~ 200mhash.
eldentyrell
donator
Activity: 980
Merit: 1004
felonious vagrancy, personified
Re: Algorithmically placed FPGA miner: 255MH/s/chip, supports all known boards
June 26, 2012, 07:27:28 PM
#515
Quote from: kakobrekla on June 26, 2012, 06:44:21 PM
Code:
java.lang.ArithmeticException: / by zeros   0.0 % ;   0H/s theoretical
        at com.triconemining.bitcoin.miner.Ring.loadJob(Ring.java:102)
        at com.triconemining.bitcoin.miner.Main.run(Main.java:93)
        at java.lang.Thread.run(Thread.java:722)
^C

Very sorry!  TML 0.91 has a bunch of bugs in the software that sets the rings' clock frequencies individually.  We will get this fixed tonight and post 0.92.
kakobrekla
hero member
Activity: 714
Merit: 500
Psi laju, karavani prolaze.
Re: Algorithmically placed FPGA miner: 255MH/s/chip, supports all known boards
June 26, 2012, 07:25:26 PM
#514
So as per jfsebastien request... short how-to get it working (thanks to BR0KK, ET and JFS)


power off the board, close jp1, power on and release jp1

run

Code:
java -cp FWLoader.jar FWLoader -uu ztex_ufm1_15d4.ix -ue ztex_ufm1_15d4.ihx


and

Code:
java -Xbootclasspath/a:ZtexBTCMiner-120221.jar -jar tml-0.91.jar ztex:0 http://user:pass@host:port

Simple as pie.
kakobrekla
hero member
Activity: 714
Merit: 500
Psi laju, karavani prolaze.
Re: Algorithmically placed FPGA miner: 255MH/s/chip, supports all known boards
June 26, 2012, 06:44:21 PM
#513
Hm, also for some reason while testing separate rings... only 0:1 seems to 'work' (returning invalids though), 0:0 and 0:2 result in

Code:
[ztex:0    ] programming FPGA
[ztex:0    ]   done programming FPGA
[ztex:0    ] magic number check ok
[ztex:0    ] chip is running TML version 0x4fe41753, built 4 days, 16 hours ago
[ztex:0    ] design is intended for input clock frequency of 48 Mhz
[ztex:0    ] chip has 3 rings
[ztex:0:0  ] enabling clock bypass mux
[ztex:0:0  ] enabling clock bypass mux
             adding work source btcguild.com
[ztex:0:0  ] signcrypting 5e06ff262071d8129937d9a2ab77397bc79f9d425d5521eb86d4170ed90bd563:1e5bd1a64fea45ef1a09b78a
[ztex:0:0  ] loading job  5e06ff262071d8129937d9a2ab77397bc79f9d425d5521eb86d4170ed90bd563:1e5bd1a64fea45ef1a09b78a
java.lang.ArithmeticException: / by zeros   0.0 % ;   0H/s theoretical
        at com.triconemining.bitcoin.miner.Ring.loadJob(Ring.java:102)
        at com.triconemining.bitcoin.miner.Main.run(Main.java:93)
        at java.lang.Thread.run(Thread.java:722)
^C

now running 0@100, everything is accepted, but that is 150 theoretical. i'll bump it up.

Code:
              server accepted solution
[ztex:0:2  ] decrypting nonce at address 0x00000001
[ztex:0:2  ]   encrypted nonce = 0x8cf8b4e8
[ztex:0:2  ]   found a share: 0xb2ac0c70
               server accepted solution
[ztex:0:0  ] signcrypting d3c9b46dfcce5340a8574151afce8a37e550f208337dae9d12188019a5d77c49:5fe666104fea498e1a09b78a
[ztex:0:0  ] loading job  d3c9b46dfcce5340a8574151afce8a37e550f208337dae9d12188019a5d77c49:5fe666104fea498e1a09b78a
[ztex:0:1  ] signcrypting 5d4039f84c1a76435d612310958fe03b1ceb263080ab97b0669e595369a0a790:8789b3ba4fea498e1a09b78a
[ztex:0:1  ] loading job  5d4039f84c1a76435d612310958fe03b1ceb263080ab97b0669e595369a0a790:8789b3ba4fea498e1a09b78a
[ztex:0:2  ] signcrypting 2c191ea669affa3ff625c9180b6dfcfd77a41fda02b7b5038debcd9bd7ae4c45:7e76444d4fea49901a09b78a
[ztex:0:2  ] loading job  2c191ea669affa3ff625c9180b6dfcfd77a41fda02b7b5038debcd9bd7ae4c45:7e76444d4fea49901a09b78a
[ztex:0:1  ] decrypting nonce at address 0x00000001
[ztex:0:1  ]   encrypted nonce = 0xa3a892b7
[ztex:0:1  ]   found a share: 0x4e25c832
               server accepted solution
[ztex:0:0  ] decrypting nonce at address 0x000000b8
[ztex:0:0  ]   encrypted nonce = 0x3dd19879
[ztex:0:0  ]   found a share: 0x539e4624
               server accepted solution
[ztex:0:1  ] decrypting nonce at address 0x000000b8
[ztex:0:1  ]   encrypted nonce = 0x56853322
[ztex:0:1  ]   found a share: 0xfd8d5c3a
               server accepted solution
[ztex:0:1  ] decrypting nonce at address 0x0000005c
[ztex:0:1  ]   encrypted nonce = 0xc5bae7e0
[ztex:0:1  ]   found a share: 0xa7a00075
               server accepted solution
[ztex:0:0  ] decrypting nonce at address 0x0000005c
[ztex:0:0  ]   encrypted nonce = 0x935e5e2f
[ztex:0:0  ]   found a share: 0x80f852ff
               server accepted solution
[ztex:0:0  ] decrypting nonce at address 0x0000002e
[ztex:0:0  ]   encrypted nonce = 0x88d294c5
[ztex:0:0  ]   found a share: 0x932fe389
               server accepted solution
[ztex:0:0  ] signcrypting 25025081b86a431ee420f7193df02316aa47cef2cff9e3b0e2145bfa506bdff4:1576601d4fea49e31a09b78a
[ztex:0:0  ] loading job  25025081b86a431ee420f7193df02316aa47cef2cff9e3b0e2145bfa506bdff4:1576601d4fea49e31a09b78a
[ztex:0:1  ] signcrypting 2f755f56f8493d00b4af2eb94fcd4d4e7a778e16eafb12d3630a261d2bd7ee93:ab82f82c4fea49e31a09b78a
[ztex:0:1  ] loading job  2f755f56f8493d00b4af2eb94fcd4d4e7a778e16eafb12d3630a261d2bd7ee93:ab82f82c4fea49e31a09b78a
[ztex:0:1  ] decrypting nonce at address 0x0000002e
[ztex:0:1  ]   encrypted nonce = 0xdf4b6b52
[ztex:0:1  ]   found a share: 0x2208e983
[ztex:0:2  ] signcrypting 907877271d941afab065a49d602afed20b5daa711e0db06355793e9517ec579d:86373d2f4fea49e31a09b78a
               server accepted solution
[ztex:0:2  ] loading job  907877271d941afab065a49d602afed20b5daa711e0db06355793e9517ec579d:86373d2f4fea49e31a09b78a
[ztex:0:2  ] decrypting nonce at address 0x000000b8
[ztex:0:2  ]   encrypted nonce = 0xa45fb442
[ztex:0:2  ]   found a share: 0x8683268a
               server accepted solution
[ztex:0:2  ] decrypting nonce at address 0x0000005c
[ztex:0:2  ]   encrypted nonce = 0xf9743661
[ztex:0:2  ]   found a share: 0xbcb9d3c3
               server accepted solution
[ztex:0:0  ] decrypting nonce at address 0x00000017
[ztex:0:0  ]   encrypted nonce = 0x2bcd4c63
[ztex:0:0  ]   found a share: 0xfd6bad65
               server accepted solution
[ztex:0:2  ] decrypting nonce at address 0x0000002e
[ztex:0:2  ]   encrypted nonce = 0xf29d9134
[ztex:0:2  ]   found a share: 0x56cd10de
               server accepted solution
[ztex:0:1  ] decrypting nonce at address 0x00000017
[ztex:0:1  ]   encrypted nonce = 0x80675b15
[ztex:0:1  ]   found a share: 0x67046463
               server accepted solution
  ( 68MH/s   0.0 %  100Mhz)  ( 68MH/s   0.0 %  100Mhz)  ( 70MH/s   0.0 %  100Mhz) overall: 183MH/s   0.0 % ; 150MH/s theoretical
kakobrekla
hero member
Activity: 714
Merit: 500
Psi laju, karavani prolaze.
Re: Algorithmically placed FPGA miner: 255MH/s/chip, supports all known boards
June 26, 2012, 06:12:01 PM
#512
Quote from: BR0KK on June 26, 2012, 05:52:30 PM
power of the board, close jp1, power on and release jp1.


you should now be able to reprogram it correctly

Looks like that was the magic trick!

We have some progress, some...


Code:
 java -Xbootclasspath/a:ZtexBTCMiner-120221.jar -jar tml-0.91.jar ztex:0 http://user:pass@host:port

_________________________________________________________________________
Tricone Mining Logic, host software v0.9

        ** THIS IS A PRE-RELEASE.  NOT FOR PRODUCTION USE **

   Eldentyrell will declare this codebase ready for production use
   once he has converted his own mine to use it (yes, he pays himself
   commissions).  Until then, performance and signcryption server
   uptime are likely to be erratic.

   Here is a partial list of issues you should be aware of:

     - many kinds of errors (network, etc) cause the miner to get stuck
     - only one of the signcryption frontends is contacted
     - clock-rate adjustment is 100% manual, not automatic
     - no overheat protection >>MAKE SURE YOU HAVE A HEATSINK INSTALLED<<


   ******************************************************************
   *                                                                *
   *               IF YOU EXPERIENCE HIGH ERROR RATES:              *
   *                                                                *
   *  Try running just one ring at a time (e.g. use 'ztex:0:0' on   *
   *  command line instead of 'ztex:0').  If each ring works error  *
   *  free on its own, but you get errors when running all three,   *
   *  it means your power supply is sagging.                        *
   *                                                                *
   ******************************************************************

[ztex:0    ] programming FPGA
[ztex:0    ]   done programming FPGA
[ztex:0    ] magic number check ok
[ztex:0    ] chip is running TML version 0x4fe41753, built 4 days, 16 hours ago
[ztex:0    ] design is intended for input clock frequency of 48 Mhz
[ztex:0    ] chip has 3 rings
[ztex:0:0  ] enabling clock bypass mux
[ztex:0:0  ] enabling clock bypass mux
[ztex:0:1  ] enabling clock bypass mux
[ztex:0:1  ] disabling clock bypass mux
[ztex:0:1  ] setting clock to 152 Mhz, mult=35 div=11
 (  0H/s   0.0 %    0hz) overall:   0H/s   0.0 % ;   0H/s theoretical
// here it hangs for a while
Code:
[ztex:0:2  ] enabling clock bypass mux
[ztex:0:2  ] enabling clock bypass mux
             adding work source 73.215
in 73.215.getWork(): com.triconemining.bitcoin.work.HttpWorkSource$InvalidJsonException: got illegible getwork response:
null
in 73.215.getWork(): com.triconemining.bitcoin.work.HttpWorkSource$InvalidJsonException: got illegible getwork response:
null
in 73.215.getWork(): com.triconemining.bitcoin.work.HttpWorkSource$InvalidJsonException: got illegible getwork response:
null
in 73.215.getWork(): com.triconemining.bitcoin.work.HttpWorkSource$InvalidJsonException: got illegible getwork response:
null
in 73.215.getWork(): com.triconemining.bitcoin.work.HttpWorkSource$InvalidJsonException: got illegible getwork response:
null
in 73.215.getWork(): com.triconemining.bitcoin.work.HttpWorkSource$InvalidJsonException: got illegible getwork response:
null
in 73.215.getWork(): com.triconemining.bitcoin.work.HttpWorkSource$InvalidJsonException: got illegible getwork response:
null
in 73.215.getWork(): com.triconemining.bitcoin.work.HttpWorkSource$InvalidJsonException: got illegible getwork response:
null
in 73.215.getWork(): com.triconemining.bitcoin.work.HttpWorkSource$InvalidJsonException: got illegible getwork response:
null
in 73.215.getWork(): com.triconemining.bitcoin.work.HttpWorkSource$InvalidJsonException: got illegible getwork response:
null
in 73.215.getWork(): com.triconemining.bitcoin.work.HttpWorkSource$InvalidJsonException: got illegible getwork response:
null
in 73.215.getWork(): com.triconemining.bitcoin.work.HttpWorkSource$InvalidJsonException: got illegible getwork response:
null
in 73.215.getWork(): com.triconemining.bitcoin.work.HttpWorkSource$InvalidJsonException: got illegible getwork response:
null
in 73.215.getWork(): com.triconemining.bitcoin.work.HttpWorkSource$InvalidJsonException: got illegible getwork response:
null
in 73.215.getWork(): com.triconemining.bitcoin.work.HttpWorkSource$InvalidJsonException: got illegible getwork response:
null
in 73.215.getWork(): com.triconemining.bitcoin.work.HttpWorkSource$InvalidJsonException: got illegible getwork response:
null
in 73.215.getWork(): com.triconemining.bitcoin.work.HttpWorkSource$InvalidJsonException: got illegible getwork response:
null
in 73.215.getWork(): com.triconemining.bitcoin.work.HttpWorkSource$InvalidJsonException: got illegible getwork response:
null
in 73.215.getWork(): com.triconemining.bitcoin.work.HttpWorkSource$InvalidJsonException: got illegible getwork response:
null


EDIT:

Changed the pool and now its getting some work!
Code:
[ztex:0    ] programming FPGA
[ztex:0    ]   done programming FPGA
[ztex:0    ] magic number check ok
[ztex:0    ] chip is running TML version 0x4fe41753, built 4 days, 16 hours ago
[ztex:0    ] design is intended for input clock frequency of 48 Mhz
[ztex:0    ] chip has 3 rings
[ztex:0:0  ] enabling clock bypass mux
[ztex:0:0  ] enabling clock bypass mux
[ztex:0:1  ] enabling clock bypass mux
[ztex:0:1  ] disabling clock bypass mux
[ztex:0:1  ] setting clock to 152 Mhz, mult=35 div=11
[ztex:0:2  ] enabling clock bypass mux
[ztex:0:2  ] enabling clock bypass mux
             adding work source btcguild.com
[ztex:0:0  ] signcrypting 13b11f1069d37810fbe8d77401d5d3d4a54886c1ea908c279bd202e8d5526344:cfd2d3bb4fea43081a09b78a
[ztex:0:0  ] loading job  13b11f1069d37810fbe8d77401d5d3d4a54886c1ea908c279bd202e8d5526344:cfd2d3bb4fea43081a09b78a
[ztex:0:1  ] signcrypting 1061cdf0e446b6d710e4538c5ca1f58268e834daa3e9606683f6f5497088b1e7:b5abc65e4fea43081a09b78a
[ztex:0:1  ] loading job  1061cdf0e446b6d710e4538c5ca1f58268e834daa3e9606683f6f5497088b1e7:b5abc65e4fea43081a09b78a
[ztex:0:2  ] signcrypting 2411d1e3e9381179974ad30f9c26748512934178ff7bb279c2ea7abf58c4cf9d:77fde8bf4fea43091a09b78a
[ztex:0:2  ] loading job  2411d1e3e9381179974ad30f9c26748512934178ff7bb279c2ea7abf58c4cf9d:77fde8bf4fea43091a09b78a
[ztex:0:0  ] decrypting nonce at address 0x00000001
[ztex:0:0  ]   encrypted nonce = 0x24f34d54
[ztex:0:0  ]   invalid nonce: 0xb0c4f32c
[ztex:0:0  ] decrypting nonce at address 0x000000b8
[ztex:0:0  ]   encrypted nonce = 0x12d97ad7
[ztex:0:0  ]   invalid nonce: 0x03119b94
[ztex:0:0  ] signcrypting 421435bde849e45281779ddfc484cf3a12f97f615b9a2ac11aadb37aecdf92cb:4141b93d4fea430a1a09b78a
[ztex:0:0  ] loading job  421435bde849e45281779ddfc484cf3a12f97f615b9a2ac11aadb37aecdf92cb:4141b93d4fea430a1a09b78a
[ztex:0:1  ] signcrypting f3baefe83e1d6e8b63479522890c05c1cc38bce00ed11b3fec628ac39314ce91:e7a53b614fea433a1a09b78a
[ztex:0:1  ] loading job  f3baefe83e1d6e8b63479522890c05c1cc38bce00ed11b3fec628ac39314ce91:e7a53b614fea433a1a09b78a
[ztex:0:2  ] signcrypting 48669c1f2b1816e00776ed476208268790171a44d4a8f77be30b3c43d3aad7b1:9c077ac54fea433a1a09b78a
[ztex:0:2  ] loading job  48669c1f2b1816e00776ed476208268790171a44d4a8f77be30b3c43d3aad7b1:9c077ac54fea433a1a09b78a
[ztex:0:1  ] decrypting nonce at address 0x00000001
[ztex:0:1  ]   encrypted nonce = 0xc15cdf8b
[ztex:0:1  ]   found a share: 0xe86b7df8
               server accepted solution
[ztex:0:0  ] decrypting nonce at address 0x0000005c
[ztex:0:0  ]   encrypted nonce = 0x7c8ad8ed
[ztex:0:0  ]   invalid nonce: 0xbcffec4f

most of it seems invalid  Undecided
I will ramp up the cooling for testing and try to lower clock iirc theres an option for that... also volt mod should prolly be made on these to run 3 rings high speeds...
BR0KK
hero member
Activity: 784
Merit: 500
Re: Algorithmically placed FPGA miner: 255MH/s/chip, supports all known boards
June 26, 2012, 05:52:30 PM
#511
power of the board, close jp1, power on and release jp1.


you should now be able to reprogram it correctly
kakobrekla
hero member
Activity: 714
Merit: 500
Psi laju, karavani prolaze.
Re: Algorithmically placed FPGA miner: 255MH/s/chip, supports all known boards
June 26, 2012, 05:03:52 PM
#510
Quote from: eldentyrell on June 25, 2012, 05:47:28 PM
Quote from: kakobrekla on June 25, 2012, 05:44:44 PM
Anyway after some debugging with jfsebastien, he said he has enough info to pass to you or we should reprogram eeprom to get it working, but im out of time for tonight.

Yes, thanks again for reporting this issue!

Here's the short story:

  1. Please use ZtexBTCMiner-120221.jar -- it is known to work.  Some of the newer versions might not.

  2. Apparently the TML only works if you have already programmed the "EEPROM" on your ztex board.  If it is blank, things won't work.  TML-0.92 will have a fix for this, but if you're in a hurry you can find the instructions here on ztex's website.  Any of his EEPROM images will work; it doesn't matter which one you use.

As a sanity check, try running the ztex miner in "cluster mode".  If that works, it means your EEPROM is programmed correctly.  Like I said, for 0.92 I'll figure out a way to avoid this being necessary.

Ok, so its like this....



Code:
java -cp FWLoader.jar FWLoader -ii
bus=001  device=10 (`010')  ID=221a:100
   Manufacturer="ZTEX"  Product="btcminer for ZTEX FPGA Modules"    SerialNumber="04A346E225"
   productID=10.0.1.1  fwVer=0  ifVer=1
   FPGA configured
   Capabilities:
      EEPROM read/write
      FPGA configuration
      High speed FPGA configuration
      MAC EEPROM read/write

but

Code:
java -cp FWLoader.jar FWLoader -uu ztex_ufm1_15d4.ix
Firmware upload time: 172 ms

and

Code:
java -cp FWLoader.jar FWLoader -ue ztex_ufm1_15d4.ihx
Firmware to EEPROM upload time: 2477 ms



yet

Code:
java -cp ZtexBTCMiner-120221.jar BTCMiner -m p -f ztex/java/ztex_ufm1_15d4.ihx
No devices found

but


Code:
 java -cp ZtexBTCMiner-120221.jar BTCMiner -m p -ps 04A346E225 -f ztex/java/ztex_ufm1_15d4.ihx

old: bus=002  device=34 (`034')  ID=221a:100
   Manufacturer="ZTEX"  Product="ucecho example for UFM 1.15"    SerialNumber="04A346E225"
   productID=10.13.0.0  fwVer=0  ifVer=1
   FPGA configured
Firmware upload time: 171 ms
EEPROM programming time: 2481 ms
new: bus=002  device=35 (`035')  ID=221a:100
   Manufacturer="ZTEX"  Product="btcminer for ZTEX FPGA Modules"    SerialNumber="04A346E225"
   productID=10.13.1.1  fwVer=0  ifVer=1
   FPGA configured

total amount of (re-)programmed devices: 1




but (cluster mode)

Code:
java -cp ZtexBTCMiner-120221.jar BTCMiner -host host -u username -p password -m c

(Re)Scanning bus ...
Error: Invalid BTCMiner descriptor version. Firmware must be updated.

Summary:
  Total         : 0 devices



and of course still

Code:
[ztex:0    ] programming FPGA
[ztex:0    ]   done programming FPGA
Exception in thread "main" java.io.IOException: TML acknowledgement of read operation failed; expected=0x1 got=0xffffffff
        at com.triconemining.board.MiningChip.read(MiningChip.java:50)
        at com.triconemining.bitcoin.miner.Miner.checkMagicNumber(Miner.java:118)
        at com.triconemining.bitcoin.miner.Miner.(Miner.java:33)
        at com.triconemining.bitcoin.miner.Main$1.(Main.java:222)
        at com.triconemining.bitcoin.miner.Main.main(Main.java:222)

grr.
eldentyrell
donator
Activity: 980
Merit: 1004
felonious vagrancy, personified
Re: Algorithmically placed FPGA miner: 255MH/s/chip, supports all known boards
June 25, 2012, 05:47:28 PM
#509
Quote from: kakobrekla on June 25, 2012, 05:44:44 PM
Anyway after some debugging with jfsebastien, he said he has enough info to pass to you or we should reprogram eeprom to get it working, but im out of time for tonight.

Yes, thanks again for reporting this issue!

Here's the short story:

  1. Please use ZtexBTCMiner-120221.jar -- it is known to work.  Some of the newer versions might not.

  2. Apparently the TML only works if you have already programmed the "EEPROM" on your ztex board.  If it is blank, things won't work.  TML-0.92 will have a fix for this, but if you're in a hurry you can find the instructions here on ztex's website.  Any of his EEPROM images will work; it doesn't matter which one you use.

As a sanity check, try running the ztex miner in "cluster mode".  If that works, it means your EEPROM is programmed correctly.  Like I said, for 0.92 I'll figure out a way to avoid this being necessary.
kakobrekla
hero member
Activity: 714
Merit: 500
Psi laju, karavani prolaze.
Re: Algorithmically placed FPGA miner: 255MH/s/chip, supports all known boards
June 25, 2012, 05:44:44 PM
#508
Yup its a single board chip. The unplugging and such didn't help.

Anyway after some debugging with jfsebastien, he said he has enough info to pass to you or we should reprogram eeprom to get it working, but im out of time for tonight.
eldentyrell
donator
Activity: 980
Merit: 1004
felonious vagrancy, personified
Re: Algorithmically placed FPGA miner: 255MH/s/chip, supports all known boards
June 25, 2012, 05:11:36 PM
#507
Hi kakobrekla, thanks for helping beta-test!

Quote from: kakobrekla on June 25, 2012, 02:51:11 PM
Code:
[ztex:0    ] programming FPGA
[ztex:0    ]   done programming FPGA
Exception in thread "main" java.io.IOException: TML acknowledgement of read operation failed; expected=0x1 got=0xffffffff

Are you sure you're using a 1.15x board?  What you're seeing is that the TML is able to program the chip, but is then unable to talk to it.  The only place I've seen this is when the board is a ztex board but not a 1.15x.  Are you sure you aren't using a 1.15y?


Code:
 java -Xbootclasspath/a:ZtexBTCMiner-120221.jar -jar tml-0.91.jar ztex:0 http://test:test@host
Caused by: java.lang.IndexOutOfBoundsException: Device number out of range. Valid numbers are 0..-1
        at ztex.ZtexScanBus1.device(ZtexScanBus1.java:174)
        ... 8 more

I've seen this a twice myself; what's going on here is that Ztex's java code can't find the board; when it says "valid numbers are 0..-1" it really means "I don't see any ztex boards"; it's a bug in ztex's USB implementation.  The only way to fix it is to unplug the board's USB connector and plug it back in.  Fortunately it doesn't happen very often.  I think the workaround is to specify the board by serial-number instead of by device-number; I'll try to implement that.
kakobrekla
hero member
Activity: 714
Merit: 500
Psi laju, karavani prolaze.
Re: Algorithmically placed FPGA miner: 255MH/s/chip, supports all known boards
June 25, 2012, 02:51:11 PM
#506
Quote from: roomservice on June 25, 2012, 02:47:22 PM
Quote from: kakobrekla on June 25, 2012, 02:29:37 PM
Code:
 java -Xbootclasspath/a:ZTexBTCMiner-120417.jar -jar tml-0.91.jar ztex:0 http://test:test@host
Exception in thread "main" java.lang.ExceptionInInitializerError
Caused by: java.lang.RuntimeException: unable to reflect on Ztex code; make sure you add -Xbootclasspath/a:ZtexBTCMiner-XXXX.jar to the command line!

ZTexBTCMiner-120417.jar  being in same folder. Runing debian.

Thoughts about my silliness?

I'm also waiting for jfsebastien on #tml-support (irc.tricone-mining.com) to hopefully assist.

Looks like a typo.

Try

java -Xbootclasspath/a:ZtexBTCMiner-120417.jar -jar tml-0.91.jar ztex:0 http://test:test@host

Wow indeed was a typo, thanks, but I didn't get much further for some reason.


Fixed another typo. Lets see now.

While board had old bitstream installed:

Code:
[ztex:0    ] programming FPGA
[ztex:0    ]   done programming FPGA
Exception in thread "main" java.io.IOException: TML acknowledgement of read operation failed; expected=0x1 got=0xffffffff
        at com.triconemining.board.MiningChip.read(MiningChip.java:50)
        at com.triconemining.bitcoin.miner.Miner.checkMagicNumber(Miner.java:118)
        at com.triconemining.bitcoin.miner.Miner.(Miner.java:33)
        at com.triconemining.bitcoin.miner.Main$1.(Main.java:222)
        at com.triconemining.bitcoin.miner.Main.main(Main.java:222)

after resetting the board:

Code:
 java -Xbootclasspath/a:ZtexBTCMiner-120221.jar -jar tml-0.91.jar ztex:0 http://test:test@host
_________________________________________________________________________
Tricone Mining Logic, host software v0.9

        ** THIS IS A PRE-RELEASE.  NOT FOR PRODUCTION USE **

   Eldentyrell will declare this codebase ready for production use
   once he has converted his own mine to use it (yes, he pays himself
   commissions).  Until then, performance and signcryption server
   uptime are likely to be erratic.

   Here is a partial list of issues you should be aware of:

     - many kinds of errors (network, etc) cause the miner to get stuck
     - only one of the signcryption frontends is contacted
     - clock-rate adjustment is 100% manual, not automatic
     - no overheat protection >>MAKE SURE YOU HAVE A HEATSINK INSTALLED<<


   ******************************************************************
   *                                                                *
   *               IF YOU EXPERIENCE HIGH ERROR RATES:              *
   *                                                                *
   *  Try running just one ring at a time (e.g. use 'ztex:0:0' on   *
   *  command line instead of 'ztex:0').  If each ring works error  *
   *  free on its own, but you get errors when running all three,   *
   *  it means your power supply is sagging.                        *
   *                                                                *
   ******************************************************************

Exception in thread "main" java.lang.RuntimeException: unable to reflect on Ztex code; make sure you add -Xbootclasspath/a:ZtexBTCMiner-XXXX.jar to the command line!
        at com.triconemining.board.Ztex$ZtexChip.(Ztex.java:116)
        at com.triconemining.board.Ztex$ZtexBoard.(Ztex.java:67)
        at com.triconemining.board.Ztex.getBoard(Ztex.java:39)
        at com.triconemining.bitcoin.miner.Main.main(Main.java:221)
Caused by: java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:601)
        at com.triconemining.board.Ztex$ZtexChip.(Ztex.java:97)
        ... 3 more
Caused by: java.lang.IndexOutOfBoundsException: Device number out of range. Valid numbers are 0..-1
        at ztex.ZtexScanBus1.device(ZtexScanBus1.java:174)
        ... 8 more



after further testing... this seems to be it. If I run ztex miner first and then tml it breaks after fw uploading, uploading to a reseted board, doesn't come even that far.

back to ztex
roomservice
full member
Activity: 199
Merit: 100
Re: Algorithmically placed FPGA miner: 255MH/s/chip, supports all known boards
June 25, 2012, 02:47:22 PM
#505
Quote from: kakobrekla on June 25, 2012, 02:29:37 PM
Code:
 java -Xbootclasspath/a:ZTexBTCMiner-120417.jar -jar tml-0.91.jar ztex:0 http://test:test@host
Exception in thread "main" java.lang.ExceptionInInitializerError
Caused by: java.lang.RuntimeException: unable to reflect on Ztex code; make sure you add -Xbootclasspath/a:ZtexBTCMiner-XXXX.jar to the command line!

ZTexBTCMiner-120417.jar  being in same folder. Runing debian.

Thoughts about my silliness?

I'm also waiting for jfsebastien on #tml-support (irc.tricone-mining.com) to hopefully assist.

Looks like a typo.

Try

java -Xbootclasspath/a:ZtexBTCMiner-120417.jar -jar tml-0.91.jar ztex:0 http://test:test@host
kakobrekla
hero member
Activity: 714
Merit: 500
Psi laju, karavani prolaze.
Re: Algorithmically placed FPGA miner: 255MH/s/chip, supports all known boards
June 25, 2012, 02:29:37 PM
#504
Code:
 java -Xbootclasspath/a:ZTexBTCMiner-120417.jar -jar tml-0.91.jar ztex:0 http://test:test@host
Exception in thread "main" java.lang.ExceptionInInitializerError
Caused by: java.lang.RuntimeException: unable to reflect on Ztex code; make sure you add -Xbootclasspath/a:ZtexBTCMiner-XXXX.jar to the command line!

ZTexBTCMiner-120417.jar  being in same folder. Runing debian.

Thoughts about my silliness?

I'm also waiting for jfsebastien on #tml-support (irc.tricone-mining.com) to hopefully assist.
eldentyrell
donator
Activity: 980
Merit: 1004
felonious vagrancy, personified
Re: Algorithmically placed FPGA miner: 255MH/s/chip, supports all known boards
June 24, 2012, 05:06:38 PM
#503
Quote from: roomservice on June 24, 2012, 04:58:01 AM
Quote from: eldentyrell on June 23, 2012, 06:35:23 PM
Quote from: roomservice on June 23, 2012, 01:26:06 AM
http://pastebin.com/61iDAAHS

… ztex:20 …

I see Smiley

My host has currently 20 Ztex 1.15x and 3 1.15y connected.

You know that the board numbers start from zero, so if your 20 1.15x boards come first they are ztex:0..ztex:19.  There's a very good chance that you were trying to run the TML on your lowest-numbered 1.15y board.  This would definitely cause the sort of error you observed: the FPGA programs correctly but the ztex cypress chip craps all over the place.

This is why I suggest that people start with the simplest setup possible: one machine, one board, one chip.
Pages:
Bitcoin Forum>Bitcoin>Mining>Hardware
Jump to: