FPGA development board "Icarus" - DisContinued/ important announcement

[wildemagic]

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

[1714231188]

1714231188

[1714231188]

1714231188

[1714231188]

1714231188

[1714231188]

1714231188

[luffy]

waiting for your results!
thanks

[kano]

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.

[wildemagic]

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.

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

[kano]

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:

Code:

Icarus %d Re-estimate: Hs=%e W=%e read_count=%d fullnonce=%.3fs

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:

Code:

java API stats

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)

[wildemagic]

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

[kano]

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

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.

[wildemagic]

Thanks again kano, very informative.

kind regards

[DrHaribo]

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 ?

[DrHaribo]

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?

[Energizer]

I've created a new thread to sell my Icarus boards:
https://bitcointalk.org/index.php?topic=90956.0

[ngzhang]

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 ?

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

[luffy]

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"!

[randomguy7]

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"!

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

[tnkflx]

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"!

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

Crazy idea and all, but maybe read the cgminer thread and the cgminer README?

The option you want is "--disable-gpu|-G: Disable GPU mining even if suitable devices exist"

[wildemagic]

Crazy idea and all, but maybe read the cgminer thread and the cgminer README?

The option you want is "--disable-gpu|-G: Disable GPU mining even if suitable devices exist"

Reading the thread will show you that other ppl cant run without the SDK installed regardless of the --disable-gpu

Recompiling without OpenCL is the only way.

kind regards

[tnkflx]

Crazy idea and all, but maybe read the cgminer thread and the cgminer README?

The option you want is "--disable-gpu|-G: Disable GPU mining even if suitable devices exist"

Reading the thread will show you that other ppl cant run without the SDK installed regardless of the --disable-gpu

Recompiling without OpenCL is the only way.

kind regards

I did not know that and now I've learned something, thanks! (SDK is always installed on my machines...)

[wildemagic]

(SDK is always installed on my machines...)

Same, I have a desktop GPU miner and an e350 with integrated.
When I tried to run an FPGA only setup on a p3 tablet I got the OpenCL issue crop up.

kind regards

[kano]

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 ?

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

Can you give an exact answer?
Since that will slightly affect the timing for when the nonce range is aborted and also how many nonces were actually processed when a nonce is found.
i.e. also details of how it affects both FPGAs

[wildemagic]

OK, ive got my xilinx cable to try and update the icarus firmware. BUT, I want to try the .bit file bitstreams before I permanently flash the spi.

Just not sure how to utilise the .bit file to temporarily hash with the icarus unit instead of using the xilinx tools to flash the mcs permanently.

ngzhang outlines in the icarus wiki that you can test the .bit files without writing anything permanently but gives no details.

If anyone can provide more information I would appreciate it, otherwise I only have the v3 bitstream mcs file that works with xilinx tools.

kind regards