Pages:
Author

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

legendary
Activity: 1904
Merit: 1007
Any word on Batch 2 chips? Has Zefir shipped?

Just be patient. Zefir received them on friday. Give it at least 1-3 days to sort things out and to package the chips. Remember that not all the chips are going to burning and it will take some time to count and pack them.
member
Activity: 70
Merit: 10
Any word on Batch 2 chips? Has Zefir shipped?
sr. member
Activity: 339
Merit: 250
Vice versa is not a meal.
@burnin: Could you do those Overclocking tests in the next time ?
Would be interesting to know what the limiting factor is right now. Heat or the voltage-supply .
If its only a heat problem, people could use watercooled soloutions and stick to higher frequencys.
full member
Activity: 126
Merit: 100
Just another miner
Just a side note about overclocking



Ok, that didn't happen because of overclocking.
Here is the story if anyone is interested to read it.
https://bitcointalksearch.org/topic/m.2886697

legendary
Activity: 2674
Merit: 1083
Legendary Escrow Service - Tip Jar in Profile
@SebastianJu
if the hashrate reduces to over time and you see "idling miner X" messages that means the cgminer version is too old.

I only had this once. Maybe rip has to be restarted every week or so. But i run cgminer 3.3.4 and the newest firmware.

@kano... i use the fans from burnin and the normal setup he suggests for now. I run at 450MHZ all the time with 1335mV, 28ms and with the dust its now at 53°C. cgminer claims after running them 2 days an average hashrate of 43.61GH/s which is 8.722GH/s for one miner. I think a fan that is capable of moving more air per second would help you.
By the way... since cgminer after 1hours gives a relatively exact average, the more after 10hours, the pool, in my case bitparking.com, gives a hashrate jumping between 43.4GH to 46.5GH... so its not really trustworthy.
full member
Activity: 197
Merit: 100
Running at 415mhz 29ms 1250mv and no problems so far. fingers crossed.

BTB 2: 48/ 48C 1266mV | 16.51G/16.01Gh/s | A:10299 R: 67 HW:292 WU:230.3/m
BTB 3: 51/ 51C 1291mV | 17.09G/15.62Gh/s | A:11400 R: 71 HW:336 WU:225.9/m
BTB 4: 51/ 51C 1280mV | 18.19G/16.05Gh/s | A: 9606 R: 70 HW:163 WU:228.1/m
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
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 Tongue
This is java API "ascset|0,mv,1333" just after I restarted

Note the HW Smiley (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

... and still running ...
 BTB 0: 56C 400 1348mV | 8.499G/7.994Gh/s | A:159912 R:1704 HW:6 WU:111.7/m

So certainly getting the expected 8GH/s (the 2nd number 7.994Gh/s) at 400MHz now (and almost no HW) at 1333mV
Runtime is almost 24 hours

I can't really push the MHz up much more due to only having a simple fan to cool it - and staying in the middle 50'sC is what I'd consider ideal.
A better environment and better cooling (like burnin or SebastianJu probably have done) would make 9GH/s seem possible.
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
Code:
usb_write error on avalon write
BTB0: conns error (buffer)
I have nearly the same but only with BFL LS
Code:
2013.08.24 [21:25]  Cannot write to ttyUSB6: device disconnected (output stream gone)
2013.08.24 [21:25]  Probe of port ttyUSB6 failed: timeout
2013.08.24 [21:26]  Cannot write to ttyUSB6: device disconnected (output stream gone)
2013.08.24 [21:27]  Cannot write to ttyUSB6: device disconnected (output stream gone)
2013.08.24 [21:27]  Cannot write to ttyUSB6: device disconnected (output stream gone)
2013.08.24 [21:27]  Probe of port ttyUSB6 failed: timeout

That's not cgminer ...
sr. member
Activity: 322
Merit: 250
Supersonic
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.

Thats what i wondered. So at a diff 8 all shares below 8 are wasted but thats not a problem because the pool pays you more because you only send higher shares to the pool. If that payment is done fair its ok. I only thought that all the wasted shares will summarize to a lot shares. Seems thats no an issue.
If i read it right a difficulty should be a multiple of 8 right? I tried with 5 and with 1000 but it looked like it lead to a lower hashrate. With 8 its good again. So ill try with multiples of 8 now.



AFAIK this depends on the pool. What share setting they have. If on their end its diff 1, then for all your shares (no matter what difficulty share was found) you get rewarded with diff 1 share. If the pool setting is diff 8, then you only send the pool shares of diff 8 and above, the pool would give u 8x the shares of the user mining at diff 1. Many stratum pools decide the share diff per user based on their hashrate to minimize variance and improve efficiency. Higher the share diff, higher your variance ... but over the long term it should average out... but check with your pool operator.
sr. member
Activity: 243
Merit: 250
ALTCOM Ab9upXvD7ChnJxDRZgMmwNNEf1ftCGWrsE
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?

if "idling miner X" messages appear means your are:
using an old cgminer build or the wrong settings

The newest firmware requires the freshest cgminer to function, i don't know if the windows build has those lastest changes in it.
  
@SebastianJu
if the hashrate reduces to over time and you see "idling miner X" messages that means the cgminer version is too old.
legendary
Activity: 2674
Merit: 1083
Legendary Escrow Service - Tip Jar in Profile
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.

Thats what i wondered. So at a diff 8 all shares below 8 are wasted but thats not a problem because the pool pays you more because you only send higher shares to the pool. If that payment is done fair its ok. I only thought that all the wasted shares will summarize to a lot shares. Seems thats no an issue.
If i read it right a difficulty should be a multiple of 8 right? I tried with 5 and with 1000 but it looked like it lead to a lower hashrate. With 8 its good again. So ill try with multiples of 8 now.

Quote

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.

The thing is that its one of the rpi-usb-ports i use. And i use this port from the start. I really dont know why this error started to appear now only since it worked all the time before. Im not even sure it has to do with the newest firmware since the new firmware ran fine for days before too. I dont have a clue if its the usb port of rpi or something with the bitburner. The usb cable is the same too since the start. And this problem only happens when i quit cgminer. Not at another time.
legendary
Activity: 2955
Merit: 1049
Code:
usb_write error on avalon write
BTB0: conns error (buffer)
I have nearly the same but only with BFL LS
Code:
2013.08.24 [21:25]  Cannot write to ttyUSB6: device disconnected (output stream gone)
2013.08.24 [21:25]  Probe of port ttyUSB6 failed: timeout
2013.08.24 [21:26]  Cannot write to ttyUSB6: device disconnected (output stream gone)
2013.08.24 [21:27]  Cannot write to ttyUSB6: device disconnected (output stream gone)
2013.08.24 [21:27]  Cannot write to ttyUSB6: device disconnected (output stream gone)
2013.08.24 [21:27]  Probe of port ttyUSB6 failed: timeout
full member
Activity: 197
Merit: 100
Quote

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.
full member
Activity: 238
Merit: 100
I run Linux on my abacus.
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.
full member
Activity: 197
Merit: 100

Quote

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

legendary
Activity: 2674
Merit: 1083
Legendary Escrow Service - Tip Jar in Profile
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)
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
legendary
Activity: 2674
Merit: 1083
Legendary Escrow Service - Tip Jar in Profile
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...
full member
Activity: 197
Merit: 100
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?
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
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.
Pages:
Jump to: