Pages:
Author

Topic: [Work in progess] Burnins Avalon Chip to mining board service - page 65. (Read 624200 times)

sr. member
Activity: 243
Merit: 250
ALTCOM Ab9upXvD7ChnJxDRZgMmwNNEf1ftCGWrsE
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  Wink)

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.
sr. member
Activity: 322
Merit: 250
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..

hero member
Activity: 518
Merit: 500
Would the board work with missing chips? One empty spot, for instance, so 19 chips on a board.
member
Activity: 98
Merit: 10
You missed a couple of changes I already posted next to a post of yours before:
https://bitcointalksearch.org/topic/m.2897971

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.
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
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://bitcointalksearch.org/topic/m.2897971

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.
newbie
Activity: 35
Merit: 0
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..
member
Activity: 98
Merit: 10
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  Wink)
member
Activity: 98
Merit: 10
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.

m5
newbie
Activity: 82
Merit: 0
Maybe on RPi it is easier to install php and use the bundled cgminer.php to access the API...
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
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.
legendary
Activity: 2674
Merit: 1083
Legendary Escrow Service - Tip Jar in Profile
sr. member
Activity: 490
Merit: 250
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.
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
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.

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

Quote
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 Smiley
legendary
Activity: 2674
Merit: 1083
Legendary Escrow Service - Tip Jar in Profile
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.

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?

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.

...
I cant download from this address with git clone? And you mentioned you want to change the const for clockrate but it doesnt appear in changelog so i wondered if you forgot.

Another question... the timeout you mentioned with java API... how can i access it? I tried in cgminer dir but no success and cgminer seems not to have a commandline. (Sorry for newbquestions. Linux isnt my OS till now.)
No, you need to clone Con's or my git
Con (master git): https://github.com/ckolivas/cgminer
Me: https://github.com/kanoi/cgminer
My git has the changes I said, e.g. for the 1400 limit, but it's a pull request to Con's coz I wanted to add something else that I hadn't done yet.
(I've actually been quite unwell almost all week, so when I get to coding at night I haven't got very far this week)

To see all the Avalon/BTB extra stats you java API stats
It will be in the beginning of that
There is a set of data for each mining device.
(The end of it is the pool info. There is a set of data for each pool on the end)

Edit: latest firmware running 21hrs seems to be getting closer to 8GH/s at 400Mhz with default voltage Smiley
 BTB  0: 48/ 48C 1222mV | 9.806G/7.784Gh/s | A:137599 R:800 HW:2255 WU:110.4/m

legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
...
I cant download from this address with git clone? And you mentioned you want to change the const for clockrate but it doesnt appear in changelog so i wondered if you forgot.

Another question... the timeout you mentioned with java API... how can i access it? I tried in cgminer dir but no success and cgminer seems not to have a commandline. (Sorry for newbquestions. Linux isnt my OS till now.)
No, you need to clone Con's or my git
Con (master git): https://github.com/ckolivas/cgminer
Me: https://github.com/kanoi/cgminer
My git has the changes I said, e.g. for the 1400 limit, but it's a pull request to Con's coz I wanted to add something else that I hadn't done yet.
(I've actually been quite unwell almost all week, so when I get to coding at night I haven't got very far this week)

To see all the Avalon/BTB extra stats you java API stats
It will be in the beginning of that
There is a set of data for each mining device.
(The end of it is the pool info. There is a set of data for each pool on the end)

Edit: latest firmware running 21hrs seems to be getting closer to 8GH/s at 400Mhz with default voltage Smiley
 BTB  0: 48/ 48C 1222mV | 9.806G/7.784Gh/s | A:137599 R:800 HW:2255 WU:110.4/m
member
Activity: 70
Merit: 10
What is the largest number of BB someone has stacked?
legendary
Activity: 2674
Merit: 1083
Legendary Escrow Service - Tip Jar in Profile
In order to test out higher voltages i compiled cgminer again with 1.4V as the maximum. When i started cgminer i realized that there is another const keeping it from going above 450MHz so i had to compile again and sat it to 550MHz.

Now i tested a bit and the results look strange. I only run with one miner to not risk 5 Miners.

The results are:

Code:
450MHz 1400mV 8.90GH/s WU: 121.5 HW: 0
460MHz 1400mV 5.50GH/s WU: 76.3 HW: 0
470MHz 1400mV 3.95GH/s WU: 54.5 HW: 0
475MHz 1400mV 1.80GH/s WU: 33.1 HW: 0

So as long as i go above 450MHz the hashing gets worse... oO

I only can think of that as a coding problem since i dont see a normal reason why the chips should behave this way at that certain border.

I only found one const that included 450 in the driver-avalon.h. Thanks Tursk.

What do you think?

Sounds like you exceed the 80Amp limit of the DC/DC-Converter causing it to go hiccup mode reducing the hash duty cycle.
The hard limit is 640Mhz that is where the communication protocol will stop working, at least on the BitBurners.
1.4V is the limit set in the Firmware.
I will replicate your settings and come back to you.
(Or you just didn't adjust the timeout)

By the way: there is a new firmware revision in the pipeline that optimizes the efficiency.
OK I'll set it to 1400 in cgminer also then Smiley

As for frequency ... well I guess I can set it to that limit - if it is a BTB then allow it to go to 640 also I guess

As for timeout - I've put the pull to change that now also:
https://github.com/ckolivas/cgminer/pull/476
So if you set timeout to be 'd' in --avalon-options then it will calculate for you the default for your frequency if you specify frequency.

I cant download from this address with git clone? And you mentioned you want to change the const for clockrate but it doesnt appear in changelog so i wondered if you forgot.

Another question... the timeout you mentioned with java API... how can i access it? I tried in cgminer dir but no success and cgminer seems not to have a commandline. (Sorry for newbquestions. Linux isnt my OS till now.)
full member
Activity: 154
Merit: 100
Hi, I've been messing with the avalon options for a while now and what seems to work best for me is 440MHz with 28 delay, gets me WU about 125/m.
I wanted to ask about the temperature...

If the chips are designed to operate at below 65C that means that the board temp that we have a reading for shouldn't go higher than 55C, right?
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
In order to test out higher voltages i compiled cgminer again with 1.4V as the maximum. When i started cgminer i realized that there is another const keeping it from going above 450MHz so i had to compile again and sat it to 550MHz.

Now i tested a bit and the results look strange. I only run with one miner to not risk 5 Miners.

The results are:

Code:
450MHz 1400mV 8.90GH/s WU: 121.5 HW: 0
460MHz 1400mV 5.50GH/s WU: 76.3 HW: 0
470MHz 1400mV 3.95GH/s WU: 54.5 HW: 0
475MHz 1400mV 1.80GH/s WU: 33.1 HW: 0

So as long as i go above 450MHz the hashing gets worse... oO

I only can think of that as a coding problem since i dont see a normal reason why the chips should behave this way at that certain border.

I only found one const that included 450 in the driver-avalon.h. Thanks Tursk.

What do you think?

Sounds like you exceed the 80Amp limit of the DC/DC-Converter causing it to go hiccup mode reducing the hash duty cycle.
The hard limit is 640Mhz that is where the communication protocol will stop working, at least on the BitBurners.
1.4V is the limit set in the Firmware.
I will replicate your settings and come back to you.
(Or you just didn't adjust the timeout)

By the way: there is a new firmware revision in the pipeline that optimizes the efficiency.
OK I'll set it to 1400 in cgminer also then Smiley

As for frequency ... well I guess I can set it to that limit - if it is a BTB then allow it to go to 640 also I guess

As for timeout - I've put the pull to change that now also:
https://github.com/ckolivas/cgminer/pull/476
So if you set timeout to be 'd' in --avalon-options then it will calculate for you the default for your frequency if you specify frequency.
sr. member
Activity: 243
Merit: 250
ALTCOM Ab9upXvD7ChnJxDRZgMmwNNEf1ftCGWrsE
In order to test out higher voltages i compiled cgminer again with 1.4V as the maximum. When i started cgminer i realized that there is another const keeping it from going above 450MHz so i had to compile again and sat it to 550MHz.

Now i tested a bit and the results look strange. I only run with one miner to not risk 5 Miners.

The results are:

Code:
450MHz 1400mV 8.90GH/s WU: 121.5 HW: 0
460MHz 1400mV 5.50GH/s WU: 76.3 HW: 0
470MHz 1400mV 3.95GH/s WU: 54.5 HW: 0
475MHz 1400mV 1.80GH/s WU: 33.1 HW: 0

So as long as i go above 450MHz the hashing gets worse... oO

I only can think of that as a coding problem since i dont see a normal reason why the chips should behave this way at that certain border.

I only found one const that included 450 in the driver-avalon.h. Thanks Tursk.

What do you think?

Sounds like you exceed the 80Amp limit of the DC/DC-Converter causing it to go hiccup mode reducing the hash duty cycle.
The hard limit is 640Mhz that is where the communication protocol will stop working, at least on the BitBurners.
1.4V is the limit set in the Firmware.
I will replicate your settings and come back to you.
(Or you just didn't adjust the timeout)

By the way: there is a new firmware revision in the pipeline that optimizes the efficiency.

Edit:
Updated the Guide here: http://www.burninmining.com/news/
With a few bits about software.
Pages:
Jump to: