FPGA development board "Icarus" - DisContinued/ important announcement

[TheSeven]

Beware of cheap power meters that don't measure the power factor.
I have one that seems to just measure the current at one certain point of the sine wave.
The current drawn by non-PFC switching power supplies (what most of those wallwarts are nowadays) is not proportional to the voltage, so such a meter will usually measure random crap if it doesn't measure the current at lots of points distributed across the voltage sine wave.
If I plug some switching power supply into mine, it shows a certain number of watts. If I additionally plug some (idle) good old halogen transformer, the wattage shown by the meter actually decreases! Pretty reliable sign that the meter is doing a very bad job.

[1714288240]

1714288240

[1714288240]

1714288240

[1714288240]

1714288240

[1714288240]

1714288240

[1714288240]

1714288240

[1714288240]

1714288240

[kano]

I've tested with each of my 2 powerpack + Icarus boards
Both show 23.1 to 23.4 watts.

With just the plugpack alone - the meter shows 1.1 Watts.

I wouldn't say the plugpacks are 'hot' - but they're warmer than various other plugpacks I have running switches etc.


edit: This is the meter I'm using - http://wattsclever.com/product/energy-watch-monitor-EW5001

Heh - same one I've got but mine is showing a total 60W increase at the power point for 2 Icarus connected to a computer.
Maybe they aren't as reliable as I thought they were?
Anyway - as I mentioned, if I get around to making a molex cable that will answer if that's the watt meter or the plug pack.
Hmm actually my 2 plug pack China<->Aus adapters also have surge protection so that may be a few watts each also ...

[Defkin]

I've tested with each of my 2 powerpack + Icarus boards
Both show 23.1 to 23.4 watts.

With just the plugpack alone - the meter shows 1.1 Watts.

I wouldn't say the plugpacks are 'hot' - but they're warmer than various other plugpacks I have running switches etc.


edit: This is the meter I'm using - http://wattsclever.com/product/energy-watch-monitor-EW5001

Heh - same one I've got but mine is showing a total 60W increase at the power point for 2 Icarus connected to a computer.
Maybe they aren't as reliable as I thought they were?
Anyway - as I mentioned, if I get around to making a molex cable that will answer if that's the watt meter or the plug pack.
Hmm actually my 2 plug pack China<->Aus adapters also have surge protection so that may be a few watts each also ...

I used pliers to convert the plug packs to AUS style pins, no adapter required.

Have to agree that the meter must be giving bad readings as I measure the boards as less than 20w

[Dhomochevsky]

Well, I received today my two first FPGA boards, after a week and some change of transit. The packaging was excellent. Right now they're hashing along for about 3 hours on ABCpool. I use RG7 miner (the Python ones are a bit out of my league for now, but I'll start messing around with them soon enough). The speeds I'm getting (as reported by ABCpool) range from as low as 300 to as high as 510 - I'm sure it's just some kind of misreporting, I don't think these things can go that high... can they? Regarding temperatures - they seem to heat up to 70-75 degrees as far as I can tell when touching the back of the PCB underneath the chips. I really need to get an infrared thermometer or some kind of thermal probes. I occasionally get connection drops (see picture), but they don't affect efficiency as far as I can tell. And it's probably because of my connection anyway.

Here they are, going at it:


 

[Turbor]

I miss a simple and reliable miner for windows 7. RG7Miner works but it sends the board to "eternal sleep mode" way too often. With CGminer i get about 5 shares from icarus accepted, then it freezes somehow A step by step guide for idiots would be nice. 

[Dhomochevsky]

Yes, that would be a nice thing to have, but for now the best we can do is experiment and discover how this stuff works/how to optimize it and hope we don't fry an expensive piece of equipment in the process .

[randomguy7]

To get rid off the error in your screenshot, add "59" as an additional parameter after the port name (without quotes). This is required for mining on abcpool. For some reason which I still could not figure out lp timeouts on abcpool don't work correctly if the timeout is set to 60 seconds or higher (default is 600s).
Starting without parameters (java -jar <miner>.jar) gives info about all possible parameters.

