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

Back on topic, Ive got 2 of the orders Im about to pay for (test sample ).

Been out off the community for a few weeks (flu) which is a long time in bitcoin terms (wow +$6 ).
Just got the email saying, ready to ship when you are ready to pay, very nice surprise.

100mh with the beta firmware hey ?, lol still they did warn us (what a refreshing show of honesty from a btc FPGA company compared to other unmentionables).

Questions

• How is current firmware development going
• Any news on a new firmware for us to test (if nothing official Im happy with gossip)
• Any settings etc I should be wary of when getting these going ? (dont want to blow them 1st round)

Im impressed how well you kept to the timeline so far, the future looks bright .

Will be organizing payment shortly, Ive been holding off cashing out my banked 500btc while watching the price spike

Thanks for all your help

Moved this to this page in case anyone was looking for it
-----
Daemonic visited me in #cgminer

Looking at his API stats figures certainly suggests it's running at just under 100MH/s
For 99.87MH/s the setting I'd suggest are:

--icarus-timing 10.001=426

10.01 10.001 is ns per hash (100MH/s is exactly 10ns/hash)
420 426 is the number of 1/10ths of a seconds to run up to before it completes (42.6 seconds)

The actual full value to use would be 429 428 (not 420 426)
However, reducing that amount a bit allows for a little leeway in the performance of the FPGA
(the performance affect of reducing that is well below displayed accuracy)

If you want to get these numbers yourself:
cgminer --api-listen --icarus-timing short .....

The timing values will be displayed on the cgminer screen, but you can check them at any time, after the first re-estimate, with the API
If you have java installed, then while cgminer --api-listen is running:
java API stats
Re-estimates are displayed on the cgminer screen like:
Icarus %d Re-estimate: Hs=%e W=%e read_count=%d fullnonce=%.3fs

The API numbers of interest are "Hs" and "read_count"
"Hs" is the seconds per hash (convert it to ns by multiplying by 1000000000.0)
"read_count" is a 1 less than how long it takes to do a full nonce range (in 1/10ths of a second)

You should let it run on a quiet machine for about 4 hours for "short" to complete at 100Mh/s
("long" runs timing forever)

so you get: --icarus-timing Hs*10^9=read_count

I've used 10.01 10.001 for Hs since Daemonic's quick test run was an average of that over 2 sets of data over 2 hours


Now if you want to know if everything is running at ~100MH/s, then U: should be 1.40 +/- 10% after a few hours

Edit: updated above in red after Daemonic has given me his 2hr run stats

moved this to the next page ...

With my approve settings and SW4 1 off, 234 on (this FPGA deactivated) i get ~143Mh/s on my pool. No more invalids  Still invalids ~30%

But the invalids are horrible for the second pair ~60%!

My pool say's 127MH/s.

Yes, I get ~200Mh/s average with SW6 1 off, 234 on with mpbm 115200 baud rate. Only one unit is working when i startup, but when i restart the second unit it will come up and working too. I have to restart the second unit more often to get it working, but then it will work and i get ~200Mh/s.

We were told that the initial bitstream was only 50mhz so that may be why the hashrates are so low even with 2/4 fpgas hashing in icarus mode.

kind regards

I actually added the =short timing and had 3 going, but then it killed my real Icarus and I decided to stop everything and start over without the timing setting. I was afraid I might hose my real Icarus, although Im prolly just being a bit paranoid.

I think ill just hold off and see what Enterpoint brings us this week.

Well, I will add that I've not had anyone come to IRC FreeNode #cgminer who has it hashing and come and ask about the --icarus-timing settings and see if we can make it do better.

I don't have one of these devices and don't expect the people making profit from them will give a rats about me trying to help people with them ... but if someone comes by I'll try help anyway.

But the limit at the moment may not be a timing issue, it may be something else - however I've no idea and also have no details about the device except what everyone here has posted.

(P.S. however if you come to #cgminer right now, unfortunately I have very little time for the next couple of hours - but later should be OK )

I *thought* the Icarus bitstream could, was reported as able to, produce 400mh/s from these things while using only two of the four FPGAs. Is no one getting that?

when started all led near the spartans light up dimmed. after roughly 5 to 10 seconds just the yellow ones come. I guess it means ready/idle/no work, as it goes on after a while when you close cgminer (i guess when the spartans are through with the nonce rage of the workunit).
Also the red ones seem to flash shortly, maybe new received workunit?

(all the while the red one to the power blinks)

I am not sure which ones yohan meant, when he said the red one stands for the frequency. Right now its kind of a secret box, all secrets lifted when the documentation comes around.

Another thing, some people mentioned getting 50MH/s. Is that per "icarus"comport? I have 100Mh/s for both "icarus coms" together (calculated via submitted shares).

Also I read 200Mh/s from someone?

yawn, I became the bad boy of this thread I guess. 

I had bees in my a.., they died some days ago.

Awesomely quiet the last days from my side, wasn't it? just that temperature question, as I thought about running longterm, I thought of fain failure (even though arctic cooling fan should take a long time and probably majorly depend on how dusty the air is) and asked.

And another point covered by enterpoint already temperature and fanspeed readable

Now I am  thinking more about building a filtered air vented enclosure of some kind. Maybe I start with a board to fasten the boards to, like seen from other people and build sth around it.

Also looking forward to the nightly "led" blinking show, especially lotta blue and hopefully no yellow, seems to mean idle right now , so maybe one side with plexiglass? (If its too bright, I can still cover it later on

And after that its a tp-link 3020n with openwrt as a host for cgminer for the boards. Already had one in my hands, and it pulled i think 2.5 Watts or less from the wall with a 3g usbstick. A bit less without the usb stick.

Maybe I will make or contribute to a howto to become one of the good guys again

Recieved my first cairnsmore1 yesterday. Highly impressed with the astonishing development rate, and professional behavior of the company. Keep it up Yohan!

I'll be attempting to get MPBM running under linux with the as shipped bitstream over the next few days.

rampone: please don't be tempted to nag Yohan for bitstreams etc in these early days. In light of their lighting fast dev rate, asking them to hurry up is blatantly ridiculous.

Oh certainly, yes even I'm not expecting cgminer to use these things anywhere near their capacity for now.
I'm just trying to see them working with what's available at the moment.

Yeah you get 4 tty, 2 cgminer doesn't talk to and 2 do. If you do it that way you get 50mhs. I mean obviously EP has the exact way these are going to work, at this point like I said before its just blind fiddling. I'm just going to leave it the way it is for now and take the 100mhs and wait for any updates EP brings later on.

Either way it was fun to see them working.

Is it some sort of USB selection issue?
I think you end up with 4 ttyUSB's (not 100% sure) and if that's the case then you may have to only use 2 of them to get 2 pairs?
So something like:
cgminer -S /dev/ttyUSBx -S /dev/ttyUSBy -S noauto ......
... at a guess ...

In linux with those settings only one FPGA is running but getting 100mhz, I had two going briefly but it didint last long. Ill take what I can get for now.


Doff

I'm very interested for such board. Either with Gigabit Ethernet or PCIe interface, but something with higher bandwidth and lower latency than the USB. At least one chip should be LX150T to achieve that. The chips on the board should be interconnected with each other with whatever means you find cost-efficient to maximize the cross-sectional bandwidth.

If you still haven't fully worked out the dual LX150 board then I urge you to consider connecting every free pin on the Spartans with each other, obeying the differential pair rules.

Thanks.

Just read through all 38 pages of this topic and I'm very impressed with the transparency and constant progress updates. It's a more credible alternative to BFL without all the drama they seem to engage in, and good to see a UK company pushing forward this technology.

I'm more than happy to buy in at this early stage, just hope I'm not too late to the party - email sent!

Keep up the good work