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

If your U:rate is 10-11 then its doing 800Mh/s, but more likely its doing alot less than that.
Most users are reporting between U:1-4 per board.

kind regards

Just quoting this, since the command line stuff was useful for me to start getting these working for me.
Needed to modify mine for the right com ports. Will provide feedback and results later today.

Just got my 2 boards. Doing one at a time, I'm sure the other works fine.
Got one working and flashed to latest bitstream. CGminer tells me it's hashing away at 825Mhash/s, so I'll wait for my pool to confirm this.

Should be a non event, every other mining fpga plugs into a usb port, hardware issues aside, if it works on one pc it should work on another.
I dont think its appropriate to blame your end users.  You have even gone as far as to tell people to cut usb cables and modify them blaming vague power issues.

I think you need be honest with your end users instead of hiding behind hyperbole.

Others in this thread think you have a fab reputation based on your communication here minute to minute, but I think they were just drawn in by the chance to get a quad lx150 for $650.
The reality is going to set in soon that they have been taken for a ride unless you get the hardware performing.  You need to get a working bitstream out.

The whole 'we dont have the time' excuse for not yet having a working bitstream is starting to sound a bit 'broken record'

Are you actively working with Elden to get the tricone bitstream working? Or did you give him just enough information to get him started?
You made comments that alluded to it being a done thing, why then are other users unable to get it working?

kind regards

It's definately not the case that "customers are on their own" or will be but there are finite resources right now. I would put it that it will be more a slow down in support response time this week but it's for the greater good towards the goal of better performance and reliablity. Anyone who does have a Cairnsmore1 problem should still send us as much information about their issue as they can to our "bitcoin.support" email. That way we have a track record of it and hopefully don't miss it. Unless you have done developments like this yourself before it's not easy to imagine what goes on here as a development task as complex as Cairnsmore1 or even the support issues of dealing with hundreds or even thousands of possible rig hardware/software combinations used with the product.

I also suggest you don't try to discount / disregard the until '800 MH/s is reached' price statement.

Enterpoint needs to either honor that, or you need to confess that you spoke out of school and Enterpoint is not bound by your statements. (As distasteful as that might be.)

This audience has been hyper-sensitized to stated commitments which are not subsequently honored. Perhaps not fair to Enterpoint, but it is what it is.

Enterpoint's biggest advantage at this point is the reputation you have established in this forum. It might be a bitter pill, but that reputation needs to be upheld or take a hit.

Meanwhile my Single from America is happily hashing away at 815MH/s

A fair reply, thank you.
And thank you for your continued contributions / presence in this forum.

I do suggest that, as you have already indicated you're switching over to, a de-emphasis needs to be placed on support - to a near level of nothing - and the admittedly finite resources prioritized to internal/primary product development and tuning. Of course, you have to make a judgement call as to how much this 'support' effort provides value to knowing what changes/revisions are required in the core hardware/firmware.

Everyone who has one of these in hand now purchased it under the statement that 'you are on your own', you are expected to be able to break your own trail or be patient until better firmware comes out. It was sold as 'beta' / 'developer's toy' with no commitments to any level of performance.

IOWs, current owners can make it better via their own resources or hold their horses until improvements are ready for general availability.

Also, IOWs, I approve of how Enterpoint has been doing business. I know it is hard to ignore the cries for assistance from current, pre-release, customers, but priorities must be set and followed.

--

However, I really do appreciate the much improved graphics and documentation about DIP switch settings / behavior and the other incremental releases of 'stuff'.

Whatever can be done in parallel without jeopardizing mainline progress is a good thing.

That's fair enough.

I also don't want to get too distracted on all of this and actually keep moving our product forward and I think we are doing that. I know that is not always visible to the forum but it is happening. Also I can't make a specific promise (or I will get balled out that) but 800 MH/s switchover might be academic anyhow in not so distant future.

What I might do if I find a little time is a quick pass though pin adapting design for the first FPGA in the pairs and show the back FPGAs working as half Icarus. That will shown that tha back half is at least as good the front and maybe if we need to do a little more work on the controller for that. I think we are ok already on the latter but a further check does not do any harm. Ok it's not a total answer but it might calm any uncertainty about what we have as a hardware platform.

BTW, yohan, it is really not my intent to bust your balls about this.

IMO, you / Enterpoint have been vastly more upfront in communications than 'that other company'.

I'm merely trying to keep the story straight.

"The second decision is that until the we reach 800 MH/s on Cairnsmore1 the offer price will be available for any new orders. The 800 MH/s performance can be by any available bitstream and that changeover is at our sole discretion."

https://bitcointalksearch.org/topic/m.973986

The very first post of this thread has this and I don't think this has been materially changed since the thread started..

We have listened to your comments on Merrick6 (see other thread) and are going to create a board specifically for Bitcoin with 4 XC6SLX150-2FGGG484C FPGAs. The price guaranteed until the end of June 2012 is GBP £400 / USD 640 / 520 Euros (plus tax and shipping). We are selling at the cost to manufacture price until we do the work of benchmarking it and check it working with the Bitcoin interface software. After we complete the benchmarking/software work the price will increase by 50% to cover our costs in doing this work and general support.

