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

[CumpsD]

I use MinePeon with my Pi and it works great. Starts mining on bootup, web interface to configure pools.

I think ill give it a try... can i edit cgminer consts there too somehow?

Then, regarding my previous question, i run the rpi through a smartphone loading cable but would like to run it from the atx psu. I found complicate tutorials for creating a usb-connector with power but i dont like it. So is it possible to simply power the rpi through pin 2 and 6 or 4 and 6 connected to a 5v cable from the psu?

Check this out: http://dangerousprototypes.com/docs/ATX_Breakout_Board

I know what voltages the cables from the atx have. The only thing i dont know is if i can safely take a 5V and a GND cable from the atx and power the rpi through its pins with it. I dont want to break it and for sure im not the only one coming up with that idea. Unfortunately i only found people that created a usb-connecter to power the rpi with a psu.

Isn't it as easy as cutting one end of an USB cable and taking black and red and wiring them up?

I hoped so, since I have a 5V power supply lying around here serving + and -

[SebastianJu]

I use MinePeon with my Pi and it works great. Starts mining on bootup, web interface to configure pools.

I think ill give it a try... can i edit cgminer consts there too somehow?

Then, regarding my previous question, i run the rpi through a smartphone loading cable but would like to run it from the atx psu. I found complicate tutorials for creating a usb-connector with power but i dont like it. So is it possible to simply power the rpi through pin 2 and 6 or 4 and 6 connected to a 5v cable from the psu?

Check this out: http://dangerousprototypes.com/docs/ATX_Breakout_Board

I know what voltages the cables from the atx have. The only thing i dont know is if i can safely take a 5V and a GND cable from the atx and power the rpi through its pins with it. I dont want to break it and for sure im not the only one coming up with that idea. Unfortunately i only found people that created a usb-connecter to power the rpi with a psu.

Isn't it as easy as cutting one end of an USB cable and taking black and red and wiring them up?

I hoped so, since I have a 5V power supply lying around here serving + and -

As far as i read here it might work: https://www.google.de/search?q=raspberry+pi+atx+psu+site:www.raspberrypi.org&client=firefox-a&hs=zvO&rls=org.mozilla:de:official

The rpi seems to have a fuse for too high voltage. It looks like it can be done what you wanted. So ill try it the same way then if i find such unused cable.

[villex]

I know what voltages the cables from the atx have. The only thing i dont know is if i can safely take a 5V and a GND cable from the atx and power the rpi through its pins with it. I dont want to break it and for sure im not the only one coming up with that idea. Unfortunately i only found people that created a usb-connecter to power the rpi with a psu.

Then check this out: http://potech.dyndns.org/Easy%20PSU%20for%20RPi.html

[CumpsD]

I know what voltages the cables from the atx have. The only thing i dont know is if i can safely take a 5V and a GND cable from the atx and power the rpi through its pins with it. I dont want to break it and for sure im not the only one coming up with that idea. Unfortunately i only found people that created a usb-connecter to power the rpi with a psu.

Then check this out: http://potech.dyndns.org/Easy%20PSU%20for%20RPi.html

This confirms my plan, thanks That's what I'll do once they arrive

[SebastianJu]

I know what voltages the cables from the atx have. The only thing i dont know is if i can safely take a 5V and a GND cable from the atx and power the rpi through its pins with it. I dont want to break it and for sure im not the only one coming up with that idea. Unfortunately i only found people that created a usb-connecter to power the rpi with a psu.

Then check this out: http://potech.dyndns.org/Easy%20PSU%20for%20RPi.html

Thanks for the link...

[LiveJay]

I know what voltages the cables from the atx have. The only thing i dont know is if i can safely take a 5V and a GND cable from the atx and power the rpi through its pins with it. I dont want to break it and for sure im not the only one coming up with that idea. Unfortunately i only found people that created a usb-connecter to power the rpi with a psu.

Then check this out: http://potech.dyndns.org/Easy%20PSU%20for%20RPi.html

