Avalon ASIC users thread

[jgarzik]

Still having some amount of reliability problems.  Moving the miner in the office helped a great deal.  However, still seeing machine restarts for unknown reasons (note: must ping support, inquire about reboot logging).

And right now, the miner is in a strange state where the controller (running Linux) and cgminer are alive, but fans are not running, and no work is occurring:

Code:

   [Elapsed] => 10477
   [MHS av] => 15419.77   (this is not changing)
   [Found Blocks] => 0
   [Getworks] => 385         (these are increasing, slowly)
   [Accepted] => 37082     (these are not increasing)
   [Rejected] => 398
...
   [fan1] => 0                     (indeed, fans are not moving)
   [fan2] => 0
   [fan3] => 0
   [temp1] => 26
   [temp2] => -1
   [temp3] => 48
   [temp_max] => 49

And the pool agrees that no shares are incoming.

[kano]

i.e. still hashing, still getting work, but not sending anything back to the pool/bitcoind.
So either there's an issue of heat causing bad/no nonces to come back or there's some failure to send out the answers (failure to send is unlikely)

Counting the amount of work done is up to the driver supplying a response back to the call to scanhash()
Is Hardware Errors increasing?

... and yes the driver module can reply in such a way as cgminer thinks it is working but no nonces are being found.
Since a work item doesn't have to find a none (they only average one per nonce range as you know) if it isn't actually returning any nonces then that would also match your description (i.e. due to some over heat MCU/whatever issue that might happen on occasion and the reboot fixes it)

Edit: this happens with Icarus on rare occasions

[jgarzik]

i.e. still hashing, still getting work, but not sending anything back to the pool/bitcoind.

No, not hashing.

[kano]

i.e. still hashing, still getting work, but not sending anything back to the pool/bitcoind.

No, not hashing.

Hmm but you said MHs isn't changing i.e. that hash rate isn't dropping.
Check "Total MH" which should be increasing.

Edit: yes it may not *actually* be hashing, but the driver module may think it is and isn't getting an error from the devices and thus assuming it is hashing and thus it's effectively saying that it's just not finding any nonces.
i.e. it's able to send the work and the expected responses are coming back, but without any nonces.

[jgarzik]

Again, no, it was not hashing.  Avoid speculating wildly based on a tiny subset of hundreds of variables.

[rchapoteau]

Mighr be a stupid question but are you sure that your office isn't doing anything on the network that might be giving you an issue?  Like proxy server settings?

[jgarzik]

Mighr be a stupid question but are you sure that your office isn't doing anything on the network that might be giving you an issue?  Like proxy server settings?

Yes.

[kano]

Again, no, it was not hashing.  Avoid speculating wildly based on a tiny subset of hundreds of variables.

No speculation.
MHs says it is hashing - reread my last reply.

[Unacceptable]

Maybe someone can get on teamviewer or the like & see whats happening  

[kano]

Maybe someone can get on teamviewer or the like & see whats happening  

As I said, this already happens with Icarus.
It's not surprising - and the API output says it is doing the same thing.

[jgarzik]

No speculation.
MHs says it is hashing - reread my last reply.

And as noted, that number is not changing.  The number is constantly changing, normally.

Other stats bear out the conclusion.

[rudrigorc2]

 is it dead

[kano]

No speculation.
MHs says it is hashing - reread my last reply.

And as noted, that number is not changing.  The number is constantly changing, normally.

Other stats bear out the conclusion.

Well the fact that the API is replying (and counting getworks) says of course cgminer is running.
The only ways *I* can imagine that number to be exactly static:
1) The system clock stopped at the same time it stopped hashing - simple to check - look at some of the other information you removed - [When] and see if it changes form one output to the next ...
2) The software changes have messed with the main control of cgminer ... and got something wrong there
3) Some number is overflowing somewhere due to the higher hash rate ... and screwing up the work thread(s) in some weird way
4) The hashing speed is perfectly 15419.77 when it thinks it is working but is indeed doing nothing - since the timing to do nothing is the same every time it does nothing
5) Who knows - anyway I'm wasting my time here ... have fun with it

[jgarzik]

is it dead

No, not at all.  A restart fixes everything.  This is just describing the behavior before the restart.

[BitSyncom]

power consumption on site fixed to reflect end-user situations.

Chip power efficienty: 6.6W/GHs @ 1.15 V
Module power consumption: 149W @ 20GHs
machine power consumption: 595W @ 220V-AC | 620W @ 120V-AC

[Elokane]

Still having some amount of reliability problems.  Moving the miner in the office helped a great deal.  However, still seeing machine restarts for unknown reasons (note: must ping support, inquire about reboot logging).

And right now, the miner is in a strange state where the controller (running Linux) and cgminer are alive, but fans are not running, and no work is occurring:

And the pool agrees that no shares are incoming.

How often does it restart?
How much trouble is it to start mining again once it does?

[Icoin]

DVB allready started to build up the team for GPL AVALON Watercooling elements production. I see heat as a major problem for ASIC devices in general, this heat probably causes the errors, more noise and higher power consumption, aswell the need for the restart. We will investigate, with a thermo camera, as soon the AVALON trade-in harware arrives here in Switzerland.

https://bitcointalk.org/index.php?topic=101559.msg1493823#msg1493823(

DVB is a DEVCOIN (DEVELOPERS COIN) based and we guys use for development devcoins in between us.

Jeff or BitSyncom: can you make heat pictures from your AVALON? It will show us the heat distribution among the device.

BitSyncom: i guess your shop system will be fixed soon, and we gonna be able to make the trade-in order today

Thanks

Icoin

[SLok]

Chip's power consumption is <6.6W/Ghs

ATX power loses(82%), DC/DC power loses(87%), Fan(5~20w), etc…

So…

650W * 0.82 * 0.87 - 20W = 443W, About right.

so an equivalent bfl number would be something like:

60w / .87 / .82 + 2W (fan) + 5W (host) = 91 W    (host can be discounted for many since it can run several units)

or "bfl's worst case" 60W * 1.2 = 72W ===> 72w / .87 / .82 + 2W (fan) + 5W (host) = ~108W

BFL's single uses 72W at the wall, there is no ATX psu or DC/DC or extra for fans etc, just the host usage to be added. All speculating of course coz it ain't alive yet, but it is definitely no 620W, or 108W.

@jgarzik, have you ran it without the ups to see if that isn't messing up? Checked/reseated internal connections, it has been on a long and bumpy ride?

[MrTeal]

Chip's power consumption is <6.6W/Ghs

ATX power loses(82%), DC/DC power loses(87%), Fan(5~20w), etc…

So…

650W * 0.82 * 0.87 - 20W = 443W, About right.

so an equivalent bfl number would be something like:

60w / .87 / .82 + 2W (fan) + 5W (host) = 91 W    (host can be discounted for many since it can run several units)

or "bfl's worst case" 60W * 1.2 = 72W ===> 72w / .87 / .82 + 2W (fan) + 5W (host) = ~108W

BFL's single uses 72W at the wall, there is no ATX psu or DC/DC or extra for fans etc, just the host usage to be added. All speculating of course coz it ain't alive yet, but it is definitely no 620W, or 108W.

@jgarzik, have you ran it without the ups to see if that isn't messing up? Checked/reseated internal connections, it has been on a long and bumpy ride?

There is an onboard DC/DC module that converts the 12V to 1.2V or whatever core voltage the chips are running at, along with whatever they're using for IO.

We have been quoting our power as power at the wall, not the chip power. If we want to talk chip power, it's .8w GH, so using the Avalon system of measure, 48w per Single, or 24w for a Little Single.

Even if we have worst case scenario, it's 1.2w per GH and that gives you 72w via the Avalon measuring system and probably somewhere around 80w - 85w at the wall. We are not expecting 1.2w GH/s, that is just the upper limit of the power draw per chip under the worst possible conditions.

Earlier Josh had posted that they were aiming for 0.8J/GH and that the possible worst case was 1.2J/GH. I'm a little confused by this too as BFL has always said that 60W would be at the wall with the included power adapter, but if 0.8J/GH is just the chips you will have to factor in both the onboard convertor losses, other draws (microcontroller, fan, etc) and the brick PSU to get the final power draw.

Hopefully we'll know the answer in a month's time.

[Aseras]

DVB allready started to build up the team for GPL AVALON Watercooling elements production. I see heat as a major problem for ASIC devices in general, this heat probably causes the errors, more noise and higher power consumption, aswell the need for the restart. We will investigate, with a thermo camera, as soon the AVALON trade-in harware arrives here in Switzerland.

https://bitcointalk.org/index.php?topic=101559.msg1493823#msg1493823(

DVB is a DEVCOIN (DEVELOPERS COIN) based and we guys use for development devcoins in between us.

Jeff or BitSyncom: can you make heat pictures from your AVALON? It will show us the heat distribution among the device.

BitSyncom: i guess your shop system will be fixed soon, and we gonna be able to make the trade-in order today

Thanks

Icoin

I can do thermal imaging of my units when they arrive. I'm in the first batch expecting them soon.