To get the initial price we need to receive an order before the end of June. You price and order will be confirmed to you by email. We may extend this offer at our sole discretion. Payment will be by PayPal or by bank transfer.

Prices are based on current exchange rates or staying within 5% of current rates.

We will accept pre-orders on the basis that no money will be charged until your board is ready to ship. We reserve the right not to sell to any person or organisation and/or to ask for more information in respect of and for export control. To pre order send an email to bitcoin AT enterpoint DOT co DOT uk with address and contact details.

UK shipping cost is £8 + VAT. EEC 32€ + VAT, US $40. Please ask for other places.

Local duties and any applying taxes will be charged direct to you by courier. For UK and EEC we will charge UK VAT unless you are VAT registered in your country (not UK).

We expect to complete the design for this board by the 1st of May 2012. We will show some CAD images of the board then. First production boards will ship towards the end of May although some lucky people may get them earlier. I will announce image availability on this forum.

The spec of the board is as follows:

FPGA - 4 x XC6SLX150-2FGG484C
Heatsinks - stick on or clip on supplied with single 12cm fan(with mount pillars) to blow over all
Size - approximately 15cm x 15cm.
Programming - with our Prog3 cable (£50/$80/65€) or similar. We may add this interface into board as standard.
Data transfer - FT4232 USB interface. Each FPGA has a port.
PCB - 4-8 layer
Power input - 12V from Jack or disk drive (Molex)
SPI Flash - We will have local FPGA image storage so you don't need to JTAG load every time.
Clock - single oscillator or clock generator.
Core voltage - 4 regulators each 12A

There is no performance specification on the Cairnsmore1 website pages as far as I remember or every has been and all we have talked about in terms of performance that we expect to attain is somewhere in this thread.

As to your specific performance issues have you sent an email to Enterpoint outlining the problem. If we have missed that I do apologise and do send it again to us. We can't fix what we don't know about. You might have a hardware fault or there might be something else causing you an issue so tell us about it. We are slowly working our way through support items as best we can and we will take action based on a custom need.

There is something about 700-800 MH/s and the price switch somewhere in this thread. I probably said also at our discretion. I'll struggle to find that now and by all means do quote what I actually said. But it's a fact that it is our choice what we sell a product at and when we change prices. It's not like we didn't warn that there would be a price change. That was said on day1 in the first post.

"Pricing we said we would hold until end of June initially"
True.

My guess is that what surprises some people is the subsequent statement, IIRC, was that the original pricing would hold until a proven 800mh/s performance level was reached on the shipping hardware.

IMO, some see that as a statement / commitment which has not been honored.

Of course, please correct me if such a subsequent statement was never made.

Hi Yohan,
I think you could have been a bit clearer on this. I may have been a bit rash in buying this, but it was described as a board 'specifically for Bitcoin' - and I guess it wasn't in my expectations that I'd need to closely follow a 68+ page thread on the forum to know the state of things. Perhaps because I have only been checking a couple of times a week - I'm still not clear about what the board is currently capable of nor how to achieve it.

Currently I'm running mine stock at around 100MH because the processes for eeking out a bit more looked pretty problematic, and nowhere near the target 800MH yet anyway as far as I could see.
As it stands I don't know if I'm supposed to be monitoring the page at http://www.enterpoint.co.uk/cairnsmore/cairnsmore1.html, this thread,  or some other thread for a completely 3rd party bitstream solution (??)

Actually what I don't like about you posts is that you have nothing useful to either us or other customers to add and just seem to trolling and making the tread even harder to follow.

I have absolutely no problem with genuine customers posting grievances here but I would also like the same information passed to our support email so we can try and sort out issues. Our support mechanism runs mainly on that not on this forum thread. The team simply don't the time to read the thread and get anything done. I will attempt to pass information accross the gap but I don't have infinate time to do it and it's very easy to miss something when the tread is busy or cluttered. I'm also not an expert in everything and that can mean I don't necessarily have a full understanding to always convey problems accurately to the team. I have said previously that we will talk about any problem or design flaw and that continues to be the case.

I also don't have problem with customers and knowledgeable people spreading useful information that improves things for customers. Our own support mechanism can't cope with all possibilities platforms, OSs and software.

There are no major hardware design problems quite the contrary. Given the aggressive development cycle we now have a very good design for the purpose. There are probably a small percentage of genuine hardware faults (we need to see boards to confirm) and we have extended and intensified our board testing to try and catch any future ones before they leave us to go to customers. The last thing we want is customers recieving faulty boards. We are swapping out any faulty boards as fast as we can after we try and do some level of diagnostic with the customer to try understand the problem and to try and identify if it is likely to be hardware or software. This is also part of our development process that we understand problems and if there are any holes in our hardware test strategy we improve the testing. We can't even hope to model all environmental circumstances customers have in our testing but we can certainly always make it better. Once we have a few "faulty" boards back in the lab we will look further to see what problems they do have and learn from that.