Well, I received today my two first FPGA boards, after a week and some change of transit. The packaging was excellent. Right now they're hashing along for about 3 hours on ABCpool. I use RG7 miner (the Python ones are a bit out of my league for now, but I'll start messing around with them soon enough). The speeds I'm getting (as reported by ABCpool) range from as low as 300 to as high as 510 - I'm sure it's just some kind of misreporting, I don't think these things can go that high... can they? Regarding temperatures - they seem to heat up to 70-75 degrees as far as I can tell when touching the back of the PCB underneath the chips. I really need to get an infrared thermometer or some kind of thermal probes. I occasionally get connection drops (see picture), but they don't affect efficiency as far as I can tell. And it's probably because of my connection anyway.
...

[ngzhang]

Well, I received today my two first FPGA boards, after a week and some change of transit. The packaging was excellent. Right now they're hashing along for about 3 hours on ABCpool. I use RG7 miner (the Python ones are a bit out of my league for now, but I'll start messing around with them soon enough). The speeds I'm getting (as reported by ABCpool) range from as low as 300 to as high as 510 - I'm sure it's just some kind of misreporting, I don't think these things can go that high... can they? Regarding temperatures - they seem to heat up to 70-75 degrees as far as I can tell when touching the back of the PCB underneath the chips. I really need to get an infrared thermometer or some kind of thermal probes. I occasionally get connection drops (see picture), but they don't affect efficiency as far as I can tell. And it's probably because of my connection anyway.

Here they are, going at it:


 

hi, please notice if the heat-sink is installed firmly on the chip. the invalid rate "should" no more than 0.2% (in 24 hours), and 0.1% is typical (caused by communication, 6ms communication time in average 6s, so 0.1% work on garbage, this will be fix in next version of firmware).

press the heat sink to fix it.

by my test for 18 boards, the highest one is 0.17% invalid rate, 0.1% in average. under MBPM.

[kano]

Hmm is it the USB protocol being used or a software bug in MBPM?

My 5 day non-stop run so far with 2 Icarus boards has 0 "Hardware errors" in cgminer.

In cgminer a "Hardware error" means a nonce returned that's no good (invalid).
I presume that is what you are referring to?
(cgminer uses serial access on top of USB to Icarus and Bitforce)

[ngzhang]

Hmm is it the USB protocol being used or a software bug in MBPM?

My 5 day non-stop run so far with 2 Icarus boards has 0 "Hardware errors" in cgminer.

In cgminer a "Hardware error" means a nonce returned that's no good (invalid).
I presume that is what you are referring to?
(cgminer uses serial access on top of USB to Icarus and Bitforce)

yes , i think the protocol have some problems. i check the invalid shares, all looks like "XXXX0000", 4 of zeros in hex.

a real hardware error should looks like "XXXXXXXX",  no regular.

[TheSeven]

yes , i think the protocol have some problems. i check the invalid shares, all looks like "XXXX0000", 4 of zeros in hex.

a real hardware error should looks like "XXXXXXXX",  no regular.

If the board increments the nonce in the opposite endianness of the value that the miner shows, this would mean that this was once of the very low nonce numbers being processed very shortly after, or even during, a work upload. It's no surprise that nonces found during work upload are garbage

cgminer probably just filters them out somehow, which doesn't make the underlying protocol issue any better.

[kano]

yes , i think the protocol have some problems. i check the invalid shares, all looks like "XXXX0000", 4 of zeros in hex.

a real hardware error should looks like "XXXXXXXX",  no regular.

If the board increments the nonce in the opposite endianness of the value that the miner shows, this would mean that this was once of the very low nonce numbers being processed very shortly after, or even during, a work upload. It's no surprise that nonces found during work upload are garbage

cgminer probably just filters them out somehow, which doesn't make the underlying protocol issue any better.

cgminer doesn't filter out anything.

