Topic: Cairnsmore1 - Quad XC6SLX150 Board - page 30. (Read 286370 times)

I for one dont believe *** will be able to deliver everything they've promised, especially the 3,5ghs trough usb-power seems far fetched.
My gpu's can take a difficulty of 6,5 million at an exchange rate of 12$ before I need to shutdown. So I'd guesstimate my gpu's go on sale as soon as first reports of ***-products mining.

That's a fairly much seems to be on the worst end of most peoples estimates but everyone has their own numbers. I can only say we don't think it will be anything like that but we could be wrong. Of course if *** actually deliver that 3.5GH/s rate, the price is $149, it actually appears in October in numbers maybe it will be that. I'm not going to try and disagree on something I can at best only guess at. There are still more questions than answers here but only waiting for October and maybe a lot longer will you find out. And when we get there maybe one set of followers will say "I told you so". We will carry on delivering what we promised as best we can and make a better evaluation in October of what return can be had. Remember the GPU rigs have a 5-10X power usage for the similar hashing levels to CM1 rig so by your numbers how many GPU miners will be left by say December. I doubt many if *** are successful.

I did some math when the exchange rate was 12$ and for me (at 0,17$/KWH) about 40million difficulty is the point where I have fairly expensive paperweights, to put it the other way around if the network hashrate goes up 18x.

State of the Nation Time


I have not done one of these for a while so probably time to do one now.

Bitstreams as you all probably know are being done by Glasswalker amd Makomk and we are doing our best to keep up with them to test and support them as much as we can. Our own bitstream development isn't stopped altogether but as these guys are doing so well it is better we put as much of our available resource into supporting them as best we can.

Shipments are going fairly smoothly and about half of September's promised deliveries have been shipped already. We will be asking for the balance to confirm during this coming week as we have to decide both on how much extra silicon to buy and if we can accept any more orders in the near term. Obviously a lot of you if the later shipment promise customers are debating whether you want to go ahead because of ***. If you are uncertain it is better for us that you tell us sooner that later. It does hurt us if we get left with a lot of silicon or boards that are not wanted for whatever reason and if we lose money on this project we won't be doing anything for Bitcoin in the future.

If *** actual produce what they promise it will change the bitcoin market somewhat but not necessarily so much that a CM1 board isn't viable still. There is much more to this that just hashing rates. It may change the return period but my guess is that it will still make a profit. Personnally I still don't think *** have done their own customers much good which is very silly and no good to anyone. I also think the real people to suffer will be GPU miners. GPUs miners banking on good resale values of GPUs might be very dissappointed as well in the next few months. My crystal ball shows resale values dropping through the floor for GPUs if *** are successful.

Some of you are asking how much we have lost to *** and it's difficult to be totally accurate as we are still getting new orders. We always expected a certain amount of drop off anyway with a pre-order system. People do change their mind over a couple of months. I'd probably say 25% as a rough number which sounds a lot but even after that we are still running at x5 the numbers of orders we expected when we started this project. The project has given us a few cashflow issues but that has been managed. We have done projects bigger than this before and that experience has been invaluable in coping with the demand and what goes with that.

Going back to the technical we are now understand the CM1 pretty well and the fixes that the successful bitstreams use are working well with that. Remembering that we are learning about Bitcoin as we go we have learned a lot in the last 16 weeks since we announced the CM1 concept and started the design and manufacture of this product. We believe the "noise" issues that have to worked around in the bitstreams are 80% down to the Spartan-6 packaging which something that we can't do anything about. This 80% is peculiar to the way that hashing causes very large current surges. The 20% part that we can change in PCB design will be incorporated into what we do next as a Bitcoin mining product. The whole "noise" subject is a combination of factors and is not simply one thing or another. It is a combination of various things. On the difference between the early pre 0051 boards and the later post 0050 boards and we think the difference is actually very small and that the better pre-0051 are as good as the lower to mid performance boards post 0050 boards. It's a tolerance band overlap. We also seem now to have bitstreams that can make the worst pre-0051 boards work. We have a "very bad" board working here now as a test platform to help prove out things.

We are getting very stable performance now out of production boards and all production boards get test mined for 1 or 2 days before they ship. Nobody should see an underperforming board now unless there is something peculiar to there setup. We can't cover all possibilities of software, network, or mining pool in our testing but unless a board meets our internal performance marker it doesn't ship to a customer.

During September we will try improve documentation on the various aspects of CM1.

For the future we are looking at what we might do as products for Bitcoin mining and we slowly putting together concepts and seeing what we might do with those. We won't release any information on these until at least October for obvious reasons. We will evaluate if they can compete with *** solutions and if we can compete they will probably be announced. If not some of those ideas will appear in our other product areas and won't be wasted time.