To third party software I wasn't blaming everything on those items and I recognise the hard work many people put into these items. It was merely a statement of fact. However it is a fact of life that there are previously undetected bugs or new ones that occur with OS updates or even new bugs that peculiar to a individual customer setup. We don't have test suites for all possible combinations out there and we can't stop the roll of OS updates, driver updates, and new hardware platforms but it is something that we have to try and deal with. It all takes time to work with. In this initial phase we have tried limit the possibilities we have to deal with by say initially just supporting CGminer and not actively supporting ETs bitstream. That is only a recognition that we have a finite sized team to deal with issues and there is only 24 hours in any one day. It is also a fact that the more support work we do the less progress we make with new things. It is the same people doing the work.Last weerk we did a lot of support work and didn't make much progress on new things like the bitstream. This week we will try and move the balance a little more to new development items.

Pricing we said we would hold until end of June initially and then we have extended up to now. It may be that ET's bitstream isn't working and we might be wrong in that change based on that. We are not actively involved on that development so only know a limited amount. But it is no real effect on existing customers so you are not being asked for more money on existing orders. We do need to change pricing at some point to cover our costs in supporting this product. If we don't cover our costs or make some small profit there is absolutely no reason to be in the Bitcoin market. There is after all a legal obligation here to make a return for our shareholders not a loss. Thatr's a commercial fact of life. You can argue whether the new pricing is justifable for your ROI but there is no obligation to buy from us and you can buy competitor kit if that is what you want to do. The market will prevail in this respect.

These number are incorrect with my worker. My worker is only correct for the 190Mh bitstreams (SW6#1 off!). The interval that is detected is wrong here also. For shipping bitstream please use the icarus worker, it should show correct numbers.

The detected Mh/s is completly different each start of the worker, but after some seconds it will show you the correct Mh/s in the website of mpbm.
The Watchdog message come from my changes in the timings, the original timings wait ~3 times longer until it restarts the worker. It could be realy normal to get that message from time to time. But if you can watch the LED's and if you get the message when the orange LED is turned on, you will notice that then it turn off. this is the behavor I had on my board#0015. And my shorten timings make sure the board don't have the orange LED (no work/job) to long.


Please take a look at the mpbm webconfiguration, the interessting part are the invalid shares, they must be realy high on your board or the Watchdog messages come really often (orange LED turn on very often).

eb

On the other hand, however, perhaps they have a proven solution 'in hand' and need to announce the price increase before the solution lest they get flooded with orders at the 'at cost' / 'at a loss' price point.

I was quite surprised by that announcement. I have seen no proof that there is a way to currently get, at least, 800mh/s out of these things. With the new price structure and basically a statement of "trust us, we'll make it right" they have now placed themselves essentially in the same position of a notable other seller of mining hardware.

Indeed, especially with Yohan's hostile reactions I would presume there is something really wrong with the hardware.

This has been confirmed by the multitude of different customers with identical devices reporting all sorts of issues.
I doubt a new bitstream is going to cure what clearly appears to be hardware deficiencies.

I do hope they get things sorted out as the hardware looks really good, potentially with a good bitstream it might be one of the best fpga offerings.

BUT, now that the price has been jacked up and things are still far from optimal, other designs are looking superior.

kind regards

Is anyone else seeing any similar issues to the below with their board?

Mine is 62-0018 updated to rev 1.3; Ive also tried 2 different machines and multiple different usb leads, all of which seem to give similar results;

(All excerpts below are from latest git MPBM with ebereon's Cairnsmore worker.)

For starters my job intervals seem way off compared to the likes of ebereon's previously posted.

shipping_test.bit (DIP's setup as per shipping_test.pdf)
 Permanent Flash;

twin_test.bit (DIP's setup as per twin_test.pdf)
 Temporary Flash
 Notes
   CM2 (FPGA3) gets 50-70% less shares than CM1 (FPGA0) (Average Utility of 1.4-1.5 & 0.8-0.9)
   Also quite a few of the following errors on both FPGA's
Permanent Flash;
 Notes
   CM2 (FPGA3) gets 50-70% less shares than CM1 (FPGA0) (Average Utility of 1.4-1.5 & 0.8-0.9)
   Also quite a few of the following errors on both FPGA's
    Watchdog triggered: 27276.511018 MHashes without share

190M_V3.bit (DIP's setup as per twin_test.pdf)
 Temporary Flash
 Notes
   First few shares ok, then;
Permanent Flash
  Not even detected

200M_BETA.bit (DIP's setup as per twin_test.pdf)
 Temporary Flash
  Not even detected
 Permanent Flash
  Not even detected

I know we're not at full potential, and no sign of any full potential yet, but id at least like to get this one board working ok before i dump a load more cash into more boards

Um excuse me but don't blame your shit on cgminer.
The version you are recommending to your customers is your fault - not done by cgminer devs.

I've had no access to the hardware at all and at least got something that sorta worked without ANY support from you or your team.

Wow sounds like something isn't going right and trying to stick the blame elsewhere ...