***
Yohan
Yohan
Hey man, I can't yell at *** for trolling Enterpoint and then let you guys troll them, even if ***'s offerings are less than, well, existent.
Topic: Cairnsmore1 - Quad XC6SLX150 Board - page 85. (Read 286370 times)
Hey man, I can't yell at *** for trolling Enterpoint and then let you guys troll them, even if ***'s offerings are less than, well, existent.
Thanks. The more info we have the better.
Email sent yohan.
Can anyone that has a problem email the new support email with the following:
Board serial number
What revision you think the controller is in. If you didn't touch it just say that.
A description of the problem you have.
What OS your host is running.
What your host is, if you know processor etc. that is all useful to know.
We will try and understand or even try and replicate the problems so that they can debugged. We probably won't do much on that until early next week so please be patient. The better bitstream is our priority for the next few days and as a lot of this stuff will change , hopefully for the better, once that is in place.
We don't want to put a lot of time on the "get going" unless that is strictly necessary as it will delay the better stuff. It would be far better for us to move the whole of the software and firmware side forward so that's the effort for the next few days.
I would also like to know who has a unit working ok is with the currently limited bitstreams. This might get us some insight to where problems actually are as much as the problem unit data. I suspect we don't have a major issue and it's all about recognising any weaknesses in combinations of different things and make even as simple as better docs.
Board serial number
What revision you think the controller is in. If you didn't touch it just say that.
A description of the problem you have.
What OS your host is running.
What your host is, if you know processor etc. that is all useful to know.
We will try and understand or even try and replicate the problems so that they can debugged. We probably won't do much on that until early next week so please be patient. The better bitstream is our priority for the next few days and as a lot of this stuff will change , hopefully for the better, once that is in place.
We don't want to put a lot of time on the "get going" unless that is strictly necessary as it will delay the better stuff. It would be far better for us to move the whole of the software and firmware side forward so that's the effort for the next few days.
I would also like to know who has a unit working ok is with the currently limited bitstreams. This might get us some insight to where problems actually are as much as the problem unit data. I suspect we don't have a major issue and it's all about recognising any weaknesses in combinations of different things and make even as simple as better docs.
That's what I thought. Hopefully this will be week we move on and show real perfomance at least at about the 800MH/s level if not something more.
two FPGAs with twin_test.bit using Mpbm.
spiccioli
Did anyone else in the US get a bill from DHL for customs duties of 2.6%?
That's what I thought. Hopefully this will be week we move on and show real perfomance at least at about the 800MH/s level if not something more.
...
Programming FPGA0/3 is still a pain, it took nearly half an hour for FPGA3 to accept twin_test.bit.
...
@yohan: look's like it's 2 fpga's he use the "twin_test.bit". Programming FPGA0/3 is still a pain, it took nearly half an hour for FPGA3 to accept twin_test.bit.
...
Right now I'm on Mpbm hashing away at 180 MH/s per FPGA.
spiccioli.
Is that 2 FPGAs or 4?
I've not re-programmed the FPGAs controller because it seems that it gives more hassles than good.
Right now I'm on Mpbm hashing away at 180 MH/s per FPGA.
I think both controller firmwares have there own problems. With the new one, the programming (still only temporary mode) works fine but i have to start cgminer and do all the things I have described until it's hashing and then I can stop cgminer to use mpbm.Right now I'm on Mpbm hashing away at 180 MH/s per FPGA.
Ebereon, thanks for your help and the cairnsmore miner for MPBM, I've changed the icarus one following a previous message of yours, though, since the cairnsmore one gives an error when I start Mpbm that some methods accepts 4 parameters but it has been called with 5.
If you need I can dig out the correct error message, anyway I've sent you a little tip since you saved me from upgrading the FPGAs controller
spiccioli.
I use the actual git, not the 0.1.0beta package. But there is also a problem, you have to change some things.If you need I can dig out the correct error message, anyway I've sent you a little tip since you saved me from upgrading the FPGAs controller
spiccioli.
I will upload my version of mpbm here: http://www.wuala.com/ebereon/Shared/bitcoin/mpbm_changed/.
And thanks for the little tip!
eb
State of the Nation Time (What again!!!)
It's 8 weeks, 1 day and about 6hrs since I announced the Cairnsmore1 concept and the Enterpoint team started work on it so please do remember that in reading this. I don't believe there is any other team in the world capable of achieving what we have already done in that timescale never mind what we are continuing to deliver. It wasn't easy do this and I am glad many of you have recognised that and there should be a big handclap for team who have worked hard and still are to try and achieve this.
Doff we do have your email. Not seen any others yet though. If there are any problems please do email as requested. That could help us close down issues more quickly. I don't think we have anything that is a major problem we just need to make better documentation and support materials available. Unlikely to be Monday but hopefully Tuesday/Wednesday we will try and sort our way through at least some of these issues.
Shipping - Production took a big step forward and daily output doubled this week. There are nearly 200 units now in the field today and we are pulling in as much feedback from them as people will give us on these units. Generally it's all good but of course we need to advance the state of the bitstream and more on that in a minute. Going back to orders this week has seen us catch up and everyone that was indicated as a June delivery will either have already had a request for payment or will get one today. We do have a few days possibly in the first week of July where production may stop whilst we await our next delivery of Spartan-6 parts but that might pull forward and then that doesn't happen. Either way it won't have too much of an effect on July ship. At current daily delivery rates our line is capable of delivering 2.5X what we have promised so a a few days downtime we can live with.
Hardware - Thanks to all you that reported that the cooling system was working exceptionally well albeit maybe only working on half the power at the moment. That's very key to what we want finally achieve on this product and a lot of time did go into what might seem a very simple thing. Some people that had planned extreme cooling methods have indicated that they are going to drop these and stay with the standard setup such is the performance of it. Other than that I think we have a great platform to hash on.
Software - We will continue to try and improve this side but won't be our priority for a few days, or a week or whatever, that it takes to get a better performance bitstream.
Bitstream - We believe that 3rd party developers are now close to releasing a solution for Cairnsmore1. Our own bitstream solution we think has the potential to very good and might even be able to compete with *** claims once there some real numbers, and experience is available, for their unit. I know that is a matter of faith for all of you but do remember there is more FPGA knowledge and experience concentrated here in one place and one office than you will probably find vendor A or X's offices and remember that we specialise in doing the near impossible and have done so for very many years.
Our competitors *** have dropped what might be nuclear bomb into Bitcoin and it might well destroy Bitcoin. We will see if it actually happens. It still doesn't financially stack up to me or any way make sense what they are doing other than to destroy Bitcoin. However in Cairnsmore1 we might well have a second strike available to let loose and we won't unless we have to. What's for certain is that GPU miners are going to find it hard to justify switching on their rig if it all goes the way I think it will. I was hoping that this could be a controlled process and not a step change and everyone would win out of that but *** have more or less ensured that people lose money especially if you are a GPU miner and probably even if you are one of their own customers.
Anyway enough of the gloomy bit. We have lost a tiny percentage (0.4%) of orders due to ***'s claims and I believe we gained more orders than we lost and thank you to all that still believe and have faith in the Enterpoint way (I'll get my white collar out for next time and do this properly). We still think Cairnsmore1 is going to be an excellent product for all of our customers and that you will all be happy with your purchases from Enterpoint and that you will all have a sensible return on your investment. We will continue to strive to make that a good experience and will continue in our professional business manner in our engagement with you all. What's for certain if there is a Bitcoin market for what we do we will still be there with competing products.
Yohan
It's 8 weeks, 1 day and about 6hrs since I announced the Cairnsmore1 concept and the Enterpoint team started work on it so please do remember that in reading this. I don't believe there is any other team in the world capable of achieving what we have already done in that timescale never mind what we are continuing to deliver. It wasn't easy do this and I am glad many of you have recognised that and there should be a big handclap for team who have worked hard and still are to try and achieve this.
Doff we do have your email. Not seen any others yet though. If there are any problems please do email as requested. That could help us close down issues more quickly. I don't think we have anything that is a major problem we just need to make better documentation and support materials available. Unlikely to be Monday but hopefully Tuesday/Wednesday we will try and sort our way through at least some of these issues.
Shipping - Production took a big step forward and daily output doubled this week. There are nearly 200 units now in the field today and we are pulling in as much feedback from them as people will give us on these units. Generally it's all good but of course we need to advance the state of the bitstream and more on that in a minute. Going back to orders this week has seen us catch up and everyone that was indicated as a June delivery will either have already had a request for payment or will get one today. We do have a few days possibly in the first week of July where production may stop whilst we await our next delivery of Spartan-6 parts but that might pull forward and then that doesn't happen. Either way it won't have too much of an effect on July ship. At current daily delivery rates our line is capable of delivering 2.5X what we have promised so a a few days downtime we can live with.
Hardware - Thanks to all you that reported that the cooling system was working exceptionally well albeit maybe only working on half the power at the moment. That's very key to what we want finally achieve on this product and a lot of time did go into what might seem a very simple thing. Some people that had planned extreme cooling methods have indicated that they are going to drop these and stay with the standard setup such is the performance of it. Other than that I think we have a great platform to hash on.
Software - We will continue to try and improve this side but won't be our priority for a few days, or a week or whatever, that it takes to get a better performance bitstream.
Bitstream - We believe that 3rd party developers are now close to releasing a solution for Cairnsmore1. Our own bitstream solution we think has the potential to very good and might even be able to compete with *** claims once there some real numbers, and experience is available, for their unit. I know that is a matter of faith for all of you but do remember there is more FPGA knowledge and experience concentrated here in one place and one office than you will probably find vendor A or X's offices and remember that we specialise in doing the near impossible and have done so for very many years.
Our competitors *** have dropped what might be nuclear bomb into Bitcoin and it might well destroy Bitcoin. We will see if it actually happens. It still doesn't financially stack up to me or any way make sense what they are doing other than to destroy Bitcoin. However in Cairnsmore1 we might well have a second strike available to let loose and we won't unless we have to. What's for certain is that GPU miners are going to find it hard to justify switching on their rig if it all goes the way I think it will. I was hoping that this could be a controlled process and not a step change and everyone would win out of that but *** have more or less ensured that people lose money especially if you are a GPU miner and probably even if you are one of their own customers.
Anyway enough of the gloomy bit. We have lost a tiny percentage (0.4%) of orders due to ***'s claims and I believe we gained more orders than we lost and thank you to all that still believe and have faith in the Enterpoint way (I'll get my white collar out for next time and do this properly). We still think Cairnsmore1 is going to be an excellent product for all of our customers and that you will all be happy with your purchases from Enterpoint and that you will all have a sensible return on your investment. We will continue to strive to make that a good experience and will continue in our professional business manner in our engagement with you all. What's for certain if there is a Bitcoin market for what we do we will still be there with competing products.
Yohan
Hi all,
I've made some progress with my ubuntu server running on the HP thin client.
First I've installed ia32-libs and libftdi-dev:i386 so now I can run xc3sprog directly from it instead of using the virtualbox image I have on a Vista laptop.
Programming FPGA0/3 is still a pain, it took nearly half an hour for FPGA3 to accept twin_test.bit.
I've not re-programmed the FPGAs controller because it seems that it gives more hassles than good.
Right now I'm on Mpbm hashing away at 180 MH/s per FPGA.
Ebereon, thanks for your help and the cairnsmore miner for MPBM, I've changed the icarus one following a previous message of yours, though, since the cairnsmore one gives an error when I start Mpbm that some methods accepts 4 parameters but it has been called with 5.
If you need I can dig out the correct error message, anyway I've sent you a little tip since you saved me from upgrading the FPGAs controller
spiccioli.
I've made some progress with my ubuntu server running on the HP thin client.
First I've installed ia32-libs and libftdi-dev:i386 so now I can run xc3sprog directly from it instead of using the virtualbox image I have on a Vista laptop.
Programming FPGA0/3 is still a pain, it took nearly half an hour for FPGA3 to accept twin_test.bit.
I've not re-programmed the FPGAs controller because it seems that it gives more hassles than good.
Right now I'm on Mpbm hashing away at 180 MH/s per FPGA.
Ebereon, thanks for your help and the cairnsmore miner for MPBM, I've changed the icarus one following a previous message of yours, though, since the cairnsmore one gives an error when I start Mpbm that some methods accepts 4 parameters but it has been called with 5.
If you need I can dig out the correct error message, anyway I've sent you a little tip since you saved me from upgrading the FPGAs controller
spiccioli.
I have found MY problem
I 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
@yohan: could that be the problem with SW6 1? Is that the frequency or baud rate?
It cost me some hours to figure it out, if it works for you also, i would be happy if you have some mBTC's 0.0xx... -> 1KWGtSxo5b52Adk3Pvw14E3o9kp96JZJm2
Greets,
eb
I 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
@yohan: could that be the problem with SW6 1? Is that the frequency or baud rate?
It cost me some hours to figure it out, if it works for you also, i would be happy if you have some mBTC's 0.0xx...
-> 1KWGtSxo5b52Adk3Pvw14E3o9kp96JZJm2Greets,
eb
Second board arrived along with the stacking kit. Looking forward to setting up my little tower of power.
Email sent.
Thanks!
Doff
Thanks!
Doff
Can anyone that has a problem email the new support email with the following:
Board serial number
What revision you think the controller is in. If you didn't touch it just say that.
A description of the problem you have.
What OS your host is running.
What your host is, if you know processor etc. that is all useful to know.
We will try and understand or even try and replicate the problems so that they can debugged. We probably won't do much on that until early next week so please be patient. The better bitstream is our priority for the next few days and as a lot of this stuff will change , hopefully for the better, once that is in place.
We don't want to put a lot of time on the "get going" unless that is strictly necessary as it will delay the better stuff. It would be far better for us to move the whole of the software and firmware side forward so that's the effort for the next few days.
I would also like to know who has a unit working ok is with the currently limited bitstreams. This might get us some insight to where problems actually are as much as the problem unit data. I suspect we don't have a major issue and it's all about recognising any weaknesses in combinations of different things and make even as simple as better docs.
Board serial number
What revision you think the controller is in. If you didn't touch it just say that.
A description of the problem you have.
What OS your host is running.
What your host is, if you know processor etc. that is all useful to know.
We will try and understand or even try and replicate the problems so that they can debugged. We probably won't do much on that until early next week so please be patient. The better bitstream is our priority for the next few days and as a lot of this stuff will change , hopefully for the better, once that is in place.
We don't want to put a lot of time on the "get going" unless that is strictly necessary as it will delay the better stuff. It would be far better for us to move the whole of the software and firmware side forward so that's the effort for the next few days.
I would also like to know who has a unit working ok is with the currently limited bitstreams. This might get us some insight to where problems actually are as much as the problem unit data. I suspect we don't have a major issue and it's all about recognising any weaknesses in combinations of different things and make even as simple as better docs.
same here, after programm the controller and programm twin_test it was hashing for about 4 hours at 280Mh/s. After that it was going down to 40Mh/s and i tried to reprogramm it. But i don't got it hashing since that time.
I tried everything, but no luck anymore. If i start EP-cgminer SW6 all on it finds the units and show 380Mh/s but no share is processed. If i start cgminer 2.4.3 SW6 1 off, it only finds 1 unit and no hash.
With mpbm, the unit is no more found, as mpbm sends a test hash to the unit, but that will never be prozessed so mpbm don't find/connect the unit
It looks like we have to wait some more time.
I tried everything, but no luck anymore. If i start EP-cgminer SW6 all on it finds the units and show 380Mh/s but no share is processed. If i start cgminer 2.4.3 SW6 1 off, it only finds 1 unit and no hash.
With mpbm, the unit is no more found, as mpbm sends a test hash to the unit, but that will never be prozessed so mpbm don't find/connect the unit
It looks like we have to wait some more time.
Ramp mine doesn't hash either if it makes you feel any better, I had it going at about 25-50 for a few minutes, then tried to program it one more time and now it just connects and never finds a share.
You should then be hashing
Yeah, I should be hashing Did exactly what you said, and different other things on like 10 or 15 runs altogether. Like before, I guess I will have to wait. 
You should then be hashing
Yeah, I should be hashing Did exactly what you said, and different other things on like 10 or 15 runs altogether. Like before, I guess I will have to wait.We are starting a Cairnsmore1 specific support email address where we can route problems to the best engineer to be able to sort them out. We will also start a FAQ page in the next few days and try and cover common problems there so hopefully whatever you encounter that there is an answer already waiting for most of you. The support email is bitcoin.support AT enterpoint.co.uk.
Yohan
Yohan
This is a great idea, thank you Yohan
Any news on why the SPI flash for the FPGAs isn't working yet when I'm trying to flash the twin_test bitstream permanantly?
Jump to: