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

[fasmax]

Why class 10 SDHC ?
Can you recommend a class 10 SDHC that will work with the RasPi.
Thanks!

[1715287808]

1715287808

[1715287808]

1715287808

[1715287808]

1715287808

[1715287808]

1715287808

[kano]

Why class 10 SDHC ?
Can you recommend a class 10 SDHC that will work with the RasPi.
Thanks!

I've had trouble with various Class 6 SDs and no problems so far (touch wood) with class 10 SDs
The class 10s I got are SanDisk Ultra SDHC Cards

I've mentioned this here also: http://www.kano-kun.net/?p=87

[SebastianJu]

The lights are a bit different form board to board. All green lights are the same. The board i put the usb in is blinking yellow very often, seldom red. The second board blinks half so often but most of the time yellow and red. Third similar but seldom at the same time. The next blinks more seldom and red any yellow are similar often. The fifth blinks seldom and sometimes more red than others.

It looks like the first miner with usb connected works more than any other.

What is the miner doing when i close cgminer and it still works on?

Not closing an old cgminer properly? (see task manager)
It is always best to quit with 'q' and see it exit - windows ...

Also try 3.3.3 and see if it has that windows problem you mentioned.
I'll try my BTB on windows again today with 3.3.3 and see if I have any problems.

I've not built 3.3.3 yet, it was only released last night while I was asleep - it's mainly CPU improvements, but there was also a problem with the first windows version of 3.3.2 in the downloads if you got the wrong copy of it.

I tried closing with q but it doesnt change. The flickering is a bit less, especially for the first board but it goes on somehow. And there is no process open anymore.

I already use 3.3.3 after i saw it some hours ago.

Will there be a miner-setting-menu at some point? So that cgminer dont have to be restarted for volt- and clockchanges?

And when i use

Code:

start ./cgminer-nogpu -o stratum+tcp://mmpool.bitparking.com:3333 -u * -p d=8 --avalon-freq 350

it seems to not having an effect on the hashrate.

[itod]

The lights are a bit different form board to board. All green lights are the same. The board i put the usb in is blinking yellow very often, seldom red. The second board blinks half so often but most of the time yellow and red. Third similar but seldom at the same time. The next blinks more seldom and red any yellow are similar often. The fifth blinks seldom and sometimes more red than others.

It looks like the first miner with usb connected works more than any other.

What is the miner doing when i close cgminer and it still works on?

Not closing an old cgminer properly? (see task manager)
It is always best to quit with 'q' and see it exit - windows ...

Also try 3.3.3 and see if it has that windows problem you mentioned.
I'll try my BTB on windows again today with 3.3.3 and see if I have any problems.

I've not built 3.3.3 yet, it was only released last night while I was asleep - it's mainly CPU improvements, but there was also a problem with the first windows version of 3.3.2 in the downloads if you got the wrong copy of it.

I tried closing with q but it doesnt change. The flickering is a bit less, especially for the first board but it goes on somehow. And there is no process open anymore.

I already use 3.3.3 after i saw it some hours ago.

Will there be a miner-setting-menu at some point? So that cgminer dont have to be restarted for volt- and clockchanges?

And when i use

Code:

start ./cgminer-nogpu -o stratum+tcp://mmpool.bitparking.com:3333 -u * -p d=8 --avalon-freq 350

it seems to not having an effect on the hashrate.

Maybe it's time for good-old problem solving technique: reduction to properly working minimum, then adding things one by one. Disconnect the boards, then power and test one by one. Make sure that each one is working as it should and that each one gives the same result. Then make a pair, and finally completely connect everything. Somewhere along this process things will start working properly, or a problem will be pinpointed.

[kano]

try
./cgminer-nogpu -o ... --avalon-options 115200:2:10:35:350

If you have different per device settings to 2x10 chips - set those numbers as appropriate

Also, I run mine at 400 without any problems: --avalon-options 115200:2:10:30:400
( ~1.4% errors and: --avalon-fan 99-100 )

 BTB  0: 48/ 48C 1225mV | 8.228G/7.766Gh/s | A:150253 R:930 HW:2107 WU:110.0/m
(approx 23 hours)

[SebastianJu]

The lights are a bit different form board to board. All green lights are the same. The board i put the usb in is blinking yellow very often, seldom red. The second board blinks half so often but most of the time yellow and red. Third similar but seldom at the same time. The next blinks more seldom and red any yellow are similar often. The fifth blinks seldom and sometimes more red than others.