We have been trialling Bitcoin payments for a few weeks and we are ready to start accepting payment this way in a limited fashion. Our biggest concern now in this is that transactions can't be traced as such and we don't want to get into "I sent money" and we say we didn't get it syndrome so we will limit direct taking of Bitcoins to less than GBP £1k equivalent. For the existing pre-order price we will also add a risk/conversion margin of 15% based on Intersango rates. Once we have more experience of this method we may revise the limits or margins but that is what we will offer for now.

There is a second way that Bitcoins can be used to pay us and this way came out of our investigations into using Bitcoins. This method uses Intersango as Bitcoin conversion, other exchanges may be able to do this as well, but Intersango is UK based as that is an advantage in this method. It works on the basis that the customer themselves hold a GBP/Bitcoin account/s at Intersango and convert Bitcoins into GBP. Once in GBP a transfer to our GBP bank account can be done on smaller amounts in less than one banking day and probably 3 days on larger amounts. We are awaiting confirmation of the "faster payments" limit for the 1 day process but we have already done up to several hundred pounds so far as a trial and that works well. The money transfer from Intersango to us should be fully traceable as it is simply a conventional UK bank transfer. Charges for the bank transfer we believe as follows £0-100 -0 £0.20, £100-200 - £1.00, £200+ - free. You can all argue about whether the Intersango converstion rates are competitive and the same for ther commission but we have not found them them to be too bad in what we have done ourselves. We may also ask you add a marker in this sort of transfer and that will simply be a variation in the number of pennies you pay us so we will vary the amount by £0.01 to £0.99. This means we unlikely to get identical payments that we can't 100% determine from whom they came from. All we see is it's from "Intersango" when it arrives in our bank account. We will be interested to how all of you get on with this method. We think this hybrid payment system is very straight forward and provides the tracability that avoid disagreements about whether payments have actually been made.
 
As far as we can tell, and it's a lot more we can find on some exchange operations, Intersango has been good in it's dealings with customers. If you have any experience on that, good or bad, we would be interested in the feedback. This is still an area that we are learning about. The advantage with Intersango being in the UK we do understand what reglatory and business norms apply to businesses operating in our particular backyard.

Trying out a :1:1 setting now

Btw Glasswalker, they all decided to disable themselves like a domino effect around 6am this morning, so they last around 36 hours.
Strangely no Hardware errors, but I did have to cold restart them to get them mining again. (thankfully now they are perma-flash).

Updated the icarus options, So lets see if that changes anything.

Of course, the major consideration / wild-card here is if BFL delivers on their promises and starts shipping ASICs, in volume, in November. If so, none of the current FPGA based products will ever break even on their up front capital expense if buying now.

An interesting 'bet'.  

Personally, I'm hoping BFL fails. (Such a sad attitude.) Just because of what I consider their unethical practices to date have been.

--

Oh, full disclosure, I own one BFL single. Which is operating at 800 MH/s.

And have a pre-order in for two CM's with an estimated delivery date in September. It is really on the razor's edge whether it will be to my advantage/profit/break-even to pay for those two or not.

That seems very 'clean/simple' to me. One USB port per hash producer.

Especially if the auto-clocking / optimizing will work per FPGA. Assurance that whatever the device can do, it will do the best it can.

I should chime in and clarify too. The current released hashvoodoo bitstream (and all future ones) do in fact hash a full nonce range on a single chip.

No worries - just thought I should explain it

I only went off what you said earlier in the thread. Not like I really went into finding out what it did. It has worked beautifully since I done the change.
I will update and try :1:1 next time.

As per the FPGA-README I wrote back when I added the option ...


And yes you can leave values out if you want the default (as given in the example earlier by me and the one above)
  --icarus-options :2:1
Where the baud isn't specified so it uses the default
or even
  --icarus-options ::1
will also default work_division to '2'

So if Glasswalker's bitstream does a full nonce range on a single FPGA, yes indeed it would be
  --icarus-options :1:1
or even
  --icarus-options :1
(both mean the same thing)

In theory, I think Glasswalker's latest bitstreams should work slightly better with --icarus-options :1:1 (:2:1 is for FPGAs configured as an Icarus-like pair with no second FPGA, whereas his are designed to run standalone).

I hadn't expected the pre-emptive erase to be that effective, but since it was I figured it deserved a decent amount of feedback on how to do it.

Excellent! Glad you got it working!

And thanks for posting those instructions, they should help anyone else experiencing similar issues. So it does seem fairly common (your case adds to this) that the other FPGAs on the chain are definitely interfering with jtag operation. So I would say not only my suggestion of flashing in reverse order, but also wiping them all ahead of time should be the "reccomended" way going forward. (in my opinion).

I'll add this to the readme on all future releases.

Also Kano: Wanted to add, that I took both your suggestions:
I've moved the "improved" protocol packet into the tailing 0 block on the data2 block, so that it can't be used to exploit security. And I've improved validation/packet verification some.
And as I mentioned before, I've added your "identify" command, so each chip can now be identified easily via software.

I believe (fingers crossed) that I've solved the problems with the dynamic clocking code.

I've also stepped up the granularity of the DCM a little further (2.5Mhz increments now instead of 3.125, it's more even to work with, and a bit more smooth for tuning).

I'm doing a test build now, so hopefully it will succeed, and I can do another interrim release of that now.

Unfortunately due to the Xilinx tools going haywire, my previous smartxplorer run that's been going now for like 60+ hours, has just died... So I need to restart it.

I'm hoping I can re-run it with this new build if it works as expected.

So the next release may not be a faster version of the non-dynamic one, instead it will likely be an "approximately equal" speed release, but with the improved tweaks and new dynamic clock code, and then later I should have an improved clock version of that one.

Good progress today, Glasswalker

The boards stayed stable over night, they had a few issues with hardware errors according to cgminer, which during all my testing will often appear in small amounts in the first few minutes with atleast 1 error, usually on the last (ica 2/3) ones on the board. However it was stable and still mining at a steady rate of around 9.5u a board.

I choose this time to restart them and look over the manual for Xc3sprog, to confirm what I knew it could do and that was just a quick erase. Hoping this would help me, perma flash them. It worked in the end, fully erasing them all, then restarting and going for a completely clean perma flash got them past verification and mining.
Also no more hardware errors after 2 hours of mining today.

Here was my methods incase it helps others;
I run xc3sprog natively from Ubuntu 12.04, instead of via virtualbox.
I also mine using Cgminer 2.65, with Kano's executable (will upgrade to 2.7 soon).
I use the verbose output in my commands to understand why they fail now, so it is abit different than before.

** Cold shutoff (all power and usb removed)
** Set switches 3 and 6 to off
** Plug in power.
** Wait a minute for it settle and connected usb.

Entered the follow, to confirm they were detected, then wipe them all individually (not sure), then do a all wipe.


** Cold Restart ( Disconnect USB and Power )
** Plug in power.
** Wait a minute for it settle and connected usb.

Then perma-flash it, with verbose out to see where it fails if it does.
* I've shorten the names on all the files for ease of typing them in


*x150.bit was originally xc6lx150.bit (if I remember right)
*hv175oc.bit is the name of the new hashvoodoo bitstream.

** Cold Restart ( Disconnect USB and Power )
** Return all switches to on (move 3 and 6 back)
** Plug in power.
** Wait a minute for it settle and connected usb.

Everyone mines a little different in cgminer, however I've found the icarus setting useful to add when starting up cgminer via the terminal are:


The first one is useful to properly calculate work division and the number of them per port. For Glasswalkers bitsteam this is different than Makomk's, ie it uses all 4 ports for 4 chips, instead of 2 ports for 4 chips. I find the timing set to long rather than short is better, since it hash rate changes all the time in small amounts I figure it's safer to do long.

[Edit:updated the correct options settings]

So in short, taking the extra step to fully erase a board, does fix some issues at the least, if flashing your board is problematic.

That's not a bad idea at all, and could likely be done fairly easily. I'll see if I can add it in quickly in the latest code revision.

EDIT: This has just been added... There is now an "identify" command in the protocol, which takes a single bit as it's parameter. Turn that bit on, and all 4 LEDs on that chip begin flashing in unison, set it to 0 and the LEDs return to their normal operation.

Edit
Though I should add, if someone still wants to send me a CM1 as I was offered by someone who will remain nameless unless they want me to say who they were (I certainly know Yohan wouldn't) then yep I'd be able to try out these bitstreams and get it working in the Icarus code with the new bitstream options
(I said no before to him since I'd be wasting the board and reducing his hash rate and doing very little myself with it - but now the bitstreams/controllers are getting way more reliable it would no longer be a waste)

Oh and Glasswalker - a command to flash a led is also a good idea.
I've been thinking of adding that to the API for BFL to more easily identify which board is which - so being able to do that here would be good too.

Guess I may not have to wait for my JTAG cable then. If the new controllers can bring my 2 boards to 800MH/s instead of 650MH/s it would mean this would give me ~2.5 BTC more at current difficulty in the 3 weeks I expect to wait for the cable. I'll happily give you 1 of them

It looks like I've managed to patch flashrom to flash the controller under Linux, fingers crossed. PMed Yohan and am waiting to hear what he thinks.

Good point, suppose they could be interfere with each other. One of those long shots I can't rule out.
They seem to be happy doing about 1.4 Gh/s and apparently less than 0.01% invalids so if it's stable for a few days I won't have anything to worry about. Look forward to improvements in the bitstream, kinda like making full use of 4 comm ports for each board.