|
1041
|
Bitcoin / Hardware / Re: Algorithmically placed FPGA miner: 245MH/s/chip and still rising
|
on: July 20, 2012, 08:06:26 AM
|
It has already been ported. That board has been fully supported for several days now. - e eldentyrell, maybe I'm missing something, but my tests and tests from other users (see previous messages) all end up with an IOException and without hashing a single share. Do you have any hint on what I'm doing wrong? spiccioli |
|
|
|
|
1043
|
Alternate cryptocurrencies / Mining (Altcoins) / Re: Quad XC6SLX150 Board - Initial Price £400/$640/520€
|
on: July 19, 2012, 12:49:51 PM
|
After nearly one week of hashing I've got a stuck FPGA, controller rev. 1.3, ICA 7 is stuck, no more increasing A: and a slowly decreasing U:. I'm offsite, right now, so I can't see leds. ICA 9, while slower than the others, is still hashing. cgminer version 2.4.3 - Started: [2012-07-13 07:26:50]
--------------------------------------------------------------------------------
(5s):8053.2 (avg):7381.1 Mh/s | Q:1251980 A:461192 R:463 HW:0 E:37% U:50.8/m
TQ: 20 ST: 21 SS: 12 DW: 16222 NB: 985 LW: 1059 GF: 794 RF: 6
Connected to http://pool.abcpool.co with LP as user ....
Block: 000006b34a33513bc9eb387c3868ad63... Started: [14:36:38]
--------------------------------------------------------------------------------
[P]ool management [S]ettings [D]isplay options [Q]uit
ICA 0: | 379.7/369.0Mh/s | A:23785 R:25 HW:0 U: 2.62/m
ICA 1: | 379.9/369.2Mh/s | A:21985 R:21 HW:0 U: 2.42/m
ICA 2: | 379.9/369.3Mh/s | A:23616 R:25 HW:0 U: 2.60/m
ICA 3: | 379.9/369.1Mh/s | A:22531 R:24 HW:0 U: 2.48/m
ICA 4: | 379.9/369.1Mh/s | A:23555 R:20 HW:0 U: 2.60/m
ICA 5: | 379.9/369.2Mh/s | A:23276 R:18 HW:0 U: 2.56/m
ICA 6: | 379.8/368.9Mh/s | A:23412 R:18 HW:0 U: 2.58/m
ICA 7: | 380.0/368.8Mh/s | A:19404 R:25 HW:0 U: 2.14/m
ICA 8: | 380.0/369.1Mh/s | A:23357 R:27 HW:0 U: 2.57/m
ICA 9: | 379.9/369.0Mh/s | A:20225 R:20 HW:0 U: 2.23/m
ICA 10: | 379.9/369.1Mh/s | A:23369 R:28 HW:0 U: 2.58/m
ICA 11: | 379.8/369.0Mh/s | A:23479 R:18 HW:0 U: 2.59/m
ICA 12: | 379.8/369.1Mh/s | A:23569 R:23 HW:0 U: 2.60/m
ICA 13: | 379.8/369.1Mh/s | A:23568 R:24 HW:0 U: 2.60/m
ICA 14: | 379.8/368.9Mh/s | A:23718 R:26 HW:0 U: 2.61/m
ICA 15: | 379.8/369.1Mh/s | A:23572 R:22 HW:0 U: 2.60/m
ICA 16: | 379.9/369.1Mh/s | A:23605 R:21 HW:0 U: 2.60/m
ICA 17: | 379.9/369.1Mh/s | A:23636 R:23 HW:0 U: 2.60/m
ICA 18: | 379.9/369.0Mh/s | A:23864 R:28 HW:0 U: 2.63/m
ICA 19: | 379.9/369.1Mh/s | A:23667 R:27 HW:0 U: 2.61/m
--------------------------------------------------------------------------------
[2012-07-19 14:42:27] Accepted db79cec0.6baf9979 ICA 15 pool 0
[2012-07-19 14:42:27] Accepted ed056591.9f6352fb ICA 11 pool 0
[2012-07-19 14:42:28] Accepted 450ac3a5.68c071a5 ICA 10 pool 0
[2012-07-19 14:42:29] Accepted 2da3d070.81b5abfa ICA 0 pool 0
[2012-07-19 14:42:31] Accepted cf2cae0d.324cfbb1 ICA 3 pool 0
[2012-07-19 14:42:31] Accepted e581471c.2e5f3f08 ICA 0 pool 0
[2012-07-19 14:42:34] Accepted 136bbf74.b7345085 ICA 2 pool 0
[2012-07-19 14:42:37] Accepted c1997113.91085fe7 ICA 3 pool 0
[2012-07-19 14:42:37] Accepted 378bec29.4aa35877 ICA 9 pool 0
[2012-07-19 14:42:38] Accepted 14bad6b8.19cfc4e0 ICA 5 pool 0
[2012-07-19 14:42:41] Accepted 9baa0cb9.6eb66538 ICA 12 pool 0
spiccioli. |
|
|
|
|
1046
|
Alternate cryptocurrencies / Mining (Altcoins) / Re: Quad XC6SLX150 Board - Initial Price £400/$640/520€
|
on: July 16, 2012, 05:50:51 PM
|
Possible CGminer Bug
We have got an intermittant internet today and we are having short periods when basically data isn't pass and we get timeouts. We have seen that in our big mining test reg, running on the same internet connection, that after such an outage that CGminer (V2.3.4) appears to stop scheduling work correctly to some or all of the stack of boards. It does continue to intermittantly schedule work and is not a total stoppage but hash rates appear to fall to less that half that expected. This does appear to be a problem that a number of rig, and in particularly the bigger ones, are reporting. Once this happens there doen't seen to be any way to recover CGminer other than a complete restart.
Yohan, you're using an "old" version of cgminer, please build one of the lastest 2.4.x or even 2.5.0 (I'm not sure 2.5.0 is as stable as 2.4.x) but 2.4.3 as a minimum version. See also https://bitcointalk.org/index.php?topic=78239.msg968533#msg968533I'm using 2.4.3 (though on linux and with not so many boards) and I've never had the problem you're reporting. spiccioli |
|
|
|
|
1047
|
Alternate cryptocurrencies / Mining (Altcoins) / Re: Quad XC6SLX150 Board - Initial Price £400/$640/520€
|
on: July 16, 2012, 06:07:40 AM
|
We have made the pricing change based on the availability of eldentyrell's bitstream being available, at close to the rate he has been promising, and we believe that is running in several Cairnsmore1 boards. We said this would happen no matter where a
I add myself to the list of people that did try the ET bitstream and did find that it does not work on my cm1 boards. spiccioli |
|
|
|
|
1048
|
Alternate cryptocurrencies / Mining (Altcoins) / Re: Quad XC6SLX150 Board - Initial Price £400/$640/520€
|
on: July 13, 2012, 08:03:13 PM
|
We have started modelling a mid size mining rig so that we can firstly test boards exactly the way Bitcoiners use them but also so we can see some of the system level problems that some of you get. This is an additional test to our normal testing and we aiming put all line boards through that test. At the moment it's windows based but we will probably run a second rig on LInux as well. We have a few observations about using USB which may help you all get running. First observation is that powering the 12V first befor plugging in USB is good way to do it. Our second observation was using a cheap 13 way USB hub we bought to test http://www.ebuyer.com/279682-xenta-13-port-usb2-0-hub-mains-powered-n-uh1301 if we switch off using the switch on the hub until the 12V is up and settled gave good results. Third observation is that our 20-30 unit test rig took 10-20 minutes to enumerate the USB structure and if you try tio do anything before that is complete one or more boards will get screwed up and you can not do anything to get it back short of doing the entire start up sequence again. Out of what we saw today we have a couple of ideas to add to the Controller that may help stability with the twin bitstream and we will try those over the next couple of days. If they are of benefit a release of Controller will follow. Yohan, given that boards can be switched on without any usb cable attached is it possible to have the controller FPGA not require/take power from usb cable? spiccioli |
|
|
|
|
1049
|
Alternate cryptocurrencies / Mining (Altcoins) / Re: Quad XC6SLX150 Board - Initial Price £400/$640/520€
|
on: July 13, 2012, 07:56:36 PM
|
Thank you for the info  Seems like your setup is quite similar to mine though (I don't think using the Raspberry Pi should affect anything, but maybe I'm wrong). I'll try using a few different USB cables tomorrow or something. Norulezapply, what is your U: number after a few hours on mining? If your usb hub is not powered I'd try a powered one first. spiccioli I have a powered USB hub. Here's a "screenshot" from my rig after ~20 hours: cgminer version 2.4.3 - Started: [2012-07-13 00:43:11]
--------------------------------------------------------------------------------
(5s):1676.7 (avg):1491.3 Mh/s | Q:6826 A:7881 R:1 HW:0 E:115% U:6.6/m
TQ: 4 ST: 5 SS: 0 DW: 1037 NB: 143 LW: 30811 GF: 0 RF: 0
Connected to ozco.in with LP as user snip
Block: 000007ce5cd122fcfd0163d16d5c742d... Started: [20:21:18]
--------------------------------------------------------------------------------
[P]ool management [S]ettings [D]isplay options [Q]uit
ICA 0: | 379.9/373.0Mh/s | A:1383 R:0 HW:0 U: 1.16/m
ICA 1: | 379.9/372.6Mh/s | A:1252 R:0 HW:0 U: 1.05/m
ICA 2: | 380.0/373.0Mh/s | A:2624 R:0 HW:0 U: 2.21/m
ICA 3: | 379.8/372.8Mh/s | A:2622 R:1 HW:0 U: 2.21/m
--------------------------------------------------------------------------------
[2012-07-13 20:30:27] Accepted fadb8f39.9ae9fafc ICA 3
[2012-07-13 20:30:28] Accepted d9c24b95.8e05a5fe ICA 1
[2012-07-13 20:30:29] Accepted cd961974.b4c4ca52 ICA 3
[2012-07-13 20:30:47] Accepted b8a4f7f6.46f1c8a1 ICA 3
[2012-07-13 20:30:48] Accepted 63c28bba.b8d6352f ICA 2
[2012-07-13 20:31:05] Accepted 526d5521.fd5beeb7 ICA 0
[2012-07-13 20:31:24] Accepted 28843c4c.7492b005 ICA 3
[2012-07-13 20:31:33] Accepted e1658fd4.fffd4e2d ICA 3
[2012-07-13 20:31:37] Accepted d2409553.dee9a890 ICA 1
[2012-07-13 20:32:04] Accepted 3a072287.dcd450a3 ICA 3
As you can see, ICA 0/1 is running approximately half the speed of ICA2/3. The lights on the suspect board are orange for a large majority of the time, where as the other board is rarely ever orange. At first I thought it could help if I ran two separate instances of cgminer but I haven't tried this yet. Regards Norulez, I don't think running two instances of cgminer will give you more speed, the fact that the orange led is mostly ON means that FPGAs aren't hashing (when you power them you should have FPGA0/3 yellow/orange led on and FPGA1/2 yellow and red leds on). Are you sure that board hosting ICA 0/1 has SW6/1 off? (115Kbaud virtual com port speed). See http://www.enterpoint.co.uk/cairnsmore/cairnsmore1_support_materials.html image labeled "TWIN BUILD (ICARUS) RUNNING DIP SETTINGS" Did you try to reflash twin_test on it? spiccioli |
|
|
|
|
1050
|
Alternate cryptocurrencies / Mining (Altcoins) / Re: Quad XC6SLX150 Board - Initial Price £400/$640/520€
|
on: July 13, 2012, 07:25:18 PM
|
Thank you for the info Seems like your setup is quite similar to mine though (I don't think using the Raspberry Pi should affect anything, but maybe I'm wrong). I'll try using a few different USB cables tomorrow or something. Norulezapply, what is your U: number after a few hours on mining? If your usb hub is not powered I'd try a powered one first. spiccioli |
|
|
|
|
1051
|
Alternate cryptocurrencies / Mining (Altcoins) / Re: Quad XC6SLX150 Board - Initial Price £400/$640/520€
|
on: July 13, 2012, 07:16:18 PM
|
Can someone with multiple boards please give me some help with getting both of mine upto speed?
I have 2 and occassionally I get them up to a total of ~710Mh/s, but most of the time I'm only getting ~520Mh/s average total (so that's 260Mh/s per board).
Hard to say (at least for me), norulezapply, since you're using a rather "uncommon" platform to mine (raspberry). Anyway, in my experience, the only difference is in the controller FPGA firmware, 1.3 seems better in achieving an uniform U: across all boards (but you already have it). Here are mine cgminer version 2.4.3 - Started: [2012-07-13 07:26:50]
--------------------------------------------------------------------------------
(5s):7513.4 (avg):7328.9 Mh/s | Q:114056 A:41757 R:40 HW:0 E:37% U:50.9/m
TQ: 20 ST: 22 SS: 2 DW: 2324 NB: 107 LW: 311 GF: 90 RF: 1
Connected to http://pool.abcpool.co with LP as user .......
Block: 0000012b95cd60eeffec7427a809b285... Started: [21:02:32]
--------------------------------------------------------------------------------
[P]ool management [S]ettings [D]isplay options [Q]uit
ICA 0: | 379.8/366.8Mh/s | A:2120 R:3 HW:0 U: 2.59/m
ICA 1: | 379.8/366.5Mh/s | A:1976 R:1 HW:0 U: 2.41/m
ICA 2: | 379.9/367.1Mh/s | A:2114 R:2 HW:0 U: 2.58/m
ICA 3: | 379.9/366.7Mh/s | A:2013 R:3 HW:0 U: 2.46/m
ICA 4: | 379.9/366.6Mh/s | A:2108 R:4 HW:0 U: 2.57/m
ICA 5: | 380.0/366.7Mh/s | A:2092 R:1 HW:0 U: 2.55/m
ICA 6: | 379.9/366.2Mh/s | A:2172 R:0 HW:0 U: 2.65/m
ICA 7: | 379.9/366.1Mh/s | A:2139 R:2 HW:0 U: 2.61/m
ICA 8: | 379.8/366.1Mh/s | A:2080 R:1 HW:0 U: 2.54/m
ICA 9: | 379.8/366.4Mh/s | A:1848 R:2 HW:0 U: 2.25/m
ICA 10: | 379.9/365.9Mh/s | A:2092 R:3 HW:0 U: 2.55/m
ICA 11: | 379.8/366.1Mh/s | A:2100 R:5 HW:0 U: 2.56/m
ICA 12: | 379.9/366.4Mh/s | A:2079 R:1 HW:0 U: 2.54/m
ICA 13: | 379.9/366.2Mh/s | A:2192 R:3 HW:0 U: 2.67/m
ICA 14: | 379.7/366.0Mh/s | A:2016 R:3 HW:0 U: 2.46/m
ICA 15: | 379.9/366.8Mh/s | A:2109 R:0 HW:0 U: 2.57/m
ICA 16: | 379.8/366.4Mh/s | A:2141 R:1 HW:0 U: 2.61/m
ICA 17: | 379.8/367.4Mh/s | A:2128 R:0 HW:0 U: 2.60/m
ICA 18: | 379.9/366.2Mh/s | A:2149 R:3 HW:0 U: 2.62/m
ICA 19: | 379.9/366.9Mh/s | A:2090 R:2 HW:0 U: 2.55/m
--------------------------------------------------------------------------------
As you can see I've got a U: around 2.30-2.60, I'm using cgminer 2.4.3 as well on an ubuntu low power pc. Note that I have a FPGA which is underperforming the others (it is ICA 9 here) and which has always underperformed no matter what controller revision I was using. I'm starting cgminer like this ./cgminer -S /dev/ttyUSB2 -S /dev/ttyUSB3 -S /dev/ttyUSB6 -S /dev/ttyUSB7 -S /dev/ttyUSB10 -S /dev/ttyUSB11 -S /dev/ttyUSB14 -S /dev/ttyUSB15 -S /dev/ttyUSB18 -S /dev/ttyUSB19 -S /dev/ttyUSB22 -S /dev/ttyUSB23 -S /dev/ttyUSB26 -S /dev/ttyUSB27 -S /dev/ttyUSB30 -S /dev/ttyUSB31 -S /dev/ttyUSB34 -S /dev/ttyUSB35 -S /dev/ttyUSB38 -S /dev/ttyUSB39 -o http://pool.abcpool.co -O ...... -o http://p2pool.soon.it:9332 -O ..... -Q 20 --failover-only
spiccioli.
edit: is your usb hub powered or unpowered? |
|
|
|
|
1052
|
Alternate cryptocurrencies / Mining (Altcoins) / Re: Quad XC6SLX150 Board - Initial Price £400/$640/520€
|
on: July 13, 2012, 10:02:00 AM
|
BTW, Yohan, a linux SPIProg would make flashing a few boards a lot faster, now I need to detach/attach usb cable from/to boards and windows laptop I use to flash them.
Which Windows version are you using? I found some old laptop with XP Professional on it and every time I plug a different CM1 it re-installs the FTDI drivers. Takes some minutes for each board to flash (need to accept non-signed drivers each time) - really annoying  The process for programming the SPI Flash is very slow. Expect 30-40 minutes per board. We do have a plan to include parallel programming of the array and this will make an obvious time saving expecially if we can make it work over multiple boards at the same time. For this to happen it needs our own bitstream so we can add some necessary support features. We have been using Win7 and XP here. What? 30 minutes per board to flash controller FPGA? On my vista 32 laptop it takes 30 SECONDS to flash it?!? spiccioli SPI flash is slow but controller takes like 15-30 seconds. Might be talking at cross purposes here. Array FPGAs take the 30-40 mins to do the SPI Flash. Controller is very fast and less than a minute to do it's internal SPI Flash. Yes, we were talking about different things here, but in any case flashing permanently FPGAs 0/3 from a linux pc is three times faster than doing the same from inside virtualbox, so if someone here has a lot of boards it makes a substantial difference in the time it takes to reprogram them all. Anyway, this morning I was going to flash my boards back to rev 1.2 when I decided to restart the host pc for the twentieth time just to see what serial connections were going to fail this morning and... surprise, it found all FPGAs and they are now all hashing again... I really don't know why the previous nineteen times it was not working properly (yesterday I've restarted boards, power supplies, usb hubs in every conceivable combination... go figure). spiccioli |
|
|
|
|
1053
|
Alternate cryptocurrencies / Mining (Altcoins) / Re: Quad XC6SLX150 Board - Initial Price £400/$640/520€
|
on: July 12, 2012, 11:12:57 PM
|
BTW, Yohan, a linux SPIProg would make flashing a few boards a lot faster, now I need to detach/attach usb cable from/to boards and windows laptop I use to flash them.
Which Windows version are you using? I found some old laptop with XP Professional on it and every time I plug a different CM1 it re-installs the FTDI drivers. Takes some minutes for each board to flash (need to accept non-signed drivers each time) - really annoying Zefir, vista 32 bit. spiccioli |
|
|
|
|
1054
|
Alternate cryptocurrencies / Mining (Altcoins) / Re: Quad XC6SLX150 Board - Initial Price £400/$640/520€
|
on: July 12, 2012, 11:11:35 PM
|
BTW, Yohan, a linux SPIProg would make flashing a few boards a lot faster, now I need to detach/attach usb cable from/to boards and windows laptop I use to flash them.
Which Windows version are you using? I found some old laptop with XP Professional on it and every time I plug a different CM1 it re-installs the FTDI drivers. Takes some minutes for each board to flash (need to accept non-signed drivers each time) - really annoying The process for programming the SPI Flash is very slow. Expect 30-40 minutes per board. We do have a plan to include parallel programming of the array and this will make an obvious time saving expecially if we can make it work over multiple boards at the same time. For this to happen it needs our own bitstream so we can add some necessary support features. We have been using Win7 and XP here. What? 30 minutes per board to flash controller FPGA? On my vista 32 laptop it takes 30 SECONDS to flash it?!? spiccioli |
|
|
|
|
1055
|
Alternate cryptocurrencies / Mining (Altcoins) / Re: Quad XC6SLX150 Board - Initial Price £400/$640/520€
|
on: July 12, 2012, 06:35:59 PM
|
i did 6 boards, now the red light is blinking faster, that is, after i have done,, and changed the dip switched to the twin_test dips, is that normal?
yes spiccioli BTW, Yohan, a linux SPIProg would make flashing a few boards a lot faster, now I need to detach/attach usb cable from/to boards and windows laptop I use to flash them. spiccioli. |
|
|
|
|
1057
|
Alternate cryptocurrencies / Mining (Altcoins) / Re: Quad XC6SLX150 Board - Initial Price £400/$640/520€
|
on: July 12, 2012, 06:07:43 PM
|
As part of our work on Rev 1.3 of the controller we found an unusual "feature" and is was related to a cheap USB hub we are using in one of system test setups. What we found was that this hub didn't turn power off properly when the host laptop released the port as it should. Indirectly this was causing a lockup of the array FPGAs. We have added an extra reset function to clock startup and this appears to solve the issue.
On our test setups we are now getting a good balance of hashing now on both FPGAs running the twin bitstream so I would recommend anyone with a controller on Rev 1.0/1.1 updates it to Rev 1.3.
Yohan, I've flashed all my boards to 1.3, now I'm getting [2012-07-12 19:43:44] Icarus Detect: Test failed at /dev/ttyUSB2: get 00000000, should: 000187a2
[2012-07-12 19:43:44] Icarus Detect: Test failed at /dev/ttyUSB3: get 00000000, should: 000187a2
port numbers are nearly random, sometimes it's ttyUSB26/27, sometimes just a FPGA out of a couple like ttyUSB15 right now. ttyUSB2/3 fail nearly always. Is the new revision requiring more power from the USB port? I'm on two usb hubs, a 2.5A 7 port hub and a 2.5A 4 port hub from Belkin for my ten boards. spiccioli Can it be a timining issue? After a dozen restarts, ttyUSB2/3 are now OK (three restarts and no problem on them), but ttyUSB14 fails... spiccioli edit: linux ubuntu 12.04 64 bit, cgminer 2.4.3 32 bit, twin_test.bit on all FPGAs (0/3) in permanent mode. This system has been hashing for more than 10 days without problems on controller 1.1 and last two days on 1.2. |
|
|
|
|
1058
|
Alternate cryptocurrencies / Mining (Altcoins) / Re: Quad XC6SLX150 Board - Initial Price £400/$640/520€
|
on: July 12, 2012, 05:49:05 PM
|
As part of our work on Rev 1.3 of the controller we found an unusual "feature" and is was related to a cheap USB hub we are using in one of system test setups. What we found was that this hub didn't turn power off properly when the host laptop released the port as it should. Indirectly this was causing a lockup of the array FPGAs. We have added an extra reset function to clock startup and this appears to solve the issue.
On our test setups we are now getting a good balance of hashing now on both FPGAs running the twin bitstream so I would recommend anyone with a controller on Rev 1.0/1.1 updates it to Rev 1.3.
Yohan, I've flashed all my boards to 1.3, now I'm getting [2012-07-12 19:43:44] Icarus Detect: Test failed at /dev/ttyUSB2: get 00000000, should: 000187a2
[2012-07-12 19:43:44] Icarus Detect: Test failed at /dev/ttyUSB3: get 00000000, should: 000187a2
port numbers are nearly random, sometimes it's ttyUSB26/27, sometimes just a FPGA out of a couple like ttyUSB15 right now. ttyUSB2/3 fail nearly always. Is the new revision requiring more power from the USB port? I'm on two usb hubs, a 2.5A 7 port hub and a 2.5A 4 port hub from Belkin for my ten boards. spiccioli |
|
|
|
|
1059
|
Bitcoin / Hardware / Re: Algorithmically placed FPGA miner: 245MH/s/chip and still rising
|
on: July 12, 2012, 02:55:46 PM
|
Hi, following ebereon's steps, I have programmed FPGA3 on my cairnsmore1 board serial 0008, controller rev. 1.2, with tml-davis.bit from latest version available on tricone-mining. I've programmed it as a not permanent bitstream. Then I've attached this board to my vista laptop and started it as java -jar tml-0.999mod.jar urjtag:FT2232 http://user:pw@pool.abcpool.co:8332/
I'm using latest available java java -version
java version "1.7.0_05"
Java(TM) SE Runtime Environment (build 1.7.0_05-b05)
Java HotSpot(TM) Client VM (build 23.1-b03, mixed mode, sharing)
And this is what I get
******************************************************************
* *
* 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. *
* *
******************************************************************
[urjtag:0:0] programming FPGA
USERCODE before bitstream upload: 0xcafebabe
USERCODE after bitstream upload: 0xcafebabe
[urjtag:0:0] done programming FPGA
[urjtag:0:0] magic number check ok
[urjtag:0:0] chip is running bitstream version davis, built 8 days, 9 hours ago
[urjtag:0:0] design is intended for input clock frequency of 48 Mhz
[urjtag:0:0] measuring clock frequency at ztex pin (csg484.L22)
[urjtag:0:0] measured input clock frequency at 0 Mhz
[urjtag:0:0] measuring clock frequency at nexus6/x6500 pin (fgg484.K20)
[urjtag:0:0] measured input clock frequency at 0 Mhz
[urjtag:0:0] measuring clock frequency at icarus/carinsmore pin (fgg484.J1)
[urjtag:0:0] measured input clock frequency at 66 Mhz
[urjtag:0:0] assuming input clock frequency of 48 Mhz
[urjtag:0:0] chip has 3 rings
[urjtag:0:0:0] opening signcryption channel
[urjtag:0:0:0] setting clock to 157 Mhz, mult=23 div=7
[urjtag:0:0:0] ramping clock: mult=8 div=7
[urjtag:0:0:0] ramping clock: mult=9 div=7
[urjtag:0:0:0] ramping clock: mult=10 div=7
Exception in thread "main" java.io.IOException: DCM PROGDONE did not go high aft
er programming
at com.triconemining.bitcoin.miner.DCM.setClockFrequency(DCM.java:173)
at com.triconemining.bitcoin.miner.DCM.setClockFrequency(DCM.java:86)
at com.triconemining.bitcoin.miner.Ring.setClockFrequency(Ring.java:278)
H:←[1m←[32m0←[0m←[0m/←[32m0←[0m X:0 C:0 E:←[1m←[31m0←[0m←[0m/←[31m0←[0m T:15m
| H:←[1m←[32m0←[0m←[0m/←[32m0←[0m E:←[1m←[31m0←[0m←[0m/←[31m0←[0m A:←[32m0←[0m
R:←[33m0←[0m T:1m8s
at com.triconemining.bitcoin.miner.Miner.enableRing(Miner.java:190)
at com.triconemining.bitcoin.miner.Miner.enableRing(Miner.java:121)
at com.triconemining.bitcoin.miner.Main.main(Main.java:426)
[urjtag:0:0:0] setting clock to 5 Mhz, mult=5 div=48
H:←[1m←[32m0←[0m←[0m/←[32m0←[0m X:0 C:0 E:←[1m←[31m0←[0m←[0m/←[31m0←[0m T:15m
| H:←[1m←[32m0←[0m←[0m/←[32m0←[0m E:←[1m←[31m0←[0m←[0m/←[31m0←[0m A:←[32m0←[0m
[urjtag:0:0:0] ramping clock: mult=67 div=48
H:←[1m←[32m0←[0m←[0m/←[32m0←[0m X:0 C:0 E:←[1m←[31m0←[0m←[0m/←[31m0←[0m T:15m
| H:←[1m←[32m0←[0m←[0m/←[32m0←[0m E:←[1m←[31m0←[0m←[0m/←[31m0←[0m A:←[32m0←[0m
java.lang.RuntimeException: java.io.EOFException[urjtag:0:0:0] ramping clock
: mult=66 div=48
H:←[1m←[32m0←[0m←[0m/←[32m0←[0m X:0 C:0 E:←[1m←[31m0←[0m←[0m/←[31m0←[0m T:15m
| H:←[1m←[32m0←[0m←[0m/←[32m0←[0m E:←[1m←[31m0←[0m←[0m/←[31m0←[0m A:←[32m0←[0m
R:←[33m0←[0m T:1m8s at com.triconemining.limp.LimpConnection.run(LimpConnect
ion.java:53)
at java.lang.Thread.run(Unknown Source)
Caused by: java.io.EOFException
at com.triconemining.util.VarInt.read(VarInt.java:16)
at com.triconemining.limp.LimpConnection.run(LimpConnection.java:50)
... 1 more
[urjtag:0:0:0] ramping clock: mult=65 div=48
H:←[1m←[32m0←[0m←[0m/←[32m0←[0m X:0 C:0 E:←[1m←[31m0←[0m←[0m/←[31m0←[0m T:15m
| H:←[1m←[32m0←[0m←[0m/←[32m0←[0m E:←[1m←[31m0←[0m←[0m/←[31m0←[0m A:←[32m0←[0m
[urjtag:0:0:0] ramping clock: mult=64 div=48
H:←[1m←[32m0←[0m←[0m/←[32m0←[0m X:0 C:0 E:←[1m←[31m0←[0m←[0m/←[31m0←[0m T:15m
| H:←[1m←[32m0←[0m←[0m/←[32m0←[0m E:←[1m←[31m0←[0m←[0m/←[31m0←[0m A:←[32m0←[0m
[urjtag:0:0:0] ramping clock: mult=63 div=48
H:←[1m←[32m0←[0m←[0m/←[32m0←[0m X:0 C:0 E:←[1m←[31m0←[0m←[0m/←[31m0←[0m T:15m
| H:←[1m←[32m0←[0m←[0m/←[32m0←[0m E:←[1m←[31m0←[0m←[0m/←[31m0←[0m A:←[32m0←[0m
R:←[33m0←[0m T:1m8s java.io.IOException: TML acknowledgement of read operation f
ailed; expected=0x435 got=0xfffffde5
at com.triconemining.board.MiningChip.read(MiningChip.java:65)
at com.triconemining.bitcoin.miner.DCM.progDone(DCM.java:199)
at com.triconemining.bitcoin.miner.DCM.setClockFrequency(DCM.java:169)
at com.triconemining.bitcoin.miner.DCM.setClockFrequency(DCM.java:86)
at com.triconemining.bitcoin.miner.Ring.setClockFrequency(Ring.java:278)
at com.triconemining.bitcoin.miner.Main.run(Main.java:191)
at java.lang.Thread.run(Unknown Source)
So it seems to be talking with FPGA3 but then it dies with some IO exception. spiccioli |
|
|
|
|
1060
|
Alternate cryptocurrencies / Mining (Altcoins) / Re: Quad XC6SLX150 Board - Initial Price £400/$640/520€
|
on: July 08, 2012, 12:56:49 PM
|
Heya,
Just got my board up and running (using the twin_test.bit), on MPBM...
All seems to be working well... on com22 and com23 I have it running at 378/377 MH's respectively. The blockchain the total avg running at 755 MH's. (running for two and a half hours now).
My pool is only registering about 425HM's... no errors are showing up in the log however... no rejects.. and only 1.16% canceled.
Is this in line with best current performance?
Thanks in advance.
Yes, each FPGA mines at 190MH/s when using twin_test.bit and you're using just two of the four FPGAs on your board. Mpbm and cgminer report twice the real speed when used with default parameters. You can use --icarus-timing parameter on cgminer and/or ebereon cairnsmore worker for Mpbm to have a more precise reported speed, see messages in this thread starting from a couple of weeks ago. spiccioli. |
|
|
|
|
Show Posts