It does however (as I have said) use serial over USB, not direct USB.
So the underlying OS code resolves the issue of writing data to the Icarus at the same time the Icarus may be replying.
(and I'd also expect the OS code to be WAY better designed at handling that)
This obviously has yet to cause an error for me (hardware errors=0)

If there was a nonce coming back during the picosecond that it starts a new work (writing over the old running work) it would of course be lost.
However that would be something like only a few in 4 billion (2^32) chance of that happening.
cgminer aborts the work at a point before it completes since it doesn't know when the work will complete.

So when cgminer reaches 4 billion shares - yep you may have lost a few
i.e. cgminer may lose roughly a few shares roughly every 2,500 blocks ...

Edit: also - no it increments the nonce in the normal direction - i.e. an early nonce returned means a low nonce value & 0x7fffffff

[TheSeven]

cgminer doesn't filter out anything.

It does however (as I have said) use serial over USB, not direct USB.
So the underlying OS code resolves the issue of writing data to the Icarus at the same time the Icarus may be replying.
(and I'd also expect the OS code to be WAY better designed at handling that)
This obviously has yet to cause an error for me (hardware errors=0)

MPBM is no different regarding that, using PySerial to access the board.
Also the up and downstreams of a serial port are completely independent, reading while writing should not be an issue.

If there was a nonce coming back during the picosecond that it starts a new work (writing over the old running work) it would of course be lost.
However that would be something like only a few in 4 billion (2^32) chance of that happening.
cgminer aborts the work at a point before it completes since it doesn't know when the work will complete.

So when cgminer reaches 4 billion shares - yep you may have lost a few
i.e. cgminer may lose roughly a few shares roughly every 2,500 blocks ...

That's not entirely true. The job upload packet is 64 bytes, which is 640 bits on the serial link at 115200 baud, so that's 5.56ms.
During that time, the internal shift register of the Icarus contains invalid data, and thus there's a timeframe of 5.56ms during which the Icarus works on a garbage job, and keeps resetting the nonce over and over again. This alone causes at minimum 0.05% invalids, a bit more if you cancel work rather early.
The maximum nonce value (ignoring the MSB) that an invalid nonce caused by this could have is probably 0x0000406e, which would match the pattern that was reported above if the endianness was reversed and the MSB was ignored.

Edit: also - no it increments the nonce in the normal direction - i.e. an early nonce returned means a low nonce value & 0x7fffffff

MPBM shows the nonces in getwork notation, so that might be byteswapped compared to what the device is actually doing.

Do all those invalids reported by MPBM match the pattern XX[0-4]X00[08]0?
It could also be possible that MPBM is associating nonces received with the wrong job if they are close to a job switch, because there is no hardware feedback about a job switch in the current protocol. But I can't really explain that specific nonce pattern that way.
I'll have a closer look at that when reimplementing the Icarus module for MPBM v0.1.x, which should happen during the next couple of days (as soon as I receive my board).

[Dhomochevsky]

hi, please notice if the heat-sink is installed firmly on the chip. the invalid rate "should" no more than 0.2% (in 24 hours), and 0.1% is typical (caused by communication, 6ms communication time in average 6s, so 0.1% work on garbage, this will be fix in next version of firmware).

press the heat sink to fix it.

by my test for 18 boards, the highest one is 0.17% invalid rate, 0.1% in average. under MBPM.

The heatsinks are firmly fixed on the chips, so no problem there. However, I think I can safely ignore that output from RG7miner, because the pool reports I actually have only 0.12% stale and 0.04% invalid. Like Randomguy said above, I can do some optimising with parameters to improve the output, but since all that matters is what the pool reports, I think everything is ok for now.


[edit]

I seem to remember somewhere in this thread a discussion about overheating - assuming the ambient temperature is ~20 degrees all the time, can these things actually overheat if they're used normally? What is the maximum temperature these chips can take (TJmax or smthng)? I assume there's no throttling solution in place, so if one of them starts overheating there's gonna be trouble. What is a worst case scenario?

[Turbor]

My invalids have always been around 1% with RG7Miner. There must be some little problem. Seems to be connected with that eternal sleeping mode where the board only produces invalids. I'm 99% sure that this is not hardware releated because when you restart the miner all works ok. Sadly it's unpredictable.

[Dhomochevsky]

That's strange. I use RG7Miner too and so far (~18 hours of continuous mining on ABCpool) I never got anything that resembles the "sleeping mode" you describe. What pool are you on? Maybe it has something to do with them? Maybe it has something to do with your connection? Is it stable enough? Maybe the pool was under some sort of ddos attack when your boards displayed that error?

[edit] - I managed to replicate your error by turning off the board then turning it back on without stopping the miner. Every share after that was invalid until I stopped and restarted the miner. Maybe there's some sort of power interruptions on the supply line and your board turns off briefly.

[kano]

...

If there was a nonce coming back during the picosecond that it starts a new work (writing over the old running work) it would of course be lost.
However that would be something like only a few in 4 billion (2^32) chance of that happening.
cgminer aborts the work at a point before it completes since it doesn't know when the work will complete.

So when cgminer reaches 4 billion shares - yep you may have lost a few
i.e. cgminer may lose roughly a few shares roughly every 2,500 blocks ...

That's not entirely true. The job upload packet is 64 bytes, which is 640 bits on the serial link at 115200 baud, so that's 5.56ms.
During that time, the internal shift register of the Icarus contains invalid data, and thus there's a timeframe of 5.56ms during which the Icarus works on a garbage job, and keeps resetting the nonce over and over again. This alone causes at minimum 0.05% invalids, a bit more if you cancel work rather early.
The maximum nonce value (ignoring the MSB) that an invalid nonce caused by this could have is probably 0x0000406e, which would match the pattern that was reported above if the endianness was reversed and the MSB was ignored.
...

I'm referring to how cgminer works.
It gets a timeout, checks the count of how many timeouts and if it has reached some limit it will then go through the process of starting fresh work (that cgminer already has queued ready to go)
Then it starts to write new work down on the Icarus.

Are you suggesting that there is some period of time AFTER it starts to write the new work to the Icarus that a valid nonce could be returned?
If so then I guess we could add that to cgminer also, but that time would need to be VERY accurate to ensure the old reader isn't taking a nonce from the new work.

Icarus hashes a pair of nonce in roughly 6 nanoseconds (11.3s ~= 380MH/s ~= 3ns per nonce if it was a single device = 6ns per pair)
... though I'd be curious to know if the hashing process is a complete cycle per pair or the pairs are stepping though a stepped cycle
i.e. is there some delay before the first nonce-check completes, and then the remaining (2^31 - 1) sequential results are closer together than this initial delay?
I've still not quite got my understanding of that inside FPGA processing clear to me yet.

[ngzhang]

is there any questions i should answer? 

about over heat: i test a fan stop issue for 1 day, 1% invalid, no damage.
but i'm afraid, so i won't to do a heat-sink drop issue... 

[Turbor]

That's strange. I use RG7Miner too and so far (~18 hours of continuous mining on ABCpool) I never got anything that resembles the "sleeping mode" you describe. What pool are you on? Maybe it has something to do with them? Maybe it has something to do with your connection? Is it stable enough? Maybe the pool was under some sort of ddos attack when your boards displayed that error?

[edit] - I managed to replicate your error by turning off the board then turning it back on without stopping the miner. Every share after that was invalid until I stopped and restarted the miner. Maybe there's some sort of power interruptions on the supply line and your board turns off briefly.

No, there is no power interruption. Two other FPGAs are on the same supply. I mine on GPUMAX and BitMinter. BM is rock solid but it happens there too. Antirack had the same error. Funny thing is that Icarus has the lowest stale rate of all devices i have. So the miner can't be that bad It's just not stable (yet)

[Energizer]

I am getting 0% invalid shares on 6 boards! I am using MPBM with jobinterval set to 11.3!

By the way I was wrong! the 11->11.3 range is as valuable as any 0.3 seconds within the 11.3 seconds range!