Wow... with all these improvements, Batch3 is going to be great!
Actually this is all software...
Topic: Avalon ASIC users thread - page 170. (Read 438516 times)
Okay I experimented with different frequencies around 350, and the hardware error count was about 1.8% by the time it was at 350, but the effective useful hashrate was the highest there, so on my hardware at least, 350 really is a sweet spot. It ran for 45 minutes and averaged about 82.3GH of submitted shares. An extra 11GH for another 10W is ... quite remarkable. I get ~82GH for 605W (at 240V) at the wall now where I used to get ~71GH at 595W at frequency 300.
Actually this is all software...
Actually this is all software...
Wow... with all these improvements, Batch3 is going to be great!
Con,
Just a thought about 39:325. I do not know why 40:300 was increased to 43:300 with latest updates, but i am positive that 3.1 with 40:300 is making 70500-71000 stable. Following that logic will 37:325 be better?
No, the latency number (43) only affects the risk of duplicates and the code has been so drastically changed since the original code that the higher value is actually better since it reloads work less frequently and uses less CPU without any chance of dupes.Just a thought about 39:325. I do not know why 40:300 was increased to 43:300 with latest updates, but i am positive that 3.1 with 40:300 is making 70500-71000 stable. Following that logic will 37:325 be better?
Super!
Thank you for the explanation.
Best
Con,
Just a thought about 39:325. I do not know why 40:300 was increased to 43:300 with latest updates, but i am positive that 3.1 with 40:300 is making 70500-71000 stable. Following that logic will 37:325 be better?
No, the latency number (43) only affects the risk of duplicates and the code has been so drastically changed since the original code that the higher value is actually better since it reloads work less frequently and uses less CPU without any chance of dupes. Just a thought about 39:325. I do not know why 40:300 was increased to 43:300 with latest updates, but i am positive that 3.1 with 40:300 is making 70500-71000 stable. Following that logic will 37:325 be better?
Con,
Just a thought about 39:325. I do not know why 40:300 was increased to 43:300 with latest updates, but i am positive that 3.1 with 40:300 is making 70500-71000 stable. Following that logic will 37:325 be better?
Just a thought about 39:325. I do not know why 40:300 was increased to 43:300 with latest updates, but i am positive that 3.1 with 40:300 is making 70500-71000 stable. Following that logic will 37:325 be better?
After a few more minutes it's up to
Power usage only went up by 5W going to 325 and 10W going to 350. 375 was unstable. The code is already in git master along with the values in ASIC README
34:375
36:350
39:325
Since mine is a batch 2, it has a 750W PSU and it does not seem to be a power issue at 350, but HW errors go nuts above this.
Code:
(5s):83.39G (avg):82.64Gh/s | A:350 R:0 HW:357 U:21.4/m WU:1173.2/m
Power usage only went up by 5W going to 325 and 10W going to 350. 375 was unstable. The code is already in git master along with the values in ASIC README
34:375
36:350
39:325
Since mine is a batch 2, it has a 750W PSU and it does not seem to be a power issue at 350, but HW errors go nuts above this.
Wow, that's damn impressive. I smell a hashrate spike!
Nice work and thank you for sharing your results.
I upgraded to the 860i and I find that as long as the ambient temps are in the 20 range then the hardware should be able to cope with the increased speed.
After a few more minutes it's up to
Power usage only went up by 5W going to 325 and 10W going to 350. 375 was unstable. The code is already in git master along with the values in ASIC README
34:375
36:350
39:325
Since mine is a batch 2, it has a 750W PSU and it does not seem to be a power issue at 350, but HW errors go nuts above this.
Code:
(5s):83.39G (avg):82.64Gh/s | A:350 R:0 HW:357 U:21.4/m WU:1173.2/m
Power usage only went up by 5W going to 325 and 10W going to 350. 375 was unstable. The code is already in git master along with the values in ASIC README
34:375
36:350
39:325
Since mine is a batch 2, it has a 750W PSU and it does not seem to be a power issue at 350, but HW errors go nuts above this.
does the Avalon temp increase?
After a few more minutes it's up to
Power usage only went up by 5W going to 325 and 10W going to 350. 375 was unstable. The code is already in git master along with the values in ASIC README
34:375
36:350
39:325
Since mine is a batch 2, it has a 750W PSU and it does not seem to be a power issue at 350, but HW errors go nuts above this.
Code:
(5s):83.39G (avg):82.64Gh/s | A:350 R:0 HW:357 U:21.4/m WU:1173.2/m
Power usage only went up by 5W going to 325 and 10W going to 350. 375 was unstable. The code is already in git master along with the values in ASIC README
34:375
36:350
39:325
Since mine is a batch 2, it has a 750W PSU and it does not seem to be a power issue at 350, but HW errors go nuts above this.
does the Avalon temp increase?
After a few more minutes it's up to
Power usage only went up by 5W going to 325 and 10W going to 350. 375 was unstable. The code is already in git master along with the values in ASIC README
34:375
36:350
39:325
Since mine is a batch 2, it has a 750W PSU and it does not seem to be a power issue at 350, but HW errors go nuts above this.
Code:
(5s):83.39G (avg):82.64Gh/s | A:350 R:0 HW:357 U:21.4/m WU:1173.2/m
Power usage only went up by 5W going to 325 and 10W going to 350. 375 was unstable. The code is already in git master along with the values in ASIC README
34:375
36:350
39:325
Since mine is a batch 2, it has a 750W PSU and it does not seem to be a power issue at 350, but HW errors go nuts above this.
Wow, that's damn impressive. I smell a hashrate spike!
After a few more minutes it's up to
Power usage only went up by 5W going to 325 and 10W going to 350. 375 was unstable. The code is already in git master along with the values in ASIC README
34:375
36:350
39:325
Since mine is a batch 2, it has a 750W PSU and it does not seem to be a power issue at 350, but HW errors go nuts above this.
Code:
(5s):83.39G (avg):82.64Gh/s | A:350 R:0 HW:357 U:21.4/m WU:1173.2/m
Power usage only went up by 5W going to 325 and 10W going to 350. 375 was unstable. The code is already in git master along with the values in ASIC README
34:375
36:350
39:325
Since mine is a batch 2, it has a 750W PSU and it does not seem to be a power issue at 350, but HW errors go nuts above this.
Thanks a lot!
It seems that it will be sleepless night for me
I will be gentle start with 325 first
After a few more minutes it's up to
Power usage only went up by 5W going to 325 and 10W going to 350. 375 was unstable. The code is already in git master along with the values in ASIC README
34:375
36:350
39:325
Since mine is a batch 2, it has a 750W PSU and it does not seem to be a power issue at 350, but HW errors go nuts above this.
Code:
(5s):83.39G (avg):82.64Gh/s | A:350 R:0 HW:357 U:21.4/m WU:1173.2/m
Power usage only went up by 5W going to 325 and 10W going to 350. 375 was unstable. The code is already in git master along with the values in ASIC README
34:375
36:350
39:325
Since mine is a batch 2, it has a 750W PSU and it does not seem to be a power issue at 350, but HW errors go nuts above this.
Even better, I've tried implementing overclocking to higher frequencies and can get my Avalon stable at 350 (without any voltage mods).
It was unstable at 375, but this is at 350 (diff 56) after a few mins:
(5s):81.58G (avg):81.55Gh/s | A:144 R:0 HW:135 U:22.4/m WU:1158.3/m
Nice!It was unstable at 375, but this is at 350 (diff 56) after a few mins:
(5s):81.58G (avg):81.55Gh/s | A:144 R:0 HW:135 U:22.4/m WU:1158.3/m
What timing have you used (--avalon-options)?
Did you change PSU? I am positive that stock green power 650W will die. Did you measure Power consumption?
PS: Can you post a patch for overclocking somewhere?
10X
And Congats Enjoy your Avalon toy!
Even better, I've tried implementing overclocking to higher frequencies and can get my Avalon stable at 350 (without any voltage mods).
It was unstable at 375, but this is at 350 (diff 56) after a few mins:
(5s):81.58G (avg):81.55Gh/s | A:144 R:0 HW:135 U:22.4/m WU:1158.3/m
It was unstable at 375, but this is at 350 (diff 56) after a few mins:
(5s):81.58G (avg):81.55Gh/s | A:144 R:0 HW:135 U:22.4/m WU:1158.3/m
With my deep respect to Con and Kano i can state following:
I calculate my ACTUAL hash rate as advised by Kano taking in account Diff1 shares accepted from pool(s) and cgminer up-time. This gives me EXACT (Real) hashrate. Knowing the fact my network was fine and i did not have downtime due to Network issues, pool issues or FPGA controller hangs (I am monitoring it every two minutes + automated power off/on no reboots) i am 100% sure that 3.2 is not performing.
PS: just for the reference (do math yourself)
Computer: cgminer 3.1.1
Elapsed: 7h 11m 30s
Difficulty Accepted:431530.00000000
MHS:71587.77
That was not happening with 3.2
I calculate my ACTUAL hash rate as advised by Kano taking in account Diff1 shares accepted from pool(s) and cgminer up-time. This gives me EXACT (Real) hashrate. Knowing the fact my network was fine and i did not have downtime due to Network issues, pool issues or FPGA controller hangs (I am monitoring it every two minutes + automated power off/on no reboots) i am 100% sure that 3.2 is not performing.
PS: just for the reference (do math yourself)
Computer: cgminer 3.1.1
Elapsed: 7h 11m 30s
Difficulty Accepted:431530.00000000
MHS:71587.77
That was not happening with 3.2
Found the regression and I've rewritten the code to avoid this performance loss. It is committed to the master git tree now and will be in the next release. Hopefully xiangfu will be able to make an official testing firmware with it before then too.
I will test it tonight
And i will share my findings in the morning. Let us hope that bitminter will not be dosed overnightThank you very much CON!
With my deep respect to Con and Kano i can state following:
I calculate my ACTUAL hash rate as advised by Kano taking in account Diff1 shares accepted from pool(s) and cgminer up-time. This gives me EXACT (Real) hashrate. Knowing the fact my network was fine and i did not have downtime due to Network issues, pool issues or FPGA controller hangs (I am monitoring it every two minutes + automated power off/on no reboots) i am 100% sure that 3.2 is not performing.
PS: just for the reference (do math yourself)
Computer: cgminer 3.1.1
Elapsed: 7h 11m 30s
Difficulty Accepted:431530.00000000
MHS:71587.77
That was not happening with 3.2
I calculate my ACTUAL hash rate as advised by Kano taking in account Diff1 shares accepted from pool(s) and cgminer up-time. This gives me EXACT (Real) hashrate. Knowing the fact my network was fine and i did not have downtime due to Network issues, pool issues or FPGA controller hangs (I am monitoring it every two minutes + automated power off/on no reboots) i am 100% sure that 3.2 is not performing.
PS: just for the reference (do math yourself)
Computer: cgminer 3.1.1
Elapsed: 7h 11m 30s
Difficulty Accepted:431530.00000000
MHS:71587.77
That was not happening with 3.2
Found the regression and I've rewritten the code to avoid this performance loss. It is committed to the master git tree now and will be in the next release. Hopefully xiangfu will be able to make an official testing firmware with it before then too.
I would like to set all this up in my house. Here, we have 120 volt lines and 15 amp breakers.
so on circuit you can have 120 x 15= 1800 Watts maximum (not taking in account Cos phi effects and such)
Buy a kill-a-watt and mesure the exact consumption of your individual machines in action. Slap on some extra safety margin
For example, with this weather, my Batch #1 Avalon @ 300 MHz are consuming 655 Watts
So three machines would be > 1800 (and I would not try to load it to 99%)
You should not go over 80% for a continuous load like a miner. Keep it under 1440 watts for a 15 amp breaker.
May I ask what the direct USB feature is?
Somewhat along these lines: USB communication to the USB chip without UART emulation
May I ask what the direct USB feature is?
Hi Avalon users
The first direct usb firmware released (Version: 20130607)
Please read the ChangeLog before reflash, here: https://en.bitcoin.it/wiki/Avalon#20130607
How to reflash: https://en.bitcoin.it/wiki/Avalon#How_to_reflash
If you have any problem on Avalon, please read/search this page first: https://en.bitcoin.it/wiki/Avalon.
Best Regards
Xiangfu
The first direct usb firmware released (Version: 20130607)
Please read the ChangeLog before reflash, here: https://en.bitcoin.it/wiki/Avalon#20130607
How to reflash: https://en.bitcoin.it/wiki/Avalon#How_to_reflash
If you have any problem on Avalon, please read/search this page first: https://en.bitcoin.it/wiki/Avalon.
Best Regards
Xiangfu
Aren't all current units arriving with this modification already performed?
Mine were part of the earlier batch 2 deliveries with the F1 fuse still present. Jump to: