Topic: Cairnsmore1 - Quad XC6SLX150 Board - page 78. (Read 286370 times)
I'm interested in the product but how are you able to quality test the FPGAs if you don't have a bitstream yet? Do you have a web page that spells out the warranty info (who pays what, shipping, warranty duration etc.)?
@yohan: any news or piece of software we can play with?
Ok nothing too exciting today. The Power Distribution Boards PCBs arrived today and we part built one of them and tested the ATX turn on function and that all worked as we expected. We are going to fit one of the switch positions with a header so a semi-remote switch can be used to turn on the stack. There will be a local switch as well. We will do a full board build up on Monday when the Pheonix connectors arrive and we should have some available to ship Tuesday or Wednesday next week.
Bitstream moved another notch closer but nothing out of the ordinary there. The first release isn't far away. I believe we are talking days now but as this is very hard to predict I won't totally promise that.
On the programming today was busy and I have not managed to go through that process yet. However I have a board with me to test in the relative peace of my home office. I will attempt the programming of a board using Win7/64 machine as the host to start with following the instruction you all have to work with. From that I will see how I do and hopefully identify things that are not totally clear and what we might do better. We do have a couple of further development activities planned to improve the programming but that will be after we get the first bitstream going.
I'm tired of testing now.
18 days of testing to get the unit hashing faster, but no success here.
18 days of testing to get the unit hashing faster, but no success here.
Ebereon,
while I can feel you're tired and I don't have definitive answers, I'd like to add some thoughts.
Am I right that you are on p2pool?
See this, three boards, serial: 8, 104, 136
Code:
cgminer version 2.4.3 - Started: [2012-06-27 21:01:05]
--------------------------------------------------------------------------------
(5s):2492.7 (avg):2080.6 Mh/s | Q:116837 A:42219 R:381 HW:0 E:36% U:14.5/m
TQ: 6 ST: 7 SS: 225 DW: 7010 NB: 278 LW: 14068 GF: 226 RF: 272
Connected to http://pool.abcpool.co with LP as xxxxxxxxxxx
Block: 00000167d598249e60d7faab8784a2c8... Started: [21:22:44]
--------------------------------------------------------------------------------
[P]ool management [S]ettings [D]isplay options [Q]uit
ICA 0: | 379.9/346.6Mh/s | A:7188 R:63 HW:0 U: 2.47/m
ICA 1: | 379.8/346.7Mh/s | A:6279 R:57 HW:0 U: 2.16/m
ICA 2: | 379.9/346.8Mh/s | A:7242 R:68 HW:0 U: 2.49/m
ICA 3: | 379.8/346.8Mh/s | A:7144 R:56 HW:0 U: 2.45/m
ICA 4: | 379.9/346.8Mh/s | A:7227 R:61 HW:0 U: 2.48/m
ICA 5: | 379.6/347.0Mh/s | A:7140 R:76 HW:0 U: 2.45/m
--------------------------------------------------------------------------------
on ABC.
Can you try/did you try a different pool?
Maybe the fast p2pool chain creates some problem which I don't seem to have.
Maybe it's just me that was lucky with the cards... I don't know, I see that ICA1: is slower than the others, this is FPGA3 on serial nr. 8, but sometimes it is ICA0: which is slower but it never slowed down (up until now, at least) to a few MH/s.
And I don't have any icarus-timing thing in my command line which is:
Code:
./cgminer -S /dev/ttyUSB2 -S /dev/ttyUSB3 -S /dev/ttyUSB5 -S /dev/ttyUSB6 -S /dev/ttyUSB8 -S /dev/ttyUSB9 -o http://pool.abcpool.co -O x:y -o http://p2pool.soon.it:9332 -O w:z -Q 7 --failover-only
I have p2pool as failover pool, but it was used just a little today in the early morning, CET time, while ABC was having problems.
I'm powering them through PCIe connectors from a 500W Antec ATX PSU and on board 8 I did not reprogram the spartan 3.
spiccioli.
ps. I'm also waiting for something that makes it possible to use all FPGAs on each board, though.
I'm tired of testing now.
18 days of testing to get the unit hashing faster, but no success here.
What I tested:
PC:
1 netbook 1666MHz Intel Atom 1GB ram Win7 32
1 notebook 1800MHz AMD something 2 GB ram Win7 32
1 notebook workstation Intel I7 2720 8GB ram Win7 x64
Checked energie options for USB Ports etc.
Tested with powered USB Hub (Logilink 10 Port) and without.
SW:
cgminer 2.4.3 (115200 baud)
cgminer ep version (57600 baud)
mpbm (115200 and 57600 baud)
Bitstreams:
shipping = 60Mh/s/week (120Mh/s/hour max)
twin_test = 60Mh/s/day (386Mh/s/hour max)
190M_V4 = same as twin_test
190M_V3 = 120Mh/s/day (401Mh/s/hour max)
200beta = 5Mh/s/day (280Mh/s/hour max)
Every bitstream is hashing 1 minute and up to 14 hours at nice rates, but after this I get many invalids (>80%) and the unit will stop working correctly, 0Mh for about 3 hours then again some shares and so on.
I'm really upset at the moment, I invested ~6 hours a day 18 days long to test things, I thougth I was doing something wrong and tested every switch settings I know. The answere from enterpoint that there is a frequency/noise problem did't help me futher. And they said that they "think" to work around the problem with their bitstream scares me too. Hardware problem?
Today I did my last test and after that, the cairnsmore1 has learned to fly from one corner to the other in my room, god thanks it landed on the couch but jumped again up and fall down and dropped in the package in which it was delivered... I think it will go back to home ..."E.T(P). phoning home"... (someone knows that?)
So this baby is now waiting in the package... I don't know what I should do now.
@yohan: any news or piece of software we can play with?
EDIT:
Tested PSU:
ATX 1000W
And a 60W switching psu with phoenix connector
Cables:
5 different USB cables
18 days of testing to get the unit hashing faster, but no success here.
What I tested:
PC:
1 netbook 1666MHz Intel Atom 1GB ram Win7 32
1 notebook 1800MHz AMD something 2 GB ram Win7 32
1 notebook workstation Intel I7 2720 8GB ram Win7 x64
Checked energie options for USB Ports etc.
Tested with powered USB Hub (Logilink 10 Port) and without.
SW:
cgminer 2.4.3 (115200 baud)
cgminer ep version (57600 baud)
mpbm (115200 and 57600 baud)
Bitstreams:
shipping = 60Mh/s/week (120Mh/s/hour max)
twin_test = 60Mh/s/day (386Mh/s/hour max)
190M_V4 = same as twin_test
190M_V3 = 120Mh/s/day (401Mh/s/hour max)
200beta = 5Mh/s/day (280Mh/s/hour max)
Every bitstream is hashing 1 minute and up to 14 hours at nice rates, but after this I get many invalids (>80%) and the unit will stop working correctly, 0Mh for about 3 hours then again some shares and so on.
I'm really upset at the moment, I invested ~6 hours a day 18 days long to test things, I thougth I was doing something wrong and tested every switch settings I know. The answere from enterpoint that there is a frequency/noise problem did't help me futher. And they said that they "think" to work around the problem with their bitstream scares me too. Hardware problem?
Today I did my last test and after that, the cairnsmore1 has learned to fly from one corner to the other in my room, god thanks it landed on the couch but jumped again up and fall down and dropped in the package in which it was delivered... I think it will go back to home ..."E.T(P). phoning home"... (someone knows that?)
So this baby is now waiting in the package... I don't know what I should do now.
@yohan: any news or piece of software we can play with?
EDIT:
Tested PSU:
ATX 1000W
And a 60W switching psu with phoenix connector
Cables:
5 different USB cables
Yohan, could you please clarify what you mean with 'you should be able to do that now (i.e. writing to SPI)'? As said above, right now no one successfully wrote to the SPI flash and it is really a PITA to reprogram all devices non persistently again when one of them crashed and need to be powered fully down (you do not know which one is the problematic one and need to turn off all of them).
So either it is possible with the current controller programming, then could you please provide a detailed step-by-step instruction. Or it is not doable over USB but needs to be done via JTAG.
Either way it would be very helpful to flash the Icarus bitstream into SPI until your dedicated one is ready. Any clarification is highly appreciated.
Thanks.
So either it is possible with the current controller programming, then could you please provide a detailed step-by-step instruction. Or it is not doable over USB but needs to be done via JTAG.
Either way it would be very helpful to flash the Icarus bitstream into SPI until your dedicated one is ready. Any clarification is highly appreciated.
Thanks.
Yes I think all of this is currently possible and I will double check that this morning that I am not talking crap in any shape or form. We use these processes on our lines already. The load of the 4 array SPI Flash does take over 30 minutes so it does need patience to do. We do a 5-10 boards together here to stop it becoming a line blocker.
I will also see if we can somehow streamline the instructions.
I too would prefer working instructions for flashing to the SPI for the twin_test bitstream.
Personally I would prefer this now as opposed to getting the working bitstream a day earlier so then atleast I can run the twin_test bitstream without going through reflashing it every day.
I would be happy to give enterpoint an interest free loan if they could beat BFl to it.
Who's with me?
I'm not giving anyone an interest free loan.Who's with me?
Id rather they just focus on their bitstream or even release an early version that can hash at 300+, Ive tried for hours to get the twin, or 190_v3 working and it just wont do it on my board. I did get it working again with the shipping_test bitstream so at least I'm getting 110 hash.
Problem is that might be quite far off yet, but I'm just speculating of course. That's why I'd rather have the twin_test flashed to SPI because I'm having problems running twin_test normally also. It's just sat turned off at the minute waiting for updates.
Yohan, could you please clarify what you mean with 'you should be able to do that now (i.e. writing to SPI)'? As said above, right now no one successfully wrote to the SPI flash and it is really a PITA to reprogram all devices non persistently again when one of them crashed and need to be powered fully down (you do not know which one is the problematic one and need to turn off all of them).
So either it is possible with the current controller programming, then could you please provide a detailed step-by-step instruction. Or it is not doable over USB but needs to be done via JTAG.
Either way it would be very helpful to flash the Icarus bitstream into SPI until your dedicated one is ready. Any clarification is highly appreciated.
Thanks.
So either it is possible with the current controller programming, then could you please provide a detailed step-by-step instruction. Or it is not doable over USB but needs to be done via JTAG.
Either way it would be very helpful to flash the Icarus bitstream into SPI until your dedicated one is ready. Any clarification is highly appreciated.
Thanks.
Yes I think all of this is currently possible and I will double check that this morning that I am not talking crap in any shape or form. We use these processes on our lines already. The load of the 4 array SPI Flash does take over 30 minutes so it does need patience to do. We do a 5-10 boards together here to stop it becoming a line blocker.
I will also see if we can somehow streamline the instructions.
I too would prefer working instructions for flashing to the SPI for the twin_test bitstream.
Personally I would prefer this now as opposed to getting the working bitstream a day earlier so then atleast I can run the twin_test bitstream without going through reflashing it every day.
I would be happy to give enterpoint an interest free loan if they could beat BFl to it.
Who's with me?
I'm not giving anyone an interest free loan.Who's with me?
Id rather they just focus on their bitstream or even release an early version that can hash at 300+, Ive tried for hours to get the twin, or 190_v3 working and it just wont do it on my board. I did get it working again with the shipping_test bitstream so at least I'm getting 110 hash.
I can confirm that the twin configuration works reliably (at least for 30hours straight on my 2 boards).
Argh: it failed on at least one of the two boards after around 48h.cgminer marked all FPGAs OFF and on restart could only find 2 of the 4 (this is why I think only one board failed). I didn't think of checking if the USB tty where still available (/dev/ttyUSB*).
Anyway: powered down the 2 boards and reinstalled the twin_test bitstream according to the documented procedure one board at a time and it works again on the 4 FPGAs (out of 8 ).
Anything we can do in Cairnsmore1 can be done better in Cairnsmore2 where we have more technology to play with.
Any hints on what's up for specs? 
There are many variables still be tied down and I also don't want to give too much away to the competition but it might be interesting. There is more that one unique idea floating round the development team and I'm not going to promise anything we have not got fully working yet. You are going to have to faith with us to deliver the interesting bit. There are many barely documented features of FPGAs that even most people designing daily with FPGAs simply don't know about and that's about all I will say for the moment.
Anything we can do in Cairnsmore1 can be done better in Cairnsmore2 where we have more technology to play with.
Any hints on what's up for specs? Yohan, could you please clarify what you mean with 'you should be able to do that now (i.e. writing to SPI)'? As said above, right now no one successfully wrote to the SPI flash and it is really a PITA to reprogram all devices non persistently again when one of them crashed and need to be powered fully down (you do not know which one is the problematic one and need to turn off all of them).
So either it is possible with the current controller programming, then could you please provide a detailed step-by-step instruction. Or it is not doable over USB but needs to be done via JTAG.
Either way it would be very helpful to flash the Icarus bitstream into SPI until your dedicated one is ready. Any clarification is highly appreciated.
Thanks.
So either it is possible with the current controller programming, then could you please provide a detailed step-by-step instruction. Or it is not doable over USB but needs to be done via JTAG.
Either way it would be very helpful to flash the Icarus bitstream into SPI until your dedicated one is ready. Any clarification is highly appreciated.
Thanks.
Yes I think all of this is currently possible and I will double check that this morning that I am not talking crap in any shape or form. We use these processes on our lines already. The load of the 4 array SPI Flash does take over 30 minutes so it does need patience to do. We do a 5-10 boards together here to stop it becoming a line blocker.
I will also see if we can somehow streamline the instructions.
I too would prefer working instructions for flashing to the SPI for the twin_test bitstream.
Personally I would prefer this now as opposed to getting the working bitstream a day earlier so then at least I can run the twin_test bitstream without going through reflashing it every day.
I would be happy to give enterpoint an interest free loan if they could beat BFl to it.
Who's with me?
I'm not giving anyone an interest free loan.Who's with me?
Let's not worry about the name that shall not be mentioned. Let's see firstly how the technology gong into Cairnsmore1 works. If it achieves even some of what think it can, and that is still an if, but and maybe, we have something that that is potentially a major step forward. Anything we can do in Cairnsmore1 can be done better in Cairnsmore2 where we have more technology to play with.
Yohan, could you please clarify what you mean with 'you should be able to do that now (i.e. writing to SPI)'? As said above, right now no one successfully wrote to the SPI flash and it is really a PITA to reprogram all devices non persistently again when one of them crashed and need to be powered fully down (you do not know which one is the problematic one and need to turn off all of them).
So either it is possible with the current controller programming, then could you please provide a detailed step-by-step instruction. Or it is not doable over USB but needs to be done via JTAG.
Either way it would be very helpful to flash the Icarus bitstream into SPI until your dedicated one is ready. Any clarification is highly appreciated.
Thanks.
So either it is possible with the current controller programming, then could you please provide a detailed step-by-step instruction. Or it is not doable over USB but needs to be done via JTAG.
Either way it would be very helpful to flash the Icarus bitstream into SPI until your dedicated one is ready. Any clarification is highly appreciated.
Thanks.
Yes I think all of this is currently possible and I will double check that this morning that I am not talking crap in any shape or form. We use these processes on our lines already. The load of the 4 array SPI Flash does take over 30 minutes so it does need patience to do. We do a 5-10 boards together here to stop it becoming a line blocker.
I will also see if we can somehow streamline the instructions.
I too would prefer working instructions for flashing to the SPI for the twin_test bitstream.
Personally I would prefer this now as opposed to getting the working bitstream a day earlier so then atleast I can run the twin_test bitstream without going through reflashing it every day.
I would be happy to give enterpoint an interest free loan if they could beat BFl to it.
Who's with me?
I'm not giving anyone an interest free loan. Who's with me?
Programming wise it's our intention that everything becomes resident in the SPI flash and doen't need to be live loaded every time. You should be able to do that now but obviously that's not straightforward for all of you and we are going to come back and look at that in more detail and try and make it better. We still have the ultimate fallback of using stand alone cables if that is necessary. It should not be necessary to go this far though.
[...]
Yohan, could you please clarify what you mean with 'you should be able to do that now (i.e. writing to SPI)'? As said above, right now no one successfully wrote to the SPI flash and it is really a PITA to reprogram all devices non persistently again when one of them crashed and need to be powered fully down (you do not know which one is the problematic one and need to turn off all of them).[...]
So either it is possible with the current controller programming, then could you please provide a detailed step-by-step instruction. Or it is not doable over USB but needs to be done via JTAG.
Either way it would be very helpful to flash the Icarus bitstream into SPI until your dedicated one is ready. Any clarification is highly appreciated.
Thanks.
Yes I think all of this is currently possible and I will double check that this morning that I am not talking crap in any shape or form. We use these processes on our lines already. The load of the 4 array SPI Flash does take over 30 minutes so it does need patience to do. We do a 5-10 boards together here to stop it becoming a line blocker.
I will also see if we can somehow streamline the instructions.
Programming wise it's our intention that everything becomes resident in the SPI flash and doen't need to be live loaded every time. You should be able to do that now but obviously that's not straightforward for all of you and we are going to come back and look at that in more detail and try and make it better. We still have the ultimate fallback of using stand alone cables if that is necessary. It should not be necessary to go this far though.
[...]
Yohan, could you please clarify what you mean with 'you should be able to do that now (i.e. writing to SPI)'? As said above, right now no one successfully wrote to the SPI flash and it is really a PITA to reprogram all devices non persistently again when one of them crashed and need to be powered fully down (you do not know which one is the problematic one and need to turn off all of them).[...]
So either it is possible with the current controller programming, then could you please provide a detailed step-by-step instruction. Or it is not doable over USB but needs to be done via JTAG.
Either way it would be very helpful to flash the Icarus bitstream into SPI until your dedicated one is ready. Any clarification is highly appreciated.
Thanks.
Unfortunately, too many members of the community have allowed greed to be their primary motivating force while hiding behind the concept of "protecting the network" which is a crock of shit. Last time I checked, no one has attempted a 51% attack and an army of people with FPGA's could very easily sustain the network over the long haul.
Unfortunately we have this great company in enterpoint coming into the market and BFL has once again used their unethical business practices to essentially halt the purchase of FPGA's while the lemmings line up once again to give these thieves no interest loans to fund their ASIC project.
Greed is such a bitch and it's going to destroy bitcoin before it has a chance to gain any real traction if people are going to flock to vendors like BFL.
This type of behavior is exactly what goes on in the central banking world that bitcoin was designed to help people gain freedom from, but once people start seeing those dollar signs, ethics and morals dissolve rapidly.
BFL has turned mining into the worst type of pyramid scheme and those who worship BFL are blindly following like crazed scientologists.
I can't believe people are willing to give a company like this upfront cash and these clowns can't even clearly articulate their buy back program until the community essentially forced them to do so.
I'd be bankrupt in a week and have my medical license taken away if I pulled half the stunts they have pulled.
I just wish there was a way to re-purpose or find some resale value for these FPGA's because I would buy dozens if that were the case.
Okay, sorry, rant over.
Unfortunately we have this great company in enterpoint coming into the market and BFL has once again used their unethical business practices to essentially halt the purchase of FPGA's while the lemmings line up once again to give these thieves no interest loans to fund their ASIC project.
Greed is such a bitch and it's going to destroy bitcoin before it has a chance to gain any real traction if people are going to flock to vendors like BFL.
This type of behavior is exactly what goes on in the central banking world that bitcoin was designed to help people gain freedom from, but once people start seeing those dollar signs, ethics and morals dissolve rapidly.
BFL has turned mining into the worst type of pyramid scheme and those who worship BFL are blindly following like crazed scientologists.
I can't believe people are willing to give a company like this upfront cash and these clowns can't even clearly articulate their buy back program until the community essentially forced them to do so.
I'd be bankrupt in a week and have my medical license taken away if I pulled half the stunts they have pulled.
I just wish there was a way to re-purpose or find some resale value for these FPGA's because I would buy dozens if that were the case.
Okay, sorry, rant over.
I'm looking forward to a new Bitstream, I have tried everything and every now and again I can get 1 ICA to work at around 120mhash. I'm bummed I'm not able to get the 300+ following the others instructions, and trying things on my own. It definitely seems to program but just wont do anything after that on one of the ports.
Thanks for the update. I'm sure you guys know by now how helpful it is to calm down customer's fears with the turmoil that recent announcements have created. Look forward to your official bitstream and hopefully we'll all just consider Cairnsmore1 as a proof of market product for Enterpoint.
edit: I should clarify. The BFL announcement has me shitting bricks and consulting soothsayers, fortune tellers and beer bottles as to how legitimate it is. Not sure if any other miners are in the same boat but it isn't a fun one At least in the end I'm hoping Enterpoint will be there with future products that leverage better technologies.
edit: I should clarify. The BFL announcement has me shitting bricks and consulting soothsayers, fortune tellers and beer bottles as to how legitimate it is. Not sure if any other miners are in the same boat but it isn't a fun one
At least in the end I'm hoping Enterpoint will be there with future products that leverage better technologies. I can confirm that the twin configuration works reliably (at least for 30hours straight on my 2 boards).
No luck storing it in flash though so if the power to the boards is lost I'll have to go to their location to reset them manually as it involves moving dip switches.
@yohan : is bitstream flashing supposed to need a manual intervention forever or will it be possible to do so remotely (without touching the dip switches) in the future ?
No luck storing it in flash though so if the power to the boards is lost I'll have to go to their location to reset them manually as it involves moving dip switches.
@yohan : is bitstream flashing supposed to need a manual intervention forever or will it be possible to do so remotely (without touching the dip switches) in the future ?
Programming wise it's our intention that everything becomes resident in the SPI flash and doen't need to be live loaded every time. You should be able to do that now but obviously that's not straightforward for all of you and we are going to come back and look at that in more detail and try and make it better. We still have the ultimate fallback of using stand alone cables if that is necessary. It should not be necessary to go this far though.
We are looking to make things nicer and that you all don't have to fiddle with dip switches very much if at all. On the array FPGAs it's our intention that the dip switches will be totally unused. So once we have that SW2, SW3, SW4, and SW5 won't even be a consideration. The dip switches SW1 and SW6 for the controller will at least be simplified. We are still debating if we need a "safety" dip switch to act as a block to accidentially programming a board but pretty much everything else can become software controlled and I think that is the way it will go. At the moment only 7 of the 8 switch bits of SW1/6 are used but that's still 127 possibilities to get it wrong.
The drive for all of this will be the delivery of our original bitstream design and with that we will have the next controller build. With the first version of that our aim will be stability but achieving at least the circa 800MH/s everyone is looking for. It's a very radical design but I think everyone will be pleased with the results assuming it works the way we think it should. Either that we have totally lost our touch at doing these sorts of things. Hopefully that's not the case. It's now our big focus to deliver this now we are more or less sorted on the hardward bits of the design.
I can confirm that the twin configuration works reliably (at least for 30hours straight on my 2 boards).
No luck storing it in flash though so if the power to the boards is lost I'll have to go to their location to reset them manually as it involves moving dip switches.
@yohan : is bitstream flashing supposed to need a manual intervention forever or will it be possible to do so remotely (without touching the dip switches) in the future ?
No luck storing it in flash though so if the power to the boards is lost I'll have to go to their location to reset them manually as it involves moving dip switches.
@yohan : is bitstream flashing supposed to need a manual intervention forever or will it be possible to do so remotely (without touching the dip switches) in the future ?
Ok some running dip switch settings. These are now on support page as well.
Your pic says more than my 1000 words, yohan. 
Thanks!The Icarus setting is exactly what I am using to mine with unmodified cgminer 2.4.3. For programming, I just set SW1-3 off and than back to on - works reliably.
I found another mini USB hub and attached 4 more boards. Looking at the cgminer output after a hour or so:
Code:
--------------------------------------------------------------------------------
(5s):10926.6 (avg):11799.3 Mh/s | Q:1397 A:1364 R:0 HW:0 E:98% U:65.8/m
TQ: 56 ST: 58 SS: 0 DW: 256 NB: 3 LW: 4553 GF: 3 RF: 0
Connected to http://eu.ozco.in:8332 with LP as user zeta-mining.1
Block: 000008eb5cae1b4d3a1d0ebf00a7342e... Started: [17:49:15]
--------------------------------------------------------------------------------
[P]ool management [S]ettings [D]isplay options [Q]uit
ICA 0: | 379.8/366.0Mh/s | A:54 R:0 HW:0 U: 2.61/m
ICA 1: | 379.9/370.3Mh/s | A:13 R:0 HW:0 U: 0.63/m
ICA 2: | 380.0/365.6Mh/s | A:51 R:0 HW:0 U: 2.46/m
ICA 3: | 379.9/374.7Mh/s | A:21 R:0 HW:0 U: 1.01/m
ICA 4: | 379.8/372.6Mh/s | A:56 R:0 HW:0 U: 2.70/m
ICA 5: | 379.9/372.1Mh/s | A:58 R:0 HW:0 U: 2.80/m
ICA 6: | 379.5/370.3Mh/s | A: 0 R:0 HW:0 U: 0.00/m
ICA 7: | 379.3/369.5Mh/s | A: 0 R:0 HW:0 U: 0.00/m
ICA 8: | 379.9/369.4Mh/s | A:53 R:0 HW:0 U: 2.56/m
ICA 9: | 379.9/369.3Mh/s | A:46 R:0 HW:0 U: 2.22/m
ICA 10: | 379.8/369.8Mh/s | A:45 R:0 HW:0 U: 2.17/m
ICA 11: | 379.9/370.1Mh/s | A:27 R:0 HW:0 U: 1.30/m
ICA 12: | 379.8/368.1Mh/s | A:60 R:0 HW:0 U: 2.90/m
ICA 13: | 379.8/369.3Mh/s | A:53 R:0 HW:0 U: 2.56/m
ICA 14: | 379.9/368.7Mh/s | A:49 R:0 HW:0 U: 2.37/m
ICA 15: | 379.8/368.8Mh/s | A:46 R:0 HW:0 U: 2.22/m
ICA 16: | 379.7/371.6Mh/s | A:57 R:0 HW:0 U: 2.75/m
ICA 17: | 379.8/372.4Mh/s | A:61 R:0 HW:0 U: 2.94/m
ICA 18: | 379.9/368.8Mh/s | A:60 R:0 HW:0 U: 2.90/m
ICA 19: | 379.7/369.8Mh/s | A:73 R:0 HW:0 U: 3.52/m
ICA 20: | 379.9/368.8Mh/s | A:43 R:0 HW:0 U: 2.08/m
ICA 21: | 379.9/368.2Mh/s | A:43 R:0 HW:0 U: 2.08/m
ICA 22: | 379.8/372.7Mh/s | A:38 R:0 HW:0 U: 1.83/m
ICA 23: | 379.9/373.6Mh/s | A:55 R:0 HW:0 U: 2.66/m
ICA 24: | 379.8/368.0Mh/s | A:44 R:0 HW:0 U: 2.12/m
ICA 25: | 379.6/369.5Mh/s | A:55 R:0 HW:0 U: 2.66/m
ICA 26: | 379.9/368.9Mh/s | A:44 R:0 HW:0 U: 2.12/m
ICA 27: | 379.9/366.1Mh/s | A:48 R:0 HW:0 U: 2.32/m
ICA 28: | 379.7/365.0Mh/s | A:48 R:0 HW:0 U: 2.32/m
ICA 29: | 379.9/368.2Mh/s | A:63 R:0 HW:0 U: 3.04/m
ICA 30: | 379.8/372.0Mh/s | A: 1 R:0 HW:0 U: 0.05/m
ICA 31: | 379.7/372.0Mh/s | A: 0 R:0 HW:0 U: 0.00/m
--------------------------------------------------------------------------------
There are always some units that remain at a very low U, i.e. not generating valid shares. Seems to be the instability eberon was reporting.
Looking forward for the real bitstream
surelly port number is not important it will depend of windows driver installation.
When i received yesterday my boards first of all i unsuccessfully try to use the default shipping bitstream and the default shipping switch settings sw6 all on sw1 all on and got your error:
[2012-06-27 12:37:35] Started cgminer 2.4.3
[2012-06-27 12:37:35] Icarus Detect: Test failed at \\.\COM20: get 00000000, sh
ould: 000187a2
[2012-06-27 12:37:35] Icarus Detect: Test failed at \\.\COM21: get 00000000, sh
ould: 000187a2
[2012-06-27 12:37:35] Icarus Detect: Test failed at \\.\COM22: get 00000000, sh
ould: 000187a2
[2012-06-27 12:37:35] Icarus Detect: Test failed at \\.\COM23: get 00000000, sh
ould: 000187a2
[2012-06-27 12:38:05] Error reading from BitForce (ZGX)
simply changing the sw6 1to off ( 115k) it started to hash with default cgminer (2.4.3) ( first i installed all usb drivers).
once i checked it worked i temporaly programmed the twin.bit and worked too.
cgminer -o http://eu.ozco.in:8332 -u xxxx -p xxxx --disable-gpu -S noauto -S "\\.\COM21" -S "\\.\COM22"
Are you using the standart cgminer and the sw6 (1 off) thingy?
PS: i 've just remembered you had to wait to the amber lights before start cgminer.
When i received yesterday my boards first of all i unsuccessfully try to use the default shipping bitstream and the default shipping switch settings sw6 all on sw1 all on and got your error:
[2012-06-27 12:37:35] Started cgminer 2.4.3
[2012-06-27 12:37:35] Icarus Detect: Test failed at \\.\COM20: get 00000000, sh
ould: 000187a2
[2012-06-27 12:37:35] Icarus Detect: Test failed at \\.\COM21: get 00000000, sh
ould: 000187a2
[2012-06-27 12:37:35] Icarus Detect: Test failed at \\.\COM22: get 00000000, sh
ould: 000187a2
[2012-06-27 12:37:35] Icarus Detect: Test failed at \\.\COM23: get 00000000, sh
ould: 000187a2
[2012-06-27 12:38:05] Error reading from BitForce (ZGX)
simply changing the sw6 1to off ( 115k) it started to hash with default cgminer (2.4.3) ( first i installed all usb drivers).
once i checked it worked i temporaly programmed the twin.bit and worked too.
cgminer -o http://eu.ozco.in:8332 -u xxxx -p xxxx --disable-gpu -S noauto -S "\\.\COM21" -S "\\.\COM22"
Are you using the standart cgminer and the sw6 (1 off) thingy?
PS: i 've just remembered you had to wait to the amber lights before start cgminer.
Jump to: