Bitcoin Forum
June 25, 2024, 08:30:04 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 [92] 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 »
1821  Bitcoin / Hardware / Re: Avalon ASIC users thread on: June 22, 2013, 07:30:48 PM
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;
        }
1822  Bitcoin / Hardware / Re: Avalon ASIC users thread on: June 22, 2013, 01:50:26 PM
Some results so far 350 with fans hacked to max speed Wink

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

1823  Bitcoin / Hardware / Re: Avalon ASIC users thread on: June 22, 2013, 10:29:39 AM
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
1824  Bitcoin / Hardware / Re: Avalon ASIC users thread on: June 21, 2013, 11:32:54 PM
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 Smiley
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
1825  Bitcoin / Hardware / Re: Avalon ASIC users thread on: June 21, 2013, 12:39:36 PM
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  Wink

Thank You!

1826  Bitcoin / Hardware / Re: Avalon ASIC users thread on: June 21, 2013, 12:32:24 PM
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
1827  Bitcoin / Hardware / Re: Avalon ASIC users thread on: June 21, 2013, 12:26:43 PM
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?

 
1828  Bitcoin / Hardware / Re: Avalon ASIC users thread on: June 21, 2013, 12:03:00 PM
After a few more minutes it's up to
              
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  Wink I will be gentle start with 325 first
1829  Bitcoin / Hardware / Re: Avalon ASIC users thread on: June 21, 2013, 11:58:36 AM
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!


1830  Bitcoin / Hardware / Re: Avalon ASIC users thread on: June 21, 2013, 11:43:12 AM
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 Wink And i will share my findings in the morning. Let us hope that bitminter will not be dosed overnight

Thank you very much CON!
1831  Bitcoin / Hardware / Re: How can I clock Avalon to 325 MHz and beyond? on: June 21, 2013, 11:40:10 AM
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 Smiley
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


1832  Bitcoin / Hardware / Re: How can I clock Avalon to 325 MHz and beyond? on: June 21, 2013, 11:21:09 AM
Good Question


It is possible for sure here is the evidence

https://bitcointalk.org/index.php?topic=234173.msg2478266#msg2478266

I am wandering how burnin made them work at 125 for testing

https://bitcointalk.org/index.php?topic=179769.msg2536501#msg2536501

PS: How do you know that 325MHz, 350MHz, and 375MHz are possible at all?




1833  Bitcoin / Hardware / Re: [ATTN] Is there anyone still not receive your batch#2 machine or tracking #? on: June 21, 2013, 11:15:38 AM
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 .
1834  Bitcoin / Pools / Re: [12 TH/s] BitMinter.com [ASIC support: var diff, Stratum, GBT, rollntime] on: June 21, 2013, 11:07:48 AM
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.

1835  Bitcoin / Pools / Re: [12 TH/s] BitMinter.com [ASIC support: var diff, Stratum, GBT, rollntime] on: June 21, 2013, 07:03:38 AM
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  Cheesy  
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 Wink

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  Smiley




1836  Bitcoin / Pools / Re: [12 TH/s] BitMinter.com [ASIC support: var diff, Stratum, GBT, rollntime] on: June 20, 2013, 02:56:54 PM
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%  Smiley And it can take a long time and stay on 99% but we will go over it for sure. Good times are coming!
1837  Bitcoin / Pools / Re: [12 TH/s] BitMinter.com [ASIC support: var diff, Stratum, GBT, rollntime] on: June 20, 2013, 01:30:25 PM
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  Cheesy  
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 Wink

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








1838  Bitcoin / Hardware / Re: [AVALON] - I got my ASIC Thread (Batch #2) on: June 20, 2013, 09:12:39 AM
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

1839  Bitcoin / Hardware / Re: Klondike - 16 chip ASIC Open Source Board - Preliminary on: June 20, 2013, 08:32:16 AM
Bad news Angry

It is not your fault BKK so do not blame yourself for that. Kep us informed pls
Thank you very much
1840  Bitcoin / Hardware / Re: Klondike - 16 chip ASIC Open Source Board - Preliminary on: June 20, 2013, 06:12:32 AM
Bkk,

Are there any news about I/O and chip communication yet? How is it going?
10X
Pages: « 1 ... 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 [92] 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!