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

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?

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.


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.

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).

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

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.

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.

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)

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.

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 .jar) gives info about all possible parameters.

Quote from: Dhomochevsky on March 07, 2012, 03:31:23 PM

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.
...

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 .

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. 

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:


 

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

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 ...

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.

hummmm...
my meter shows a zero if all boards turned off.

i think the default adapter is Ok for a few boards, because the waste (if there is) is rather low.

i use a ATX with 80plus label to handle multi-boards. compact and effective. 

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

 



220V/50Hz

I suspect the plug pack supplied is wasting quite a bit of power.. at least when run on a 240V supply - it gets quite warm.
My power meter is showing 23.3W.

I have a high efficiency supply on order, so I'll see if that makes a difference.

what miner software is best for batch 3 icarus

Just wanted to say that Bitcoin Syndicate (www.btcsyn.com) just ordered and paid for 17 Icarus FPGA boards from this batch to be shipped out shortly!

Once I get them operational, I'll post pics of the rig. (we plan to scale it well past 17 but that's our first wave).