It looks like the first miner with usb connected works more than any other.

What is the miner doing when i close cgminer and it still works on?

Not closing an old cgminer properly? (see task manager)
It is always best to quit with 'q' and see it exit - windows ...

Also try 3.3.3 and see if it has that windows problem you mentioned.
I'll try my BTB on windows again today with 3.3.3 and see if I have any problems.

I've not built 3.3.3 yet, it was only released last night while I was asleep - it's mainly CPU improvements, but there was also a problem with the first windows version of 3.3.2 in the downloads if you got the wrong copy of it.

I tried closing with q but it doesnt change. The flickering is a bit less, especially for the first board but it goes on somehow. And there is no process open anymore.

I already use 3.3.3 after i saw it some hours ago.

Will there be a miner-setting-menu at some point? So that cgminer dont have to be restarted for volt- and clockchanges?

And when i use

Code:

start ./cgminer-nogpu -o stratum+tcp://mmpool.bitparking.com:3333 -u * -p d=8 --avalon-freq 350

it seems to not having an effect on the hashrate.

Maybe it's time for good-old problem solving technique: reduction to properly working minimum, then adding things one by one. Disconnect the boards, then power and test one by one. Make sure that each one is working as it should and that each one gives the same result. Then make a pair, and finally completely connect everything. Somewhere along this process things will start working properly, or a problem will be pinpointed.

I tried this now. I found that all boards work like they should when run per usb alone. When using 2 boards together the hashrate doubles but the third starts to not make a big difference. One miner makes 5GH, 2 makes 10GH but three, i tried all remaining three one after another, only leads to number around 9-10GH again. Like it doesnt make a difference. And i used the jumper correctly. The last board at the stacking cable and at the opposite site of the usb-board needs the jumpers. The usb-board itself seems not to need the jumper very much. But now i have the impression the HW-Errors are a bit less when the usb-board has jumpers too. Might be random.
When i put in the remaining 2 miners it only goes to 14.6GH or so and thats it.

try
./cgminer-nogpu -o ... --avalon-options 115200:2:10:35:350

If you have different per device settings to 2x10 chips - set those numbers as appropriate

Also, I run mine at 400 without any problems: --avalon-options 115200:2:10:30:400
( ~1.4% errors and: --avalon-fan 99-100 )

 BTB  0: 48/ 48C 1225mV | 8.228G/7.766Gh/s | A:150253 R:930 HW:2107 WU:110.0/m
(approx 23 hours)

This option seems to work. The hashrate jumped a bit from 14 to 17GH. I used your setting. Unfortunately the HW-Errors rise a lot. A/HW is only slightly better than 100/50. And when i set the voltage to 1300mv it doesnt help. Burnin's Tests showed that raising the voltage would help to lower the HW-Errors. It looks like i dont have luck with this.
And i noticed that the higher clockrate leads to often this line: BTB0: Idled 1 miners. I dont know what this means.
One time the miner crashed after a minute when i ran it with high clock but normal voltage.

I hope theres a solution for the hashrate and the HW-Errors. I updated the firmware of all boards before too.

When i look at the stats... since i use the higher clockrate the temperature isnt anymore around 36°C, its only 24°C now even though the fans arent louder so i doubt they work more.

I use this command in a batch:

Code:

start ./cgminer-nogpu --avalon-options 115200:2:10:35:400 --bitburner-voltage 1300 -o stratum+tcp://mmpool.bitparking.com:3333 -u *** -p d=8

And cgminer shows this after 5 minutes:

Code:

 cgminer version 3.3.3 - Started: [2013-08-13 01:51:50]
--------------------------------------------------------------------------------
 (5s):20.31G (avg):18.06Gh/s | A:1288  R:0  HW:514  WU:252.3/m
 ST: 2  SS: 0  NB: 1  LW: 1654  GF: 0  RF: 0
 Connected to mmpool.bitparking.com diff 8 with stratum as user ***
 Block: 0030fc046f8128ee...  Diff:37.4M  Started: [01:51:50]  Best share: 2.88K
--------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
 BTB 0: 23/ 23C 1298mV | 19.11G/18.54Gh/s | A:1304 R:0 HW:517 WU:259.2/m
