[Work in progess] Burnins Avalon Chip to mining board service

[dddbtc]

EDIT: NVM, looking forward to recieving my zefir batch 1 bitburnerXX in the near future.  If you can remember to put the tracking number in my invoice, I would very much appreciate that.

[SebastianJu]

Thanks for all the explaination.

I guess i dont have Java installed then on the rpi, i used a noob image for raspi. Raspberian or so. But i will try again when im home.

Is WU including rejected shares too? I found an interesting thing in the morning when i tested with the timeout a bit. I sat 1340mV, 450MHz and 25, or was it 20ms? timeout. After 10 minutes there were zero rejected shares. ZERO. While normally 13% rejected shares appear. I cant explain but the hashrate at the pool went from 38GH to 42GH by doing this. So it looks it really has an effect. The hashrate in cgminer didnt change by doing that so i think rejected shares are included and its not a safe value to judge efficient. Maybe its best to use the pool for the value since it only seems to count hashrate that delivers correct shares.
So at the moment i believe WU includes rejected shares too since they didnt change.

Im still puzzled about the drop in hashrate, wattage and all when using higher values. I hope burnin finds an explaination.

The download and compiling worked (i changed the max hashrate before). Now it understands the d sign. I only have to test now if it changes things.

But i dont understand the java API stats part. Is this a java program part? I dont have a clue how to use it. I saw the commands you gave but i cant find where to enter that command.

If you have java installed on your computer then in the cgminer folder type:
java API stats
and it will report all the extra internal stats and related debug info stored in cgminer
The Avalon extra stats are there plus the BTB voltage.

Another question regarding the most efficient settings. Where can i see this best. WU seems to be the whole work. Including HW and rejected shares. There is unfortunately no U stat. And the hashrate seems to include rejected shares too. So where can i see the cleaned stat for the useful hashingresults so that i know the best settings? I till now use the average hashrate and WU but those are polluted with useless work. Is there somethine better? Maybe using a timer and counting the accepted shares?

WU: is 1diff and work returned by the device that isn't a HW error.

You can also reset it but you will zero all the important stats in cgminer when you do it:
java API "zero|all,true"
However, the 'true' on the end means it will print a full summary of everything before it zeros them all

The way the Avalon code works, you can't get a reliable estimate of the result of a change without waiting an hour or so.
The Avalon code uses the found nonces to determine the hash rate (which is of course greatly affected by variance)
Of course over a long period of time that's pretty accurate, but over a short period (even 1 hour) it's not all that accurate at all.

However, WU: is of course the best thing to use.
The old U: was meaningless on any pool with variable diff

You may notice now that A: and R: are also 1diff since again on a variable diff pool the old versions were meaningless.

Anyway. I tried the d-param and found that its not the best value. For example when i run it at 475mhz and 1400mV its a whole lot worse than when i give the timeout. I tend to believe that the needed timeout might be changed by the voltage but i dont know since i cant tell what timeout that is at all.

The temperature was at 44°C when running at 1.4V and 475mhz too only. With full hashing at 1340V and 450mhz its at normal 49°C.

So raising the hashrate gives worse results. The temperature is lower, the chips work less.

The d param cant help. I tried many different values with no success. Its like the chips wont work anymore. Maybe its really some border of the board parts. But i doubt a bit since at 1.4V and 375mhz the wattage is 340W instead nearly 500 when it fully runs at 450mhz and 1340V.

Ill set it back to these settings now since i dont know better ones yet.
...

timeout is in ms

The timeout calculated is simply how the Avalon has always done it since it was added
I've not actually thought about why it is exactly "12690 / freq"

The point of it though is to ensure the chips don't repeat the hashing they are doing.
So if it is too high, you can get duplicate hashes and loss of GH/s due to redoing work.
If it is too low, you get more latency due to having to send work more often.

If someone wants to check that and come up with a better calculation for BTB - let me know - and explain it - and I'll use it

[kano]

Thanks for all the explaination.

I guess i dont have Java installed then on the rpi, i used a noob image for raspi. Raspberian or so. But i will try again when im home.

Is WU including rejected shares too? I found an interesting thing in the morning when i tested with the timeout a bit. I sat 1340mV, 450MHz and 25, or was it 20ms? timeout. After 10 minutes there were zero rejected shares. ZERO. While normally 13% rejected shares appear. I cant explain but the hashrate at the pool went from 38GH to 42GH by doing this. So it looks it really has an effect. The hashrate in cgminer didnt change by doing that so i think rejected shares are included and its not a safe value to judge efficient. Maybe its best to use the pool for the value since it only seems to count hashrate that delivers correct shares.
So at the moment i believe WU includes rejected shares too since they didnt change.

Im still puzzled about the drop in hashrate, wattage and all when using higher values. I hope burnin finds an explaination.

Meh, I wish my 2nd RPi would hurry up and arrive.
I run Arch on my RPi now and it's in my garage, so it's annoying to switch it back to Raspbian temporarily to check anything
(also one of the reasons why I bought a 2nd RPi)

Anyway I think the package is:
apt-get install openjdk-7-jdk

Rejected shares are not HW errors.
Rejected shares should only be during an LP - coz of:
1) Your hardware latency is high
  This can be reduced by aborting the work at LP rather than waiting for it to finish.
  I'm pretty sure it can't be done with an Avalon, but there was mention of adding an abort to the BTB firmware
  Reducing the timeout will also reduce this, but reducing the timeout too much is also bad as I mentioned before
2) Your pool latency is high
  Speed up your connection to the pool (too many hops, too much latency through the net from you to the pool ...)
  Tell the pool to do better when supplying you with LP information - e.g. use Stratum (not GetWork or GBT)
3) Some pools don't handle diff changes properly or don't handle a stratum reconnect properly ...

Some pools also pay Stale shares (which is what a Rejected share is in cgminer) so you shouldn't get them on those pools
The pool itself also replies with the reason why the share was rejected - that's what's in the () at the end

HW is ignore since indeed it is a fault of the hardware.

[m5]

Maybe on RPi it is easier to install php and use the bundled cgminer.php to access the API...

[northcape]

Received my devices today after a week of shipping. I’m quite impressed by the quality of burnin's service regardless.

It is possible to update the firmware using a raspberrypi and arch linux after all. Somebody in an earlier posting stated that it isn’t possible, but I found it works just fine.

I simply checked out http://code.google.com/p/pic32prog/ as read-only, installed build-essentials and libusb-compat and compiled it. If you try to compile it without libusb-compat installed, you’ll get an error because usb.h is missing.

Then I had an issue where my pic32prog wouldn’t recognize the bootloaders. They always timed out. If you have the same problem, edit lines 163-166 in target.c:

Code:

 if (! t->adapter)
        t->adapter = adapter_open_hidboot ();
    if (! t->adapter)
        t->adapter = adapter_open_an1388 ();

to look like this:

Code:

 if (! t->adapter)
        t->adapter = adapter_open_an1388 ();
    if (! t->adapter)
        t->adapter = adapter_open_hidboot ();

then recompile (make && make install) and try again.

to flash, simply execute ./pic32prog BitBurner_08.05b.hex

I did all of the above the above as root, otherwise you’ll probably run into permission issues.

[northcape]

Oh and be extremely careful with the micro usb jacks. One of mine broke clean off when I first disconnected it. (cold solder joint? the whole area looks quite matte and rough)

Fortunately this happened after updating the firmware, so the board runs over the CANBUS just fine. Of course that means I’m stuck with this firmware, but it seems to work flawlessly so far.

If you look really closely, you can see the micro usb-jack and PCB flex an awful lot from just the weight of the cable alone.
It is probably a good idea to zip-tie the cable to one of the bolts for strain relief. (Zugentlastung  )

[neslekkim]

Oh and be extremely careful with the micro usb jacks. One if mine broke clean off when I first disconnected it. (cold solder joint? the whole area looks quite matte and rough)

Not sure about your card, but on other cards I have, it seems like the microusb is not soldered on all feets, and it's very little to solder with so they bread easily
They do come in throughole versions for better support..

[kano]

Received my devices today after a week of shipping. I’m quite impressed by the quality of burnin's service regardless.

It is possible to update the firmware using a raspberrypi and arch linux after all. Somebody in an earlier posting stated that it isn’t possible, but I found it works just fine.

I simply checked out http://code.google.com/p/pic32prog/ as read-only, installed build-essentials and libusb-compat and compiled it. If you try to compile it without libusb-compat installed, you’ll get an error because usb.h is missing.

Then I had an issue where my pic32prog wouldn’t recognize the bootloaders. They always timed out. If you have the same problem, edit lines 163-166 in target.c:

Code:

 if (! t->adapter)
        t->adapter = adapter_open_hidboot ();
    if (! t->adapter)
        t->adapter = adapter_open_an1388 ();

to look like this:

Code:

 if (! t->adapter)
        t->adapter = adapter_open_an1388 ();
    if (! t->adapter)
        t->adapter = adapter_open_hidboot ();

then recompile (make && make install) and try again.

to flash, simply execute ./pic32prog BitBurner_08.05b.hex

I did all of the above the above as root, otherwise you’ll probably run into permission issues.

You missed a couple of changes I already posted next to a post of yours before:
https://bitcointalk.org/index.php?topic=179769.msg2897971#msg2897971

The problem for me was it hangs during programming on the RPi
It does find it and connect to it and start programming, but then hangs before completion

May well be the libusb version I used that day ... the default libusb version on raspbian is bugged ... but the default version on Arch seems to be OK, so I may have only run it on Raspbian - I can't remember.

[northcape]

You missed a couple of changes I already posted next to a post of yours before:
https://bitcointalk.org/index.php?topic=179769.msg2897971#msg2897971

The problem for me was it hangs during programming on the RPi
It does find it and connect to it and start programming, but then hangs before completion

Ah yes, I missed that posting. About the hangs, I experienced those too but got around them by starting the flash process right as I powered up the boards with no waiting in between. Even then it took 2-3 tries to get a successful flash.

[Boxman90]

Would the board work with missing chips? One empty spot, for instance, so 19 chips on a board.

[alexuk]

Hi guys

Got my bitburners today

Attached the stacking cable, set the termination jumpers on both boards at the of the chain...

with just 2 boards in a stack (i had 6 originally) , using the latest cgminer on github, it seems only _one_ bitburner board is doing any work:

Code:

./cgminer --avalon-options 115200:4:10:35:350 --avalon-temp 45 

Code:

 cgminer version 3.3.4 - Started: [2013-08-17 00:45:23]
--------------------------------------------------------------------------------
 (5s):5.262G (avg):7.564Gh/s | A:12  R:8  HW:0  WU:105.7/m
 ST: 2  SS: 0  NB: 2  LW: 34  GF: 0  RF: 0
 Connected to eu-stratum.btcguild.com diff 2 with stratum as user xxx
 Block: 0049ef5b5e645be2...  Diff:50.8M  Started: [00:45:31]  Best share: 11
--------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
 BTB 0: 45/ 45C 1237mV | 4.721G/7.564Gh/s | A:12 R:8 HW:0 WU:105.7/m
--------------------------------------------------------------------------------

 [2013-08-17 00:45:21] Started cgminer 3.3.4
 [2013-08-17 00:45:22] BTB0: Reset succeeded
 [2013-08-17 00:45:22] BTB0: Idling 1 miners
 [2013-08-17 00:45:22] BTB0: Core voltage set to 1200 millivolts
 [2013-08-17 00:45:22] Probing for an alive pool
 [2013-08-17 00:45:22] Pool 0 difficulty changed to 2
 [2013-08-17 00:45:22] Network diff set to 50.8M
 [2013-08-17 00:45:22] Stratum from pool 0 detected new block
 [2013-08-17 00:45:23] Avalon: Discarding 32 bytes from buffer
 [2013-08-17 00:45:23] Accepted 7e3c858e Diff 2/2 BTB 0
 [2013-08-17 00:45:25] Accepted 281bcad0 Diff 6/2 BTB 0
 [2013-08-17 00:45:26] Accepted 66115963 Diff 2/2 BTB 0
 [2013-08-17 00:45:28] Accepted 5a4ca74d Diff 2/2 BTB 0
 [2013-08-17 00:45:29] Accepted 38223744 Diff 4/2 BTB 0

im stuck anyone got any clues what to do?

ive double checked the jumpers, moved the stacking cable around, but no luck, what am i doing wrong?

cheers..

[burnin]

im stuck anyone got any clues what to do?

ive double checked the jumpers, moved the stacking cable around, but no luck, what am i doing wrong?

cheers..

Sounds like you didn't update the firmware.

Oh and be extremely careful with the micro usb jacks. One if mine broke clean off when I first disconnected it. (cold solder joint? the whole area looks quite matte and rough)

Fortunately this happened after updating the firmware, so the board runs over the CANBUS just fine. Of course that means I’m stuck with this firmware, but it seems to work flawlessly so far.

If you look really closely, you can see the micro usb-jack and PCB flex an awful lot from just the weight of the cable alone.
It is probably a good idea to zip-tie the cable to one of the bolts for strain relief. (Zugentlastung  )

I chose micro-usb because they are tougher then mini-usb plugs, and they through hole, must have been a real bad solder joint there.
On my boards here none of the connectors flex at all.

[alexuk]

im stuck anyone got any clues what to do?

ive double checked the jumpers, moved the stacking cable around, but no luck, what am i doing wrong?

cheers..

Sounds like you didn't update the firmware.

Hmm, i upgraded using this hex file on all bitburners: (as per the link on your website)

https://www.dropbox.com/s/q22eb8f85ybtxzm/BitBurner_08.05b.hex

Got this as the output on all of them

Code:

Device connected
Bootloader Firmware Version: 1.0
Hex file loaded successfully
Flash Erased
Programming completed
Verification successfull
Verification successfull
Device disconnected

[alexuk]

ah! i didnt click "run application", im assuming thats the issue here

going back to reflash....

[burnin]

That shouldn't make a difference.
When CAN is working the yellow LED on both boards should flash when running cgminer.
Could you triple check those jumpers?

Have you read the instructions?
http://www.burninmining.com/news/

[Bogart]

Burnin, my chips have been awaiting you at your post office.  Tracking says "Addressee requests own pick-up - Item being held, addressee being notified"

See my PM for the tracking number.

[burnin]

Burnin, my chips have been awaiting you at your post office.  Tracking says "Addressee requests own pick-up - Item being held, addressee being notified"

See my PM for the tracking number.

They are at the customs office.

[SebastianJu]

Thanks for all the explaination.

I guess i dont have Java installed then on the rpi, i used a noob image for raspi. Raspberian or so. But i will try again when im home.

Is WU including rejected shares too? I found an interesting thing in the morning when i tested with the timeout a bit. I sat 1340mV, 450MHz and 25, or was it 20ms? timeout. After 10 minutes there were zero rejected shares. ZERO. While normally 13% rejected shares appear. I cant explain but the hashrate at the pool went from 38GH to 42GH by doing this. So it looks it really has an effect. The hashrate in cgminer didnt change by doing that so i think rejected shares are included and its not a safe value to judge efficient. Maybe its best to use the pool for the value since it only seems to count hashrate that delivers correct shares.
So at the moment i believe WU includes rejected shares too since they didnt change.

Im still puzzled about the drop in hashrate, wattage and all when using higher values. I hope burnin finds an explaination.

Meh, I wish my 2nd RPi would hurry up and arrive.
I run Arch on my RPi now and it's in my garage, so it's annoying to switch it back to Raspbian temporarily to check anything
(also one of the reasons why I bought a 2nd RPi)

Anyway I think the package is:
apt-get install openjdk-7-jdk

Rejected shares are not HW errors.
Rejected shares should only be during an LP - coz of:
1) Your hardware latency is high
  This can be reduced by aborting the work at LP rather than waiting for it to finish.
  I'm pretty sure it can't be done with an Avalon, but there was mention of adding an abort to the BTB firmware
  Reducing the timeout will also reduce this, but reducing the timeout too much is also bad as I mentioned before
2) Your pool latency is high
  Speed up your connection to the pool (too many hops, too much latency through the net from you to the pool ...)
  Tell the pool to do better when supplying you with LP information - e.g. use Stratum (not GetWork or GBT)
3) Some pools don't handle diff changes properly or don't handle a stratum reconnect properly ...

Some pools also pay Stale shares (which is what a Rejected share is in cgminer) so you shouldn't get them on those pools
The pool itself also replies with the reason why the share was rejected - that's what's in the () at the end

HW is ignore since indeed it is a fault of the hardware.

I was able to install that java package but when i run that command in cgminer dir and cgminer is running "bash: java: unknown command" for all commands you wrote.

Anyway. I know the formula now. I calculated that 450MHz should be 28.2ms timeout. Im not sure if its perfect because when i tested it at the day i got 10% rejected shares. One ms less zero rejected shares. But now, at the evening i cant replicate that anymore. The d param works now and no rejected shares. I dont know why.
My pool doesnt count rejected shares and i wouldnt want my pool paying out rejected shares to others when i know how i can prevent rejected shares.

Based on this i started another test. I sat the mhz to 450 and didnt bother with HW. Only WU was of interest for me. Even with >50% HW the WU calculates all shares. Every test i ran for 15minutes after that my htc ringed to read the values. After that time the values have relatively good settled. So i tested and found that the optimum voltage is 1228mV with 670WU. Unfortunately when it became later and the temperature went down outside the bitburner cooled down too. Which leaded to the effect that the temperature went from 50°C to 46°C and at the same time 1228mV only was 630WU anymore. Instead the optimum voltage was at 1224 now. 4mV less because 4°C less. So 4mV does have such a big impact. I tend to believe a settings per °C is needed because one cant change it back and forth when you host it at a datacentre.

*sigh* And i hoped to find an ideal setting...

At least its interesting to know that the voltage always has a sweet spot at a working temperature. Going 100mV above or below has a big impact. Even one mV can have a not small effect. I cant explain why.

[Bogart]

Burnin, my chips have been awaiting you at your post office.  Tracking says "Addressee requests own pick-up - Item being held, addressee being notified"

See my PM for the tracking number.

They are at the customs office.

Does that mean there is a fee due?  What does it take to get them from the customs office?

[alexuk]

That shouldn't make a difference.
When CAN is working the yellow LED on both boards should flash when running cgminer.
Could you triple check those jumpers?

Have you read the instructions?
http://www.burninmining.com/news/

yellow light only flashing on one board that i have the USB plugged into

reflashed 4 devices, using

https://www.dropbox.com/s/q22eb8f85ybtxzm/BitBurner_08.05b.hex

triple checked the jumpers - using the jumper supplied in the box, they are aligned in the same fashion as the pics on your news section, two jumpers on the first board, two jumpers on the last board in the chain

plugged the CAN cable by using the top 4 plugs in the chain, tried others also.

only one board seems to be doing work, the one that the usb is plugged into only, switching the usb cable around doesnt change anything else either, only the board thats plugged in does the work

using settings:

Code:

./cgminer --avalon-options 115200:8:10:35:282 --avalon-temp 45 -u xxx -p 12345 -o eu-stratum.btcguild.com:3333

Code:

 [P]ool management [S]ettings [D]isplay options [Q]uit
 BTB 0: 38/ 38C 1221mV | 86.48M/2.862Gh/s | A:6 R:0 HW:0 WU: 80.0/m
--------------------------------------------------------------------------------

 [2013-08-17 09:40:07] Started cgminer 3.3.4
 [2013-08-17 09:40:07] BTB0: Reset succeeded
 [2013-08-17 09:40:07] BTB0: Idling 1 miners
 [2013-08-17 09:40:08] BTB0: Core voltage set to 1200 millivolts
 [2013-08-17 09:40:08] Probing for an alive pool
 [2013-08-17 09:40:08] Pool 0 difficulty changed to 2
 [2013-08-17 09:40:08] Network diff set to 50.8M
 [2013-08-17 09:40:08] Stratum from pool 0 detected new block
 [2013-08-17 09:40:09] Avalon: Discarding 32 bytes from buffer
 [2013-08-17 09:40:14] Accepted 2b6307a5 Diff 5/2 BTB 0
 [2013-08-17 09:40:14] Accepted 062d3b04 Diff 41/2 BTB 0
 [2013-08-17 09:40:15] Accepted 2f272947 Diff 5/2 BTB 0

Code:

root@atom:~/cgminer# ./cgminer -V
cgminer 3.3.4
root@atom:~/cgminer#

Code:

root@sol:~/cgminer# cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=12.04
DISTRIB_CODENAME=precise
DISTRIB_DESCRIPTION="Ubuntu 12.04.2 LTS"
root@sol:~/cgminer#


root@sol:~/cgminer# uname -a
Linux sol 3.2.0-39-generic #62-Ubuntu SMP Thu Feb 28 00:28:53 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Cant understand why this isnt working, version of cgminer perhaps?!

recompiled cgminer from github, no errors anywhere, on a different server, same issue, only one bitburner is doing work.