This confirms my plan, thanks That's what I'll do once they arrive

Be sure to use one of the +5V lines and not the +5V standby if you want the pi to go off when you turn off the power supply.  Also, be sure to check the rated current output of the standby lines, it may be lower than the full +5V rail.  You need 1A for the pi to be happy.

-Jay

[CumpsD]

I know what voltages the cables from the atx have. The only thing i dont know is if i can safely take a 5V and a GND cable from the atx and power the rpi through its pins with it. I dont want to break it and for sure im not the only one coming up with that idea. Unfortunately i only found people that created a usb-connecter to power the rpi with a psu.

Then check this out: http://potech.dyndns.org/Easy%20PSU%20for%20RPi.html

This confirms my plan, thanks That's what I'll do once they arrive

Be sure to use one of the +5V lines and not the +5V standby if you want the pi to go off when you turn off the power supply.  Also, be sure to check the rated current output of the standby lines, it may be lower than the full +5V rail.  You need 1A for the pi to be happy.

-Jay

I'm using this: https://eb.automation.siemens.com/mall/en/ww/catalog/products/10073747?tree=CatalogTree&activeTab=order#topAnch&activetab=order&

[LainZ]

Thanks burnin & Avalon & kano! (and SebastianJu/BenTuras for the help in PM)

Now mining at 117GH/S on btcguild with 18 bitburners:)

Code:

 ./cgminer -o stratum+tcp://stratum.btcguild.com:3333 -u * -p 123 --usb XX:XX --avalon-options 115200:20:10:35:350

Those jumpers were hard to find :p

[SebastianJu]

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?

[kano]

I now run my miner from the rpi. It works so far but i want to know how and where i can change the const for the maximum voltage. I used ./autogen.sh --enable-avalon to compile but i dont know what file to edit for the const.

Probably these lines in driver-avalon.h

Code:

#define BITBURNER_DEFAULT_CORE_VOLTAGE 1200 /* in millivolts */
#define BITBURNER_MIN_COREMV 1000
/* change here if you want to risk killing it :)  */
#define BITBURNER_MAX_COREMV 1310

[SebastianJu]

And another strange behaviour. I run now at 450MHz always and played a bit with the voltage.

Code:

1330mV	40.0GH/s	560WU	2%HW
1335mV	43.0GH/s	615WU	4%HW
1340mV	44.5GH/s	630WU
1345mV	42.5GH/s	600WU
1350mV	42.0GH/s	596WU
1360mV	38.0GH/s	530WU
1370mV	39.0GH/s	550WU
1380mV	35.5GH/s	495WU
1390mV	32.0GH/s	450WU

The temperatures arent really different.

So what is this? The higher the voltage the lower the hashrate? I really believe its a software side problem. It would be strange if these borders are both at the limits that were set in the miner software.

[kano]

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

What do you think?

You need to set the timeout to match the frequency (since you are setting the frequency at startup)
As I've mentioned, the easy way around this for now is to use the API to set the frequency at least once and it will tell you the correct timeout.
e.g. on mine just now:
java API "ascset|0,help"
Output: [Msg] => ASC 0 set help: freq: range 256-450 millivolts: range 1000-1310

java API "ascset|0,freq,400"
Screen:  [2013-08-15 10:27:05] BTB0: Set frequency to 400, timeout 31

(I guess I better get around to adding 'd' as a timeout option now ...)

I've no idea what it would do to the chip to clock it above 450, but yeah, the timeout could be the problem you are seeing.

[burnin]

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.

[kano]

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

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.

[eraziel]

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?

[SebastianJu]

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

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

[JHenderson]

What is the largest number of BB someone has stacked?

[kano]

...
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
 BTB  0: 48/ 48C 1222mV | 9.806G/7.784Gh/s | A:137599 R:800 HW:2255 WU:110.4/m

[SebastianJu]

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
 BTB  0: 48/ 48C 1222mV | 9.806G/7.784Gh/s | A:137599 R:800 HW:2255 WU:110.4/m

[kano]

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