--------------------------------------------------------------------------------

 [2013-08-13 01:56:28] Accepted 107ce61b Diff 15/8 BTB 0
 [2013-08-13 01:56:28] BTB0: Idled 1 miners
 [2013-08-13 01:56:28] BTB0: Idled 1 miners
 [2013-08-13 01:56:28] Accepted 14f68789 Diff 12/8 BTB 0
 [2013-08-13 01:56:29] Avalon: Discarding 2 bytes from buffer
 [2013-08-13 01:56:29] BTB0: Idled 1 miners
 [2013-08-13 01:56:29] BTB0: Idled 1 miners
 [2013-08-13 01:56:29] BTB0: Idled 1 miners
 [2013-08-13 01:56:30] Accepted 1e13072f Diff 8/8 BTB 0
 [2013-08-13 01:56:30] BTB0: Idled 1 miners
 [2013-08-13 01:56:30] BTB0: Idled 1 miners
 [2013-08-13 01:56:30] Accepted 0d8cc151 Diff 18/8 BTB 0
 [2013-08-13 01:56:30] BTB0: Idled 1 miners

[SebastianJu]

It looks like avalon-options was the source for the HW, regardless of what MHz or voltage i used it was always 50%. Even with:

Code:

start ./cgminer-nogpu --avalon-options 115200:2:10:35:282 -o stratum+tcp://mmpool.bitparking.com:3333 -u *** -p d=8

I dont know if i have to change the number before the clockrate but i have 5 bitburner xx which should be 2x10 chips each.

Now that i took out avalon options the hashrate is lower again but zero HW-Errors again.

Ill let it run over night now this way...

[SebastianJu]

I think i know what you mean now. My setup is 10x10 chips. After i tested this i found that the hashrate was quite better now. I checked how far i can go and at 400mhz i got HW-Errors. I raised the voltage to 1.3V and zero HW-Errors again. And now i hash at 38GH/s without HW-Errors.

Unfortunately 420MHz lead to HW-Errors. Ill have to check out how to handle this. But i will let it run now over night.

Im not sure but it seems the avalon option is needed to get the full hashrate. So maybe the recognition isnt working fully right till now so that less chips are found or really used.

Code:

 cgminer version 3.3.3 - Started: [2013-08-13 02:22:35]
--------------------------------------------------------------------------------
 (5s):38.49G (avg):39.16Gh/s | A:8992  R:872  HW:1  WU:547.2/m
 ST: 2  SS: 0  NB: 5  LW: 9020  GF: 0  RF: 0
 Connected to mmpool.bitparking.com diff 8 with stratum as user ***
 Block: 005c9bd179ccdfb1...  Diff:37.4M  Started: [02:29:13]  Best share: 3.43K
--------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
 BTB 0: 49/ 49C 1317mV | 37.82G/39.22Gh/s | A:9032 R:872 HW:1 WU:548.4/m
--------------------------------------------------------------------------------

 [2013-08-13 02:40:30] Accepted 12cda998 Diff 13/8 BTB 0
 [2013-08-13 02:40:32] Accepted 135cc4e2 Diff 13/8 BTB 0
 [2013-08-13 02:40:34] Accepted 180fae6d Diff 10/8 BTB 0
 [2013-08-13 02:40:37] Accepted 1e2e7785 Diff 8/8 BTB 0
 [2013-08-13 02:40:37] Accepted 1bbe59c2 Diff 9/8 BTB 0
 [2013-08-13 02:40:38] Accepted 10e30585 Diff 15/8 BTB 0
 [2013-08-13 02:40:38] Accepted 1363b1a7 Diff 13/8 BTB 0
 [2013-08-13 02:40:39] Accepted 06fd087a Diff 36/8 BTB 0
 [2013-08-13 02:40:40] Accepted 06d0a633 Diff 37/8 BTB 0
 [2013-08-13 02:40:40] Accepted 05b7b9e8 Diff 44/8 BTB 0
 [2013-08-13 02:40:41] Accepted 151473a1 Diff 12/8 BTB 0
 [2013-08-13 02:40:41] Accepted 0a2af487 Diff 25/8 BTB 0
 [2013-08-13 02:40:41] Accepted 1fc21a8e Diff 8/8 BTB 0

[kano]

The default avalon settings match a default BTB (although the '2' is wrong, it doesn't matter)
If you chain them, then you'll need to use --avalon-options

With 35:350, the 35 timeout is important to get correct to stop duplicates.
I'll look into adding the option to use a flag (e.g. d or * or ? or -1 or some such) so that it calculates it for you if you don't want to.
When you switch the frequency via the API it recalculates the timeout for you.
(so if you just set the frequency the same as it currently is, it will correct the timeout)

At the moment the firmware doesn't return information about the internal configuration, but that will be coming soon and I'll then get the code to use that to determine the correct "2x10" for the chips.

[burnin]

Meaning of the LEDs:

Green:
steady blinking - board is operational
off - in bootloader or something is wrong

Orange:
flashing - active data transfer from this board (this is a good indicator if CAN works or not)
off - no data transfer in progress from this board

Red:
steady blinking - board is in bootloader mode, it will jump to the firmware in a few seconds.
short red flash - found a nonce
solid red - something went horribly wrong

@SebastianJu
What  read from that cgminer output: 39.2ghash, perfect in line with 5x20x400mhz = 40ghash.
A few HW errors are to be expected when going past 400, but are not a problem.

[Stack]

solid red - something went horribly wrong

[AMD FTW]

solid red - something went horribly wrong

had a few drinks and this had me laughing out loud..

[maxmint]

With 35:350, the 35 timeout is important to get correct to stop duplicates.

What would be the correct timeout for 430?
I'm currently running my 16 boards with this config:

--avalon-options 115200:32:10:35:430 --bitburner-voltage 1300 --avalon-temp 45

Anything wrong with these parameters?

[burnin]

Anything wrong with these parameters?

You got them from me, they are correct. 

btw if you hook 16 boards up to a single 1000W PSU don't exceed 360Mhz.

[alexuk]

Got this from the DHL track and trace:

Tue, 13.08.2013 07:58 h --- The shipment was misrouted and could not be delivered. The shipment will
be readdressed and forwarded to the recipient.


Called DHL Express, said they couldn't help, as the shipping number doesn't up on their system, and that it was shipped by German post?

Confused here, i thought it was DHL - Burnin - sent you an email about it, can you check the shipping details?

Thanks!

[maxmint]

Anything wrong with these parameters?

You got them from me, they are correct.  

Of course
You gave me the config for a 8 board cluster, I just wanted to make sure my config would be correct for a 16 board cluster as well.
EDIT: Actually, I'm running 2 separate units with 8 boards each, so I'm not quite sure whether I should use 16 or 32 as number of miners. (cgminer shows BTB 0 and BTB 1)

Seems to be working good, 16 boards running at 128 GH/s.

Still not sure about the timeout part though (and about its exact meaning).

btw if you hook 16 boards up to a single 1000W PSU don't exceed 360Mhz.

Thanks for letting me know. I got me another PSU so this should be no problem.

[kano]

As I mentioned on the previous page, to get the timeout correct:
https://bitcointalk.org/index.php?topic=179769.msg2921457#msg2921457

When you switch the frequency via the API it recalculates the timeout for you.
(so if you just set the frequency the same as it currently is, it will correct the timeout)

But it also shows you on the screen (and it's in the API stats)

If you have 1 board 2x10 then the options are 115200:2:10...
If you have two boards chained together with 4x10 then the options are 115200:4:10...
etc.

[Fizban]

As I mentioned on the previous page, to get the timeout correct:
https://bitcointalk.org/index.php?topic=179769.msg2921457#msg2921457

When you switch the frequency via the API it recalculates the timeout for you.
(so if you just set the frequency the same as it currently is, it will correct the timeout)

But it also shows you on the screen (and it's in the API stats)

If you have 1 board 2x10 then the options are 115200:2:10...
If you have two boards chained together with 4x10 then the options are 115200:4:10...
etc.

And what about 1x20 and 1x10?
Should be possible =)

[kano]

As I mentioned on the previous page, to get the timeout correct:
https://bitcointalk.org/index.php?topic=179769.msg2921457#msg2921457

When you switch the frequency via the API it recalculates the timeout for you.
(so if you just set the frequency the same as it currently is, it will correct the timeout)

But it also shows you on the screen (and it's in the API stats)

If you have 1 board 2x10 then the options are 115200:2:10...
If you have two boards chained together with 4x10 then the options are 115200:4:10...
etc.

And what about 1x20 and 1x10?
Should be possible =)

There is no 1x20 it's 2x10 to cgminer.

[eraziel]

Picked up my BitBurner today after work and it's happily mining @ 8GH/s and 46C, HW faults below 2%

#feelsgood