zefir
Donator
Hero Member
Offline
Activity: 919
Merit: 1000
|
|
June 26, 2012, 09:46:52 PM |
|
... currently not available at Amazon. Plus need to get it to Switzerland -> ~2 weeks delivery time Best deal here would be to go to a local store and buy 8x7-port hubs for ~35$ each. Sad thing is, I prepared the up/down cables already and hoped to bring up all boards to life tomorrow without wasting money for the USB hubs - but thats life...
|
|
|
|
Isokivi
|
|
June 26, 2012, 10:09:51 PM |
|
190M_V3.bit is running @ 401Mh/s (1 hour average) on p2pool stats, so far so good.
I will post an update tomorrow.
Im about to get my boards later this week and it seems like your the who's reporting in with best numbers. Could you please specify what bitstream you are runnin running with what miner and what versions ? Thank you in advance.
|
Bitcoin trinkets now on my online store: btc trinkets.com <- Bitcoin Tiepins, cufflinks, lapel pins, keychains, card holders and challenge coins.
|
|
|
zefir
Donator
Hero Member
Offline
Activity: 919
Merit: 1000
|
|
June 26, 2012, 10:16:12 PM |
|
Short update (before I'm done for today): got three boards (serial# 126-128) programmed with the V3 bitstream (with eberon's howto) up and running. After around an hour the average hashrate reported by the pool is 1150 MHps, which is quite in line with 380 per board.
One important thing (lost track in the thread, might already been mentioned): do not run cgminer with automatic Icarus detection or with the script proposed by xiangfu to run all available FPGAs. Instead, do a dry run first to see which ttyUSB ports are assigned to the malfunction FPGAs (with Linux it depends on the order of how they are plugged into the hub) and then run cgminer with only the valid ttyUSB ports as parameters. Giving all ports to cgminer confuses some processing, i.e. the faulty ones get disabled but the scheduling is also messed up with the FPGAs idling most of the time.
Good night.
|
|
|
|
kano
Legendary
Offline
Activity: 4620
Merit: 1851
Linux since 1997 RedHat 4
|
|
June 26, 2012, 11:23:32 PM |
|
... and if you add a "-S noauto" then that ensures it never does auto detection
|
|
|
|
daemonic
Newbie
Offline
Activity: 49
Merit: 0
|
|
June 26, 2012, 11:26:26 PM |
|
I have found MY problemI don't know if it fixes your's also. FIRST: Turn off the unit! Set the dip switches to the shipping configuration!If you turn on the unit with other dip settings, the unit will not work! It will not work, no matter what you do. Shipping configuration 50MHz: SW1/6 all on SW2 all on SW3 134 on, 2 off SW4 134 on, 2 off SW5 all on Keep in mind, every time you need to turn off your unit, you need to redo the dip switches to the shipping config BEFOR you turn on the unit! 1. Turn on the unit and wait until all led's turn orange. Then plug in the USB. 2. Then start up the VM (the VM automaticly takes the unit, that's really anoying). If it does not, connect it to the VM. 3. Now SW1 3 off! SW3/4 12 off, 34 on! 4. Then programm it, i think everyone knows how to do that with all that testing 5. No change to the switches and disconnect it from the VM. 6. Turn off the VM now. Not the unit! ...Please do that! The bump VM retakes the unit sometimes. 7. SW1 3 on. 8. SW6 1 off. 9. Start cgminer 2.4.3 with the COM-Ports your unit works. 10. cgminer show you some Mh/s, but U=0.0 Now you are at the point your were often the last day's. The unit will not hash... But, now i find out there is a problem with the SW6 1. Donno if that is software or hardware related. 11. Just switch the SW6 1 on, and again off. 12. Wait some seconds/minutes. 13. One fpga(0) should now do something, if not repeat point 11. Take a look on the LED, the orange should go off. If it keeps getting on after a second, repeat point 11. 14. Now one fpga is working, repeat point 11. until you see the orange led from the second fpga(3) turn off. 15. Now it should work with both fpga's, but the second one is instable and don't provide hashes like the first fpga. Please try that, it works for me now on every attempt. I hope it works for someone else too Are you using the same process still for the 190M_V3.bit bitstream? I can get to the step 9 and all i get is the good old "got 0000000 expecting 000187a2" error
|
|
|
|
Doff
|
|
June 27, 2012, 12:30:05 AM Last edit: June 27, 2012, 01:02:23 AM by Doff |
|
The twin test is more or less a standard Icarus build. I think the ID and maybe the DCM settings were changed but that was about it.
Ok, then it's based on the 190M_V4.bit. 190M_V3.bit and less is 100% different when i make a binary compare to the twin_test.bit. But then that's the problem with twin_test.bit. It will stop working after some time. It is not droping it will complete stop working. 50 minutes so far on the 190M_V3.bit without invalids and pool stat is still rising the Mh/s. 386Mh/s/10 minutes so far. (fingers crossed!) Eb when you did this did you use the twin_test.bit programing switches? I followed what you did Ebereon I'm still unable to get hashing at over 100, I did have 1 ICA hashing for a few minutes but they always die after a little bit. I also tried the 190M_V3 bitstream but was unsuccessful on that as well. I can program it now in Linux witch makes me happy, Thanks Zefir, and Spiccoli.
|
|
|
|
kano
Legendary
Offline
Activity: 4620
Merit: 1851
Linux since 1997 RedHat 4
|
|
June 27, 2012, 01:21:06 AM |
|
... Are you using the same process still for the 190M_V3.bit bitstream? I can get to the step 9 and all i get is the good old "got 0000000 expecting 000187a2" error ... and just in case anyone was wondering what exactly that error means: An icarus is detected by sending it work and getting a reply (there is no other command you can send to it and no ACK other than a random 4 byte nonce reply) So the code sends some work that has the expected nonce answer of 0x000187a2 (or 0xa2870100) I searched the blockchain for a low value and the lowest I found in the small search I did was: Ozcoin block 171874 (which is certainly low enough) For a normal Icarus this takes ~0.53ms ((0x000187a2 / 2^31) * ~11.3) The code waits up to 100ms for the reply and then effectively returns 0 So the error means either of: 1) The work didn't get to the FPGA or the FPGA couldn't return the answer (due to some FPGA configuration settings/bitstream issue) 2) The FPGA took more than 100ms to find the nonce (EXTREMELY unlikely) But in both cases, yes there is no point trying to mine on it: 1) It doesn't work 2) It will be mining at less than 2MH/s Just an FYI in case anyone was wondering
|
|
|
|
spiccioli
Legendary
Offline
Activity: 1379
Merit: 1003
nec sine labore
|
|
June 27, 2012, 06:20:25 AM |
|
rjk, here the image of the boards, on the left serial nr 62-008 and on the right, 62-104 with its military green hue By the way, if someone needs it (and trusts my build) here it is cgminer 2.4.3 built as a 32 bit linux program without OpenCL/ADL and with icarus support only. http://p2pool.soon.it/cgminer/cgminer-2.4.3Download it, issue a to make it executable and it's ready to go. Given that it is easy to build one, I'll remove it in a few days. spiccioli
|
|
|
|
ebereon
|
|
June 27, 2012, 07:25:24 AM |
|
Eb when you did this did you use the twin_test.bit programing switches?
I followed what you did Ebereon I'm still unable to get hashing at over 100, I did have 1 ICA hashing for a few minutes but they always die after a little bit. I also tried the 190M_V3 bitstream but was unsuccessful on that as well.
In most cases when it will not work is the frequency/noise problem. See my post here -> https://bitcointalk.org/index.php?topic=78239.msg992167#msg992167I use the programming switches for the shipping bitstream. But i got it also work with the switch settings for the twin_test.bit. 190M_V3.bit is running @ 401Mh/s (1 hour average) on p2pool stats, so far so good.
I will post an update tomorrow.
Im about to get my boards later this week and it seems like your the who's reporting in with best numbers. Could you please specify what bitstream you are runnin running with what miner and what versions ? Thank you in advance. I use: Original Icarus bitstream "190M_V3.bit" MPBM latest git with some changes on Win7 32bit Worker setting in MPBM 115200 baud, jobinterval 11.34 Standard unit switch settings: SW1 1234 on SW6 1 off, 234 on SW2 1234 on SW3 2 off, 134 on SW4 2 off, 134 on SW5 1234 on Programming switch settings: SW1 3 off, 124 on SW6 1234 on SW2 - SW5 same as Standard I can programm only in the temporary mode, if i turn off the unit then it have the shipping bitstream again. I hope this helps a bit greets, eb
|
|
|
|
spiccioli
Legendary
Offline
Activity: 1379
Merit: 1003
nec sine labore
|
|
June 27, 2012, 07:30:14 AM |
|
|
|
|
|
ebereon
|
|
June 27, 2012, 07:37:21 AM |
|
yes, works with huge invalids. At the moment also the 190M_V3.bit have invalids, i think we can't do anything, it's the Frequency/noise problem and it looks like after some hours hashing it gets more and more invalids. I'm off now for work i will report my hashing rate later today.
|
|
|
|
rjk
Sr. Member
Offline
Activity: 448
Merit: 250
1ngldh
|
|
June 27, 2012, 12:57:35 PM |
|
|
|
|
|
gyverlb
|
|
June 27, 2012, 02:05:41 PM |
|
Serials 110 and 111 delivered today. They are now hashing for more than 2 hours with twin_test.bit at a total of ~770MH/s as reported by Ozcoin. Couldn't store the bitstream in flash with xc3sprog "-I" parameter though This is the same problem than the one reported here by others ("ISF Bitfile probably not loaded"). Hope the rig remains stable...
|
|
|
|
testconpastas2
|
|
June 27, 2012, 02:19:28 PM |
|
Well now i have all my boards. only opened one, and using your advices could hash with shipping bitstream (and twin_test). I (temporaly) programed 0 and 3 fpgas but couldn't permanent program them. anyone with permanent programming has a piece of advice? I`ve used "--icarus-timing short" and speed's still weird looking forward your ribbon cables support.
|
|
|
|
|
|
rjk
Sr. Member
Offline
Activity: 448
Merit: 250
1ngldh
|
|
June 27, 2012, 03:20:36 PM |
|
Actually, I think the 45586 has the wrong keying, but the 50-36-1744 looks like it might work? The PDF shows a 10-pin version, but I can't tell what the keying is on the 8-pin version.
|
|
|
|
mrb
Legendary
Offline
Activity: 1512
Merit: 1028
|
|
June 27, 2012, 03:23:26 PM |
|
rjk: nope. This 45586 part (there are many of them) and the other do not have the plastic bridge between pins 7-8, and (as you pointed out) do not appear to have the right keying which should be:
LL RRSS SRRR
L = Latch R = Round S = Square
|
|
|
|
rjk
Sr. Member
Offline
Activity: 448
Merit: 250
1ngldh
|
|
June 27, 2012, 03:31:17 PM |
|
rjk: nope. This 45586 part (there are many of them) and the other do not have the plastic bridge between pins 7-8, and (as you pointed out) do not appear to have the right keying which should be:
LL RRSS SRRR
L = Latch R = Round S = Square
Sorry my bad! I got mixed up between 8-pin PCIe and EPS12V. The thing is, the additional 2 pins on a PCIe 8-pin connector are unnecessary - they are just signals connected to ground and do not carry current. EPS12V goes like this: LL RSSR SRRS
|
|
|
|
yohan (OP)
|
|
June 27, 2012, 03:46:58 PM |
|
It doesn't surprise me that PCIsig would try and keep a secret of this. It's a very greedy organisation. The amount they charge just for a PCIe spec is enormous. However I would not be surprised if there isn't a Chinese clone available somewhere out there. It's the identifying and getting hold of the parts that is the biggest issue. On a side note we are looking at the emails send to the new support email and we will try and make a proper response on these before too long. Please bear with us on this we aren't doing *** style response here and deliberately ignoring you all but at the moment our main focus is the new design bitstream which is now getting more time and resource to bring that into shape. Once we have the first version of that the up/down function won't be far behind and the Cairnsmore1 design will start to show what we think it is really capable of doing.
|
|
|
|
|