|
Looks like its pulling around 180 watts for me...which is pretty horrible considering this is supposed to be a 150 watt card. I guess considering the higher hashrate its not bad, but definitely higher than i expected.
|
|
|
|
Getting about 26-27 MH on mine with basic settings that can be adjusted via crimson. Ill measure exact power draw in a bit, but running around 80c with very quiet fan profile (50% fan speed). This should easily hit 30 MH once non reference cards hit.  |
|
|
|
|
Yea not sure whats going on here...they seemed like they had sample chips in from the fab last month and published those "tested" 1.5 w/MH specs, which is in line with what a 14nm scrypt chip *should* do. Now they are stating 4 w/mh??? Thats very fishy...I got 5 w/mh efficiency out of the 40nm Alcheminer chip on my USB miner. The only thing I can think of is that yield so horrible that they are only getting 1/4 functional cores per silicon area. That or they are selling an improved version of their 28nm chip and saying its 14nm...
|
|
|
|
Thanks, I didn't encounter that during my own tests.
can you push the fix to that to your repo? |
|
|
|
It is 3D mark, so it is not too relavant to the Ethereum mining. It is even 40% slower than 1070, not very encouraging. seems that the 480 is close to nano speed and caps out at 100 watts http://wccftech.com/amd-rx-480-faster-than-nano-980/I expect it to be the go to card for eth mining in the next few months Hope it is good. My only concern is the memory width of only 256 bit, it might be just a little faster than 380. Not considering architectural and slightly higher CU changes between the 380 and 480 and on base clocks that 380 does 21MH/s @ 1500 mem clock, the 480 *should* run AT LEAST 28MH with its mem clock of 2000. I wouldn't be surprised if we see 30+ on it with just small OC's. |
|
|
|
I'm confused. Now they are giving us two temp readings. In the past, for the S7 and others have we just been seeing the pcb temp (labeled: Temp).
Then why now they showing us the chip temp. Why is that important now? Poor design?
My pcb temps are running 56, 56, 59 at 625M. On any other Antminer I would say there is plenty of room for some over-clocking. Or in this case to move to the default 650M. (EDIT)
Chip temps are 87, 86, 91. Are these temps higher than an S7 with the above pcb temps? In other words is there more of variance on this miner than the older ones. Where we can burn out a chip before the pcb gets to 80C. That's still the safety shutdown temp. I believe.
Inquiring minds want to know.
PCB temps are useless...just a cheap way to guesstimate what the die temps would be. My guess would be that with more real-estate afforded by 14/16nm it became worth it it put temps sensors on the dies, and the fact that chips at these node levels are more sensitive to high temps. Anything over 90c continuous on die temps will shorten the life of the chip. I would be concerned if they are running over 80c. |
|
|
|
Spondoolies had simulation results at 0.15J/GH and BitFury was ordering engineering samples for a 0.06-0.15J/GH chip. Given that the BM1384 could run 0.25J/GH but the S5 was clocked at 0.45J/GH and the BM1385 could do 0.18J/GH but the S7 was clocked at about 0.26J/GH; if the S9 chip is clocked at 0.09J/GH we can assume it's probably got about 30% more efficiency hiding in the basement for a bottom clock around 0.06J/GH.
I'd bet that Bitmain and BitFury used all the tricks they'd already learned optimizing designs for 28nm on this 16nm chip. Is there probably room for more improvement? Seems likely. But I doubt we'll see another 30-50% drop in power use like we had with optimizations in previous generations.
I would say the same in re: to optimizations at design-level. My formula says by next June we would see efficiency as low as 0.02W/GH, but I think this time it might be wrong. I'd say 0.05-0.07 in the next 12 months, based mostly on increased chip density but that's just a guess. I slightly tend to disagree with you guys. Just guessing, in the next 12 we will see the next GEN for home miners somewhere around 0,04J/GH, and the big guys will probably have something in in the 0,02J/GH range by the same time, just as they did with the previous chips. Just remember that this industry is worth a few billions, so there is put very much effort in the R&D to gain a significant volume of advance in respect to your opponents in this race. I tend to predict, that BITMAIN is having a monopol at the moment speaking, and if AVALON and/or BITFURY (Not one running miner or container seen in the wild by now) donīt come up with something equal or more efficient, BITMAIN will stay in this monopol position just to play Monopoly in this industry... look at the pattern: s-1 2.00 watts s-3 0.74 watts s-5 0.51 watts S-7 0.25 watts S-9 0.10 watts S-11 at worst goes to 0.07 based on the s-5 to s-7 I don't see a 0.02 any time soon. I also do not think bitmaintech need worry about that 0.07 s-11 unless avalon makes a 0.09 machine or bit fury makes a 0.085 machine. The key for improvement is what does avalon bitfury or bw do . Since no one is near the .1 s-9 BW was actually first to .1 J/GH...I even have the chips in hand..of course they aren't selling anything publicly as of now. They are in a position to undercut bitmain by a large margin, not sure why they don't capitalize on it. At least 1k of the S9 price is pure profit, and they can get away with it since they are the only ones selling 14/16nm stuff. |
|
|
|
Mr. jstefanop, can you just throw some light on how much these chips are costing you and what is the MOQ, please? It would really help us all.
I would love too...but thats the part I'm under NDA about. Im in some talk with a few people to see how I can get this off the ground...but with the s9 announcement there is not much room for offering a more "competitive" miner with these chips, especially from a third party. |
|
|
|
sorry was away for the weekend...and yes I am under NDA so I can't say much other than what is publicly available. Chips are indeed BW's latest 1402 14nm. About 50 GH a chip @ .1 w/gh.
So don't tell us anything that is covered by the NDA, just tell us what your plans are for the chips? Rich My plans involve discussing the deal with BW so thats the issue there. And the "deal" is a bit at odds with my plan for producing small affordable miners for you guys which is the problem currently. I was going to stay away from stick miners since the high end of the stick miner range (for both compaq and my moonlander) was around 10W which cause a bit of headaches for USB powered devices/hubs...since most hubs can't provide that much clean power. The good thing about this chip is the high end is 5w, which would make it a prefect stick miner. My "ideal" plan would be around a 4-5 chip "pod" miner ~200GH @ 20 watts (ridiculously small, think a 2x2x2 inch box) that could connect up to 10 of them on a single pcie power connector, and would have a separate controller box. So essentially you would buy the pcie cable connector (or make one), the controller box, then add as many pods as you would like (up to 20 chained). So you would have miner "building blocks" and its up to the user how much they want to spend and how large to make the miner. Then lets say a new chips comes out, all you would have to do is swap out the board on the mini-pods for upgrades (same controller/powersetup and you would reuse the pod box/fan). |
|
|
|
|
sorry was away for the weekend...and yes I am under NDA so I can't say much other than what is publicly available. Chips are indeed BW's latest 1402 14nm. About 50 GH a chip @ .1 w/gh.
|
|
|
|
|
I have 10 GPUs running in our linux rigs. Will post an announcement soon as I will put them up for sale, but you can contact me if you want to know how its done.
|
|
|
|
Hi,
I have an USB volt and amp meter.
It tells me how much volts, amps and watts is draining the USB port at any moment.
Any formula to get ML ASIC core voltage from that data?
Thanks.
Not really, since how much power the ASIC is using is not constant and depends on frequency etc. You can just measure the core voltage directly with a simple multimeter. Check out the main posts in the beginning of this thread for instructions. |
|
|
|
Ill let you guys figure it out   |
|
|
|
I just ran a little test on both Nvidia (CUDA) and AMD (OpenCL) where I switched between current and next DAG every 5 blocks. No problems whatsoever. I don't have a multi-card rig, but I don't see how that should be any different, other than maybe a bit of clutter in the log output while changing DAGs.
Unfortunately DAGs are created so fast that the custom pcie bus we are running all these GPUs on is getting overloaded and the OpenCL calls hang. I guess I got lucky and it started the first time but quickly crashed. The only way to solve this issue is to implement the same serialization fix claymour did on his miner (i.e. generate DAGs one by one serially, and any OpenCL calls have to have a delay in them (especially when new work is pushed to all the GPUs). Unfortunately I don't think thats an easy fix with ethminer and how threaded it is. FYI this wont effect most users running less than 6 GPUs This on 1.1 i assume. There's not so much going over the bus, just about 50-100MB of DAG cache. When did it actually crash? During DAG generation or during mining? Because when mining, it;s not really that much different from 1.0.8, other than some code commented out. It must be something else then this, perhaps removing all this DAG crap opened up another weird ethminer bug. no i have debugged the issues extensively and confirmed its a bug with how fglrx makes openCL calls with multiple GPUs (and its made worse with bridges we use). Here is an example of where it usually crashes [OPENCL]:Printing program log
[OPENCL]:
[OPENCL]:Creating cache buffer
[OPENCL]:Creating DAG buffer
[OPENCL]:Loading kernels
[OPENCL]:Writing cache buffer
0%
67%
[OPENCL]:Creating buffer for header.
[OPENCL]:Creating mining buffer 0
[OPENCL]:Creating mining buffer 1
[OPENCL]:Generating DAG data
8%
42%
25%
50%
33%
67%
8%
75%
17%
0%
50%
33%
58%
42%
75%
17%
83%
25%
8%
92%
58%
42%
50%
67%
83%
25%
92%
33%
17%
67%
50%
58%
75%
33%
42%
25%
75%
58%
67%
83%
92%
42%
50%
33%
83%
ℹ 15:06:03|gpuminer0 set work to: #6a82dd23, target #0000000112e0be82
67%
92%
75%
50%
58%
ℹ 15:06:03|gpuminer1 set work to: #6a82dd23, target #0000000112e0be82
42%
75%
83%
92%
58%
67%
50%
ℹ 15:06:03|gpuminer2 set work to: #6a82dd23, target #0000000112e0be82
83%
ℹ 15:06:04|gpuminer3 set work to: #6a82dd23, target #0000000112e0be82
92%
67%
75%
58%
75%
83%
67%
92%
83%
75%
92%
83%
92%
As you can see there is way to much I/O going on between 9 GPUs in short amount of time, which causes the openCL call hangs. The only fix until AMD decides to revamp the AMDGPU drivers is to serialize the OpenCL calls and make sure they don't overlap between GPUs. |
|
|
|
I just ran a little test on both Nvidia (CUDA) and AMD (OpenCL) where I switched between current and next DAG every 5 blocks. No problems whatsoever. I don't have a multi-card rig, but I don't see how that should be any different, other than maybe a bit of clutter in the log output while changing DAGs.
Unfortunately DAGs are created so fast that the custom pcie bus we are running all these GPUs on is getting overloaded and the OpenCL calls hang. I guess I got lucky and it started the first time but quickly crashed. The only way to solve this issue is to implement the same serialization fix claymour did on his miner (i.e. generate DAGs one by one serially, and any OpenCL calls have to have a delay in them (especially when new work is pushed to all the GPUs). Unfortunately I don't think thats an easy fix with ethminer and how threaded it is. FYI this wont effect most users running less than 6 GPUs |
|
|
|
1.1 pre-release is out: https://github.com/Genoil/cpp-ethereum/tree/110/- no more DAG files (both CUDA/OpenCL) - CUDA Compute 2.0 support is back It looks like it's all working but I'm releasing early so you can help me test. Don't forget to remove your -E and -R params, that is all gone now. CPU util seems down, RAM usage down of course. CPU validation is still in there, using the light cache. no devfee, but do send me some ETH if you like it  awesome job! If this proves to be stable wont need claymour's miner to run my 9-10 GPU rigs  will definitely send some eth your way! ℹ 14:46:38|stratum Received new job #f89025a1
ℹ 14:46:38|gpuminer0 set work to: #f89025a1, target #0000000112e0be82
ℹ 14:46:38|gpuminer1 set work to: #f89025a1, target #0000000112e0be82
ℹ 14:46:38|gpuminer2 set work to: #f89025a1, target #0000000112e0be82
ℹ 14:46:38|gpuminer3 set work to: #f89025a1, target #0000000112e0be82
ℹ 14:46:38|gpuminer4 set work to: #f89025a1, target #0000000112e0be82
ℹ 14:46:38|gpuminer5 set work to: #f89025a1, target #0000000112e0be82
ℹ 14:46:38|gpuminer6 set work to: #f89025a1, target #0000000112e0be82
ℹ 14:46:38|gpuminer7 set work to: #f89025a1, target #0000000112e0be82
ℹ 14:46:38|gpuminer8 set work to: #f89025a1, target #0000000112e0be82
m 14:46:39|ethminer Mining on PoWhash #f89025a1 : 221.06MH/s [A25+0:R0+0:F0]
m 14:46:41|ethminer Mining on PoWhash #f89025a1 : 189.79MH/s [A25+0:R0+0:F0]
m 14:46:43|ethminer Mining on PoWhash #f89025a1 : 189.79MH/s [A25+0:R0+0:F0]
m 14:46:45|ethminer Mining on PoWhash #f89025a1 : 189.79MH/s [A25+0:R0+0:F0] |
|
|
|
So probability is not the only thing that matters.
Sorry, but your wrong. Probability is all that matters, and regardless what you think or see in the short term does not matter, so your point is not valid. Regardless of whether your solo or pool mining, the def fee wont change hard math. Over time, If you solo mine 100 blocks, 1 block will be missed due to the dev fee on average. If your on the pool your hashrate will be shown 1% less on average. |
|
|
|
Also someone that know curl explain why telnet localhost 3333 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. {"id":0,"jsonrpc":"2.0","method":"miner_getstat1"} works to get a response, but curl -i -X POST --data '{"id":0,"jsonrpc":"2.0","method":"miner_getstat1"}' http://localhost:3333does not work? Im not that great with curl so not sure if I formatted that request right. My guess is that CDM doesn't like the HTTP headers that curl sends. I'd recommend using nc ( https://en.wikipedia.org/wiki/Netcat) instead. Nice, this works: echo '{"id":0,"jsonrpc":"2.0","method":"miner_getstat1"}' | nc localhost 3333 this dumps the raw json output so it can easily be used in a bash script in linux to do fun things |
|
|
|
Claymore can you format your json output with key value pairs? Current output is very hard to parse and get individual values. {"id": 0, "result": ["4.3", "8", "93479;11;0", "18352;18914;18191;18809;19210", "0;0;0", "0;0;0;0;0", "67;53;66;50;66;48;56;61;60;56", "us1.ethpool.org:3333"], "error": null} something like result.eth_mh would be great to get just the hashrate value for example. Also someone that know curl explain why telnet localhost 3333 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. {"id":0,"jsonrpc":"2.0","method":"miner_getstat1"} works to get a response, but curl -i -X POST --data '{"id":0,"jsonrpc":"2.0","method":"miner_getstat1"}' http://localhost:3333does not work? Im not that great with curl so not sure if I formatted that request right. |
|
|
|
|
Show Posts
