Topic: FPGA development board "Icarus" - DisContinued/ important announcement - page 4. (Read 207279 times)

Do you GPU mine on that box, too? If not, I'd recommend to compile cgminer from source disabling GPU support.

i tried to run icarus with cgminer in an ATOM laptop but cgminer said "no opencl.ddl available" something like that.  what can i do?
i tried to load opencl sdk from microsoft but i see the message "no opencl capable GPU, instalation abort"!

yes， it didn't scan the nonce range form 0. approx: 132

I've created a new thread to sell my Icarus boards:
https://bitcointalksearch.org/topic/sold-discounted-icarus-fpga-for-sale-90956

Nonces starting with three nullbytes (0x000000??) are never reported. Nonces starting with three FF (0xFFFFFF??) always get 01 for the fourth byte, which is usually an incorrect result. This had me confused for a while. Error in the bitstream?

Adding Icarus support to my miner. But I can't get it to ever return a nonce starting with three null bytes. I feed it data for which there is such a solution, but it's not working.

Is that normal? Does it start scanning from nonce 0x00000100 ?

Thanks again kano, very informative.

kind regards

Well the complete recalc in 'short' mode should only take about an hour or so
and you can look at the 2nd value it spits out after about 5 minutes and that will tell you roughly what it is.

However, if you don't care about the MH/s display being correct, you can simply tell it the abort time.
e.g. --icarus-timing 2.5=80
That tells it to assume 2.5ns per hash and abort at 8.0 seconds.
2.5ns would actually come up as 10.6seconds, but giving it less will ensure you are under the required limit.
The wrong nanoseconds wont affect the number of shares you get (U:) if you also have a valid abort time, but it will display the MH/s wrong if 2.5 isn't close to the correct value.

The abort time can be as low as you like.
The only loss from having the abort value too low is the overhead of starting extra work.
When a miner checks a nonce range it doesn't matter if it aborts early - there is no statistical loss of shares or blocks when you don't check the full nonce range.
You will of course expect to find (on average) one share every time you check 2^32 nonce values, but it doesn't matter if they are from different getworks - it's simply how many nonce values you check, not which ones you check.

Thanks kano, I appreciate the in-depth reply.

Since the only other bistream is a 200mhz as compared to a 190mhz, any problem with just a down and dirty 5% alteration to the timing rather than a recalc by the miner software ?

kind regards

I wrote all the Icarus timing code in cgminer and all the code that adjusts it (and redesigned all of that in the Icarus code)
So yeah the following is correct

The current code defaults to 11.2 seconds (not 11.3s) before aborting the work and starting again
It gives a little lea way of 1 unit of time (1/10sec) in case there are any processing delays

However, 11.2s is calculated based on the Icarus mining at 2.6316ns per hash
(which of course means 5.2632ns per pair of hashes)

i.e. (2^32 * 2.6316 * 10^-9) - 0.1 = 11.20...

What it will also mean is: if you are hashing faster, and complete the nonce range without finding a valid nonce before 11.2s, then the icarus will be idle for "11.2 - however long it takes to complete the nonce range" each time that happens.

So the correct value in place of 2.6316ns, will ensure it isn't ever completing and waiting for new work.
It would only have to be 1% faster to end up waiting.

The second thing that the correct nanosecond value does, is help cgminer to calculate the correct MH/s value.
With the correct value, it knows how many hashes it has done when it aborts the work (at 11.2s in the current settings)
If it doesn't have the correct nanosecond value, it will report the MH/s incorrectly (hi or low depending on the speed of the bitstream)

The option: --icarus-timing short (or long) tells the code to work out the correct values and use them.
N.B. you will get a message on the screen each time it re-estimates the values, like:
The first %d is just the Icarus ID number
The Hs=%e is the hash nanosecond time it has calculated (in place of 2.6316 * 10^-9)
The W=%e is the code overhead per work
The read_count=%d is the new replacement value for 11.2 (times ten)
The fullnonce=%.3fs is how long it actually takes to complete a full nonce range

You can also ask the API for the current values it is using:

Once you have a new correct nanosecond value for your faster bitstream (lets say it was 2.2222ns), you simply start cgminer with the option:
--icarus-timing 2.2222

Of course if you have any trouble with this, come visit FreeNode IRC #cgminer - I'm almost always logged into it as 'kanoi' (but not always available to help but I will see the messages later if I'm asleep or elsewhere)

I believe this was worked out to be 11.3 from reading this thread.

Is it still ok to just leave cgminer and it will work it out even with the 200mhz bitstream as apposed to the 190mhz default?

I currently run cgminer with no extra timing options and after an hour it seems to settle on the correct speed to report.

I was under the impression that cgminer works it out over time even with no timing switches.

kind regards

Don't forget if you use cgminer, to use "--icarus-timing short" (or "--icarus-timing long")
... since a faster bitstream will of course have a different timing
The result of the timing (if it's correct due to being run on a quiet computer) can be fed into "--icarus-timing nanosectime" every time after that so you don't need to get cgminer to work it out ('short' or 'long') and thus cgminer will use the proper timing from the start.

waiting for your results!
thanks

Got a xilinx kit on the way, will test the v3,v4 and 200mhz streams to see if there are any improvements.

At the moment they are v2,v3,v3,v3.  I think a cooling upgrade is in order, the default fans have a bit to be desired.

It gets about 40c here in summer so i think they are going to struggle in that kind of heat.

kind regards

Im pretty sure you need the dev xilinx cable and software.

Not sure tho as I dont have it (yet).

The instructions on ngzhang's link here : https://github.com/ngzhang/Icarus/blob/master/Downloads/bitsteam/guide%20for%20flash%20update.txt suggest that the cable is required.

kind regards

what is the procedure of loading a different bitstrwam? is it possible from the PC via USB?

Has anyone tried the 200mhz bitstream on the v2 or v3 hardware?

Just wondering what the results were?

I assume some extra cooling may be required.

kind regards

I have PM'd ngzhang, but if anyone else can answer my query I would be most appreciative.

What voltage input does icarus work from?
I have a bench power supply that is 12v 10A and works at 13.8v.  Will this work with my 4 icarus?

I have 1xv2 and 3xv3 icarus.
I have heard that other hardware works from 5v-15v input, but Im sure its different from manufacturer to manufacturer.

[update] Reply from ngzhang :


kind regards

no... i will test them myself...

My guess is xiangfu is selling his Icarus to make room for the Lancelots he'll be testing for ngzhang.