Guy's, Just a question it drives me nuts. While changing PSU of my Avalon batch one i removed blue fan connector and forget where it was. I connected it to the last fan connector on controler Now following happens
When avalon boots Blue fan is blowing inside like the rest fans When cgminer starts BLUE fan start to suck - changing the rotation
This is driving me nuts
To be on the safe side i hacked cgminer to max out fan speed that is all.
Here is the patch (by the way - con pls add an option like avalon-fan-max or whatever so we can max out fan performance)
Does your blue fan suck hot air out or blow cold inside while you are mining? I did not pay attention to it but it is stupid fun to suck while other two pwm's blow
temp_new = info->temp_sum / info->temp_history_count;
if (temp_new < 35) { - info->fan_pwm = AVALON_DEFAULT_FAN_MIN_PWM; + //info->fan_pwm = AVALON_DEFAULT_FAN_MIN_PWM; + info->fan_pwm = AVALON_DEFAULT_FAN_MAX_PWM; info->temp_old = temp_new; } else if (temp_new > 55) { info->fan_pwm = AVALON_DEFAULT_FAN_MAX_PWM; info->temp_old = temp_new; } else if (abs(temp_new - info->temp_old) >= 2) { - info->fan_pwm = AVALON_DEFAULT_FAN_MIN_PWM + (temp_new - 35) * 6.4; + info->fan_pwm = AVALON_DEFAULT_FAN_MAX_PWM; + //info->fan_pwm = AVALON_DEFAULT_FAN_MIN_PWM + (temp_new - 35) * 6.4; info->temp_old = temp_new; }
|
|
|
Some results so far 350 with fans hacked to max speed Elapsed 3h 10m 59s Diff1 Accepted 217849.00000000 1140.67/m 81652.35 I am positive that it will stay above 80 in long term I am very happy! Con, can you please advise us how to calculate HW error rate in % Thank you
|
|
|
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
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. Does this new firmware 6/22 include this new code in order to deal with the regression? Yes dude working perfect just grab latest git and hash
|
|
|
Guy's I have changed 650 to 850W PSU just in case. these screws are just fucking killing me. I was not able to screw a single one of them. That were bad news. The good news are: that i am making about 77081.89 average for the last half an hour at 325 I will wait until tomorrow at least 24 hours to see the actual hash rate and i will try 350 PS: Con, Will you tell us the formula in order to calculate HW errors in %.Are shares below target counted somewhere? I know how to cal HW error rate with diff 1 but ..that is not enough
|
|
|
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. Wow... with all these improvements, Batch3 is going to be great!
Actually this is all software... And the guy who is making it Thank You!
|
|
|
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. 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?
|
|
|
After a few more minutes it's up to (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
|
|
|
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! 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!
|
|
|
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
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 overnight Thank you very much CON!
|
|
|
Question: what should be buf[6] and buf[7] for 325MHz, 350MHz, and 375MHz?
if (frequency == 256) { buf[6] = 0x03; buf[7] = 0x08; } else if (frequency == 270) { buf[6] = 0x73; buf[7] = 0x08; } else if (frequency == 282) { buf[6] = 0xd3; buf[7] = 0x08; } else if (frequency == 300) { buf[6] = 0x63; buf[7] = 0x09; }
Use these at your own risk! For 325 MHz: buf[6] = 0x2b and buf[7] = 0x0a For 350 MHz: buf[6] = 0xf3 and buf[7] = 0x0a For 375 MHz: buf[6] = 0xbb and buf[7] = 0x0b The meaning of these values is documented on page 6 of the Avalon ASIC (A3256-Q48) datasheet. Thanks, I guess I need to take a good look at the datasheet first, and then re-compile cgminer with the new avalon driver. And pls make sure to replace stock PSU first Because magic smoke can come out Apart of the joke i am interested how it will go I will watch this tread closely. If someone has made it i will be glad to see that info shred here
|
|
|
Bump
Yo, you've been told recently that they reopened their support tickets at a new location and asked any prior tickets to be re-sent via the new form... I did not yet received any info. I have opened a ticket almost a week ago. I am not complaining however. But there are still a lot of us in my situation. I am confident that i will have my unit delivered by the end of the month though .
|
|
|
Doc I will pop up on Irc to discuss it when i (and you) do have time. I feel I have to stop spamming the topic with FW TCP/UDP and stuff
Thank you very much for your comments.
|
|
|
1. If the attacks are coming from known IP address - rangers you can easy filter them out on 8.8.8.8 With zero CPU/Network load to your Server 8.8.4.4. I am not aware of the attacks details but believe me Empty Linux box doing nothing just natting one IP can filter a lot 2. You can use Connection iptables limit - i am not aware if it is a good or bad idea since some miners can be affected also 3. And other fancy stuff We're not running out of CPU here, but bandwidth. One scrubbing server will just get knocked off the net, same as the mining server itself did. I could perhaps set up multiple 10 Gbps servers to scrub traffic, at a data center with very high bandwidth and where they don't blackhole (nullroute) you when you get DDoSed. I don't know a good place for that, nor if it can be done for a reasonable price. I think for now Black Lotus is a good choice. Doc, In my opinion Black Lotus will not be able to guard your network (bandwidth) usage in case you are victim to UDP due to protocol nature itself. UDP attacks can be filtered in ISP core routers only. If it is a TCP attack it will be OK with both VPN and Black Lotus solution. However what i have noticed so far - when server was down (attacked) it was responding damn fast to wget with 404 page not found. If responses came from your server not from cloudfire it is pretty obvious that there were no issues with bandwidth at all during the attacks. Good luck Doc - choose what you will be comfortable with
|
|
|
Thank you.
I was asking that because it is the first time I notice 2 consecutive blocks with 90+ CdF.
the worst part is that CDF never reaches 100% And it can take a long time and stay on 99% but we will go over it for sure. Good times are coming!
|
|
|
Doc, We do appreciate all of your handwork and efforts I wrote the idea a couple of times but before going with lotus please consider the flowing The example i will use Google public DNS IP's for simplicity: Exposed Machine emty Box just Ovpn+Firewal+Nat (ISP One) Real Bitminter Server (ISP TWO) -------------------------- ------------------------------- 8.8.8.8/OVPN 10.10.10.1 <----------> 8.8.4.4 (Hidden known only by you and 8.8.8.8 box)/OVPN 10.10.10.2 -------------------------- - -------------------------------- Bitminter is known/resolved to 8.8.8.8 All requests (web mining or whatever you need) 10.10.10.2 Is serving the requests+ Policy routing. All requests arrived at are forwarded to 10.10.10.2 OVPN 10.10.10.2 are forwarded back to 10.10.10.1 Hiding your IP All requests coming back from 10.10.10.2 are nated to 8.8.8.8 Doing this you will achive: 1. If the attacks are coming from known IP address - rangers you can easy filter them out on 8.8.8.8 With zero CPU/Network load to your Server 8.8.4.4. I am not aware of the attacks details but believe me Empty Linux box doing nothing just natting one IP can filter a lot 2. You can use Connection iptables limit - i am not aware if it is a good or bad idea since some miners can be affected also 3. And other fancy stuff In the end you are the boss and you will decide what to do no doubt about it but i just wanna know you got the idea Drawbacks some lag will occur (Traffic moving along the ovpn) but it will be not noticed at all especially if you rent second server in a Rack near by And if you decide to do it pls make sure that nginx (or whatever else is there) will never expose 8.8.4.4 IP via http (other) headers to attackers
|
|
|
My is: Date: February 18, 2013 03:23:39 PM and I still did not get it or any tracking info.
Who have payed after me and have received avalon or tracking #?
I want to write ticket to avalon asking to explain that, an I want to be sure that there is someone who I believe should be after me in order and already get machine.
Dude, No one paid after Feb 18. So keep calm. Some orders paid on 18 get delivered though which does not mean that all of them will get delivered before other folks get theirs
|
|
|
Bad news It is not your fault BKK so do not blame yourself for that. Kep us informed pls Thank you very much
|
|
|
Bkk,
Are there any news about I/O and chip communication yet? How is it going? 10X
|
|
|
|