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

[Josue]

Is there an ongoing doc available (or link) on the overclocking settings for when we get our Burin rigs?
(Something specific to these rigs).

edit - Also, has anyone played with this setting? "--avalon-auto       Adjust avalon overclock frequency dynamically for best hashrate"
I haven't read the whole thread but curious how this compares to manual...

Thx,
IAS

+1

Thanks¡

[1715164167]

1715164167

[1715164167]

1715164167

[peonminer]

I want one so bad! or ten!!

[Its About Sharing]

Is there an ongoing doc available (or link) on the overclocking settings for when we get our Burin rigs?
(Something specific to these rigs).

edit - Also, has anyone played with this setting? "--avalon-auto       Adjust avalon overclock frequency dynamically for best hashrate"
I haven't read the whole thread but curious how this compares to manual...

Thx,
IAS

+1

Thanks¡

Welcome and here is a start, but like I said I'm looking for something regarding these rigs specifically.
https://github.com/ckolivas/cgminer/blob/master/ASIC-README (Seems very simple, not a lot of settings).

IAS

[SebastianJu]

20chips on BBXX = 9gh/s (450 mhz OC)

Till now i didnt find a setting that can do this. And it looks like the temperature the chips have are changing the needed mV to get the best Hashrate, so in theory each Temperature should run its own mV to get the maximum possible hashrate.

Where did you get that from? My 50 chips (20/20/10) run fine at 450 Mhz, 1.330 mV (it seems to overvolt slightly?) and cgminer "d" timing. Rejects and HW errors are reasonable. Temperature is around 47-49°C. I’m stuck on the old firmware because of a broken USB connector or my hashrate would be closer to the theoretical 22.5 GH/s.

I have a feeling that these chips would much higher with better cooling but burnin’s (slightly crude) cooling implementation is hard to beat for price/performance.
Putting fancy copper/heatpipe heatsinks with expensive TIMs on them would probably not make sense from a financial standpoint.

I got that from testing. It seems to make a difference when you run the miner at max 46°C at a certain mV, when its up at 53°C then the hashrate is lower with the same mV. But if you slightly change it you can find the sweet spot again. Its strange but thats my observation.

The newest firmware is indeed good, it gave me a bit speed. I believe 5% more when i remember correctly.

Im not so sure yet with the better cooling. But i will try to change the setting of the fans so that the air is forced through the heatsinks. Maybe it changes something.

You can run it at 450MHz but that doesnt resolve to 9GH/s for me. Till now i didnt find a setting that can do this. And it looks like the temperature the chips have are changing the needed mV to get the best Hashrate, so in theory each Temperature should run its own mV to get the maximum possible hashrate.

have you added the --queue 4 setting to the command line?
That is important to get close to theoretical performance.
My tests showed hashrates very close to 9ghash @ 450mhz for a single board.
Didn't test high OC with a cluster yet though.

I really have to do a MAX-OC test with a single line of chips to find out the real limits.
(maybe even more then 500Mhz)

OC headroom is also chip-dependent, some chips are just better then others.
(One reason why i want to push for individual-per-board OC settings in future firmware revs)

I read the first time of this option. Ill try it. Normally i get the 5 miners slightly above 44GH/s. What does the queue mean to bitburners? Are higher values worth a try?

But i experienced a problem. Today its the second time the miner seems to close down slowly hashratewise. The first time i found after maybe 40minutes. The 5s Hashing was at zero already, now it happened again. The hashing is at 20GH, the watt usage is nearly halved, temperature low and the stats say that the miner is idled often. Im not sure whats the problem but i hope thats not happening over night. The leds were still blinking now. I dont have a clue whats the problem. Does the rpi have to be rebooted some times?

20chips on BBXX = 9gh/s (450 mhz OC)

You can run it at 450MHz but that doesnt resolve to 9GH/s for me. Till now i didnt find a setting that can do this. And it looks like the temperature the chips have are changing the needed mV to get the best Hashrate, so in theory each Temperature should run its own mV to get the maximum possible hashrate.

Well, for me it does:

The pools doesnt calculate very correct in my experience. A 1 hour average of cgminer is more trustworthy. Does it say the same? Whats your options?

[eraziel]

cgminer has no way to measure the actual hashrate of the avalon asic chips, it is estimating based on the nonces returned, just as is the pool you are connected to.

[itod]

I think I need to put the MHz there and one temperature.

Hallelujah.

[kano]

cgminer has no way to measure the actual hashrate of the avalon asic chips, it is estimating based on the nonces returned, just as is the pool you are connected to.

Not quite the same

The pool depends on the shares returned and whatever random calculation they do on that.
The higher difficulty, the higher the variance.

cgminer depends on the nonces found at difficulty 1.

[kano]

I think I need to put the MHz there and one temperature.

Hallelujah.

BTB 0: 47C 400 1225mV | 9.660G/7.839Gh/s | A:78047 R:747 HW:1000 WU:110.9/m

It's in current git master (not enough space to say "MHz" but easy enough to see what it is)

[itod]

I think I need to put the MHz there and one temperature.

Hallelujah.

BTB 0: 47C 400 1225mV | 9.660G/7.839Gh/s | A:78047 R:747 HW:1000 WU:110.9/m

It's in current git master (not enough space to say "MHz" but easy enough to see what it is)

Great!

[RoadStress]

I think I need to put the MHz there and one temperature.

Hallelujah.

BTB 0: 47C 400 1225mV | 9.660G/7.839Gh/s | A:78047 R:747 HW:1000 WU:110.9/m

It's in current git master (not enough space to say "MHz" but easy enough to see what it is)

Looking good!

[kano]

I think I need to put the MHz there and one temperature.

Hallelujah.

BTB 0: 47C 400 1225mV | 9.660G/7.839Gh/s | A:78047 R:747 HW:1000 WU:110.9/m

It's in current git master (not enough space to say "MHz" but easy enough to see what it is)

Still running at 400 but I didn't put the voltage up
This is java API "ascset|0,mv,1333" just after I restarted

Note the HW (due to the higher voltage)
 BTB 0: 55C 400 1353mV | 10.38G/7.905Gh/s | A:12635 R:80 HW:1 WU:110.5/m

[SebastianJu]

I found that my miners temperature is higher now than from the start. Before it was never above 49°C, now its at 53°C. I see a bit dust and i wonder if that bit dust can have such a great effect... can only test it.

Yesterday i had some problems with disabling cgminer. It stated then comms error buffer or something and cgminer did not close even after long time. I had to use a new tab for restart.

cgminer has no way to measure the actual hashrate of the avalon asic chips, it is estimating based on the nonces returned, just as is the pool you are connected to.

In my tests i found that the pools hashrate is very volatile. Using the same setting at the same temperature with cgminer gives nearly the same average hashrate after 1 hour. Its different with the pools hashrate. Even when i take an average out of the last 10 shown hashrate values. So i trust more the values i get from cgminer.

What i wonder... when i set the difficulty to 1000 doesnt i lose mining income? I mean cgminer only is sending such high shares to the pool then. All other shares are discarded. And there are a lot smaller shares at 1 and so. So doesnt this mean to lose much or doesnt this matter? I normally run with diffi 8 but if it doesnt matter i would use maybe 1000 or so.

[kano]

I found that my miners temperature is higher now than from the start. Before it was never above 49°C, now its at 53°C. I see a bit dust and i wonder if that bit dust can have such a great effect... can only test it.

Yesterday i had some problems with disabling cgminer. It stated then comms error buffer or something and cgminer did not close even after long time. I had to use a new tab for restart.

cgminer has no way to measure the actual hashrate of the avalon asic chips, it is estimating based on the nonces returned, just as is the pool you are connected to.

In my tests i found that the pools hashrate is very volatile. Using the same setting at the same temperature with cgminer gives nearly the same average hashrate after 1 hour. Its different with the pools hashrate. Even when i take an average out of the last 10 shown hashrate values. So i trust more the values i get from cgminer.

What i wonder... when i set the difficulty to 1000 doesnt i lose mining income? I mean cgminer only is sending such high shares to the pool then. All other shares are discarded. And there are a lot smaller shares at 1 and so. So doesnt this mean to lose much or doesnt this matter? I normally run with diffi 8 but if it doesnt matter i would use maybe 1000 or so.

No, setting the difficulty higher only increases the variance.

So e.g. 1000 diff vs 10 diff means you will submit (on average) one in every 1000 nonces found rather than on in every 10.
However each nonce submitted will be worth 1000 1diff shares rather than 10 1diff shares.
So ... yes ... simply ... higher variance, nothing more.

At the moment my main rig (125.5GH/s) is mining at 2176 diff ... about 1 share per 48 seconds.

[LordTheron]

hi guys,

What doeas it mean BTB:0 Ideled 1 miners? I get that very frequently. It seems to more frequent when i have my biburners clustered. At the moment im running 4 clusters with 2 BB each, and 1 single. Also I have noticed that my cgminer is freezing twice a day( windows and rpi), but not crashing. Looks like its hashing but no submits, rejects or hw errors. Back to hashing after cgminer reboot.

Last night I noticed another thing. I had 2 cluster with 4 Bb each, and both ware hashing at 30gh average for the past 6 hours. Then hash rate dropped to around 20gh per cluster and I couldn't get them to hash as before. Powered down everything,  and nothing changed. Both clusters wouldn't go above 20gh. So I've broken down clusters to 4x2 and the speed is much better about 14.8gh per cluster. I cant explain why this is happening. I have 1000W psu and have 9 BB powered from it. Is it possible that the psu cant deliver stable power and that in turns affect the miners stability and speed?

[SebastianJu]

I found that my miners temperature is higher now than from the start. Before it was never above 49°C, now its at 53°C. I see a bit dust and i wonder if that bit dust can have such a great effect... can only test it.

Yesterday i had some problems with disabling cgminer. It stated then comms error buffer or something and cgminer did not close even after long time. I had to use a new tab for restart.

cgminer has no way to measure the actual hashrate of the avalon asic chips, it is estimating based on the nonces returned, just as is the pool you are connected to.

In my tests i found that the pools hashrate is very volatile. Using the same setting at the same temperature with cgminer gives nearly the same average hashrate after 1 hour. Its different with the pools hashrate. Even when i take an average out of the last 10 shown hashrate values. So i trust more the values i get from cgminer.

What i wonder... when i set the difficulty to 1000 doesnt i lose mining income? I mean cgminer only is sending such high shares to the pool then. All other shares are discarded. And there are a lot smaller shares at 1 and so. So doesnt this mean to lose much or doesnt this matter? I normally run with diffi 8 but if it doesnt matter i would use maybe 1000 or so.

No, setting the difficulty higher only increases the variance.

So e.g. 1000 diff vs 10 diff means you will submit (on average) one in every 1000 nonces found rather than on in every 10.
However each nonce submitted will be worth 1000 1diff shares rather than 10 1diff shares.
So ... yes ... simply ... higher variance, nothing more.

At the moment my main rig (125.5GH/s) is mining at 2176 diff ... about 1 share per 48 seconds.

Do you say all the small 1 diff shares are collected and then sent when at least 1000 shares are together? Might be true since the shares climbed in thousand steps onward. Which means they probably are summarized instead randomly having exactly 1000 shares found at once.
Looks like the diff then only changes the amount of connections to the pool and how big or small the sharepacket is.

@Lord Theron... did you change the avalon-options accordingly to the amount of miners clustered?

@burnin... i tested --avalon-queue but i dont see a big difference...

[kano]

No

[SebastianJu]

Then ill take it that all shares found below the diff set arent lost when you use such a high diff.

But i have another problem that occured lately. Restart of rpi didnt help.

Often when i close cgminer with q to use another setting i get the following message and after them nothing happens. cgminer wont close anymore then:

Code:

usb_write error on avalon write
BTB0: conns error (buffer)

[LordTheron]

@Lord Theron... did you change the avalon-options accordingly to the amount of miners clustered?

Yes mate I did. I've set my diff to 128 it seems to help with Idle miners.

[shapemaker]

Then ill take it that all shares found below the diff set arent lost when you use such a high diff.

If you set the diff at X, you won't send any nonces found which are below X in difficulty. But one correct result (diff at X or higher) is worth X shares. The idea behind this is to lessen the impact of fast ASICs on pools. There simply is no need to send all the diff 1 work, when you can send, say, 1 diff 32 (or higher) result and get 32 shares accepted. Also network bandwidth is saved.

So, in essence, all the nonces your ASICs find that have difficulty below X are "wasted", but the valid nonces are also worth more. It will even out over time.

[LordTheron]

Code:

usb_write error on avalon write
BTB0: conns error (buffer)

Try different usb hub. I've had that on one of my hubs.  Especially if you use rpi, Ive used that hub on pc and I dont get that errors anymore. At the same time I bought belkin hub yesterday and that works fine with rpi and pc but I can only use 4 out 7 ports. What I dont get is that I can use my BFL miners on any hub and any host with no problems, but for some reason bitburners are very picky when it comes to hubs or rpi is. Now I have worked out which hubs works where, I dont get usb write errors so try to play around and see if it helps.