I presume you mean you made build.sh work out of the box?
Exactly that, works for both non-AES CPU's and AES CPU's. GCC provides __AES__ macro if -march=native supports it. Did not test on MinGW, though, only on Debian 8.4. It'l be in the next release, hopefully in a day or so. It'l be handy for users not to have to know the architecture. I really appreciate the work you did. I've been stumbling my way around the environment just trying to make things work. It's been challenging to apply my experience to a completey foreign environment. Feel free to comment on overall architecture. Being a foreigner in the land of GNU C I'm not aware of the local customs and conventions. I've done a first pass through your changes and I want to undertsand more so forgive my stupid questions. I'm curious about some of the changes because things worked. Amd when things work I don't want to make changes unless it makes them work better. In general terms I ask why is it better, will it hash faster? Simpler compilation procedure is an obvious one but other changes escape me. I didn't know about the compiler support for __AES__. Good job. I never heard of LTO before, what will it give me? Is that how boost now works with your changes? Boost didn't work fo me until I added the linking options to teh makefile. Are your changes leading edge? Will they work on older loads? Can you explain the __attribute__ used stuff a bit more, that's a new concept for me. Again, it worked before so how is this better? Thanks again. I'll get the __AES__ implemented quickly, the other stuff can wait until I have a better understanding. Update: I've been spending a lot of time trying to implement another algo with little success. I get a nice multi page dump for a buffer overflow, not just the typical segfault, but I digress. I put that aside for another day so I can your user visible changes released. I implemented __AES__ with a slight change, I allow configure to override automatic aes compile, not very useful for users but it helps testing SSE2 on my i7. There are still problems with build.sh. First groestl sse2 complained about ASM constraints so I removed USE_ASM then a bunch of AES code failed to compile, then I stripped it down to "-O3 -march=native" and it works. It's nice to get rid of the alloca warnings. I didn't see a point in changing the way boost was linked, it doesn't make compiling any easier and it ain't broke. I'll look into the other issues over the longer term. Thanks again. |
|
|
|
Does someone have a link to the hardware comparison spreadsheet? I can't find it in my history/bookmark somehow.
I'm debating getting a i7 over a i5 if i can recoup the cost.
I can give you my stats for cpuminer-opt, similar to hodlminer-wolf. i7-6700K @ 4 GHz, 8 threads, 260 H/s. i5-2400 @ 3.1 GHz, 4 threads, 180 H/s. |
|
|
|
I presume you mean you made build.sh work out of the box?
Exactly that, works for both non-AES CPU's and AES CPU's. GCC provides __AES__ macro if -march=native supports it. Did not test on MinGW, though, only on Debian 8.4. It'l be in the next release, hopefully in a day or so. It'l be handy for users not to have to know the architecture. |
|
|
|
I'm surprised they released tesla first, I would expect them to beta test with the consumer line. Maybe they are confident enough in the quality. |
|
|
|
I've added some changes to make it work out of the box on non-AES linux builds: Diff can be found here -- https://github.com/hmage/cpuminer-opt/compare/upstream...masterRaw diff -- https://github.com/hmage/cpuminer-opt/compare/upstream...master.diff- On non-MSVC, if -march=native supports AES, then NO_AES_NI is not defined, otherwise it's defined.
- An LTO build did not work out of the box, some variables and functions needed to be marked as used, so they won't be removed by linker.
- Add -march=native into build.sh
- Fix a compiler warning, since builtin_alloca() is already defined as alloca() on GCC.
- Curiously, on my benchmarks, -O2 is faster than -Ofast on gcc 4.9.2.
I presume you mean you made build.sh work out of the box? That's great. I'll dig into it. If you left it -Ofast I'll change it to -O3, that's what I always use anyway. |
|
|
|
COOL PIC, BRO! -- But did it mine AltCoin? BTW, A Dodge SuperBee with a six-pac carburetor (I think it was a dealer option) could go through a tank of 25-cent-a-gallon gas driving from one small town to the next. I was able to look at pictures in the weekly student science magazine ads. Gas was practically frre, I guess. My first car cost $35. --scryptr OOOH Hemi! That pic is from the Lost TV show, I freaked when I saw it on TV. It's rare enough I thought it might be mine. Most are fakes with a cut front bumper or full bumper, no nose extension, cat's eye front signals and large 3 piece rear spoiler. Real ones have a real two piece front bumper, nose extension, round front signals and a small one piece rear spoiler. The web page hosting the pic also has pics of a fake used in the car chase scenes on the show. I have to say I bought my dream car youg. Now I drive a Nissan Micra. Back to mining, profit is tumbling, but lyra2 is still hot for CPU miners, though perhaps not to Pallas' efficiency standards.  |
|
|
|
its like saying that feul efficiency IS the factor in high octane drag races ... its not - its the time it takes to get from one point to another - and the fastest wins ... period ... they dont care how much feul or noise or rubber is used or destroyed in the process ...
that's because they have a wide margin. everybody must take expenses into account. if you made more money by lowering your TDP, wouldn't you do it? do the math and you'll see. agreed ... expense IS a factor IF the result takes it into account ... if all you want is more hashrate at the expense of power - then great ... i will concede though that in a larger farm environment - this view would be the deciding factor for the farm and its design and setup - as the smallest decrease in power would save a huge amount ... but in this case pallas - i honestly dont think the power reduction is that great that it would be anything to worry about - especially if thehasrate is increased by a larger margin ... not a very small one ... as for money - im not fussed on that end ... it comes good in the end when it comes to money ... im more concerned with the coins themselves ... more hash - more coin ... hence the reason why i have always said - that my view of 'profitability' is VERY different form what most people accept it to be ... #crysx By definition power is a variable in efficiency. But as crysx said many people don't care. The bottom line is to state whether power efficiency or raw hashrate is being specified. Otherwise we could end up in a false argument, and we already have enough real arguments. |
|
|
|
Sorry guys a cronjob on Suprnova got Stuck over the night, nothing was lost, all was credited now.
So now a lot of problems with the connection: [2016-04-12 16:19:55] Stratum connection interrupted
[2016-04-12 16:19:55] Stratum requested work restart
[2016-04-12 16:19:55] stratum_recv_line failed
[2016-04-12 16:19:55] Stratum connection interrupted
[2016-04-12 16:19:56] Stratum requested work restart
[2016-04-12 16:19:57] accepted: 36472/36697 (99.39%), 122.52 hash/s (booooo)
[2016-04-12 16:19:59] accepted: 36472/36698 (99.38%), 117.79 hash/s (booooo)
[2016-04-12 16:19:59] accepted: 36472/36699 (99.38%), 119.40 hash/s (booooo)
[2016-04-12 16:19:59] stratum_recv_line failed
[2016-04-12 16:19:59] Stratum connection interrupted
[2016-04-12 16:20:00] Stratum requested work restart
[2016-04-12 16:20:04] accepted: 36473/36700 (99.38%), 115.01 hash/s (yay!!!)
[2016-04-12 16:20:04] accepted: 36474/36701 (99.38%), 112.72 hash/s (yay!!!)
[2016-04-12 16:20:07] accepted: 36475/36702 (99.38%), 112.67 hash/s (yay!!!)
[2016-04-12 16:20:08] stratum_recv_line failed
[2016-04-12 16:20:08] Stratum connection interrupted
[2016-04-12 16:20:08] stratum_recv_line failed
[2016-04-12 16:20:08] ...retry after 30 seconds
[2016-04-12 16:20:10] submit_upstream_work stratum_send_line failed
[2016-04-12 16:20:10] ...retry after 30 seconds
[2016-04-12 16:20:38] Stratum requested work restart
[2016-04-12 16:20:40] accepted: 36475/36703 (99.38%), 130.99 hash/s (booooo)
[2016-04-12 16:20:41] accepted: 36475/36704 (99.38%), 130.99 hash/s (booooo) This is a massive problem or what should i do? Same here. I will switch to another pool if it continues, a lot of hashrate lost  What miner are you using? Edit: nevermind, it wasn't a miner problem, working now. |
|
|
|
cpuminer-opt v3.1.13 just released. Added support for a few dusty algos:
sha256d, scrypt, scryptjane and yescrypt.
If anyone knows of anywhere to pool test any of the remaining algos please let me know.
I'll even test you your address.
You can test scryptjane at YACoin pool: Miner config: -o stratum+tcp://yacoin.club:3433 -O alenevaa.CPU1:1 You can use 2 ports: - 3433 difficulty 1 - 3434 difficulty 0.25 If you miner doesn't support difficulty less than 1 - use port 3433 Thanks but scryptjane has been pool tested. When I said remaining algos I was referring to the ones that have not yet been tested in a live pool. Specifically they are X17, blakecoin, fresh, cryptolight, and bastion. I have not been able to find any pools offering to mine coins using these algos. Sorry for the confusion. |
|
|
|
I have been having this error with my gtx 660se cuda error in func'qubit_luffa512_cpu_init' input at line 446, invalid device symbol ccminer does work with my gtx 770 very well, but i have just not been able to get this to work this is the batch file for my 660 ccminer-30-35-50-52.exe -t 2 -d 1 --algo=qubit -o stratum+tcp://stratum.dgb.theblocksfactory.com:9000 -u greedytacothief.1 -p x -f 10
I am having the same problem. Has anyone found a solution to this? That was two years ago, so I doubt it's the same problem. Maybe it's the same error message. It means the software isn't compatible with your GPU. Check here for your GPU and compare with the SM versions supported in the version of ccminer you are using. https://developer.nvidia.com/cuda-gpus#collapse4 |
|
|
|
I have a question about the bonus interest rate which decreases with every new block.
How does this rate get applied to existing coins. Is their rate reduced or does the lower
rate only apply to new deposits. This question applies to regular deposits as well as TDs.
TIA
When you make a TD you are locked in at that blocks rate.. Same goes for standard interest.. The Standard interest rate is set at the rate that output was last moved.. Until 30 days and then you most move that output to start interest accruing again.. Got it thanks. |
|
|
|
It would help if you accepted the reality that the big gains in Maxwell are done.
You are wrong. The big gains in Maxwell are only in private farms. Ok, the're done in private farms then, but the're still done. If they were yours I expect you would be releasing them in your fee based miner so I assume they are other devs' private miners. If you can't get access to them you can't sell them so your Maxwell business is also done. Like I said, focus on pascal & cuda 8, be the first to market with a pascal optimized miner, make lots of profit. Worth way more than 0.1BTC. I will not do the opensource pascal mod. You can do it. I said profit, not open source. If you have the product when people want it you make big profit. You can decide how you want to market it and if and when you open the source. At the moment you are trying to sell a product that has no market appeal. Develop a better product and it will sell itself. That's what I'd do, if I could. I have cpuminer-opt, but it isn't a marketable product so there is no point in me trying to sell it. But the work is fun so I do it. BTW I got my first donation a couple of days ago but I'm not sure it was for my cpuminer work. |
|
|
|
It would help if you accepted the reality that the big gains in Maxwell are done.
You are wrong. The big gains in Maxwell are only in private farms. Ok, the're done in private farms then, but the're still done. If they were yours I expect you would be releasing them in your fee based miner so I assume they are other devs' private miners. If you can't get access to them you can't sell them so your Maxwell business is also done. Like I said, focus on pascal & cuda 8, be the first to market with a pascal optimized miner, make lots of profit. |
|
|
|
Ofcource ppl will donate for a 6% faster x11 kernal if it is profitable. With etherum and decred taking a dive, you need to move the rigs to the profit. Everyone is welcome to mine Dash. If you don't use my modded kernals you are eighter stupid or have to few cards..
People who already mine x11 will, but I don't think it will motivate people to switch to x11. That decision is probably made based only on x11's proofitability regardless of the miner. Another porblem for devs was cuda 7.5. It's release should have been an opportunity for further optimisations but it was a flop. Most of the work on cuda 7.5 was to recover lost hash. There's no profit in that. |
|
|
|
They expect value. When a new release comes out they expect significant performance increases
in preformance.
And when Pallas opensource a 10% improvement, they expect me to do another +10% in my mod right? And when Alexis spend another 50hours to squeeze out a few percent, they expect that the sp-mod will be faster right? The competition is also working. You never see wolf0 release updates to his modded kernals. I do. Sometimes with bugfixes, sometimes with improved hashrate.. My Vcash and cryptonight kernals need some more work. Let's see what I can do, the limit is not yet reached. Wolf0 just AES_NI optimized a CPU miner for HOdl for a bounty and released the source. Now anyone can take that source and improve it. He did the same with his cryptonight AES_NI optimisations. I've added both to cpumier-opt. He got his bounty so I'm not stepping on his toes. Whether he chooses to optimise further is entirely up to him but he probably realizes the profit/work ratio has gone way down. That is part of the problem with SP_MOD. Early on the was excitement for Maxwell and people were anxious to donate for more hash and the improvements came big and fast. But that has reached the pont of dimishing returns, donations dropped off, improvement were fewer and smaller and interest waned. Your profit dropped and you tried to get them back. The conversion from free to fee based didn't go smoothly. For one the big increases for existing algos were long gone, each release was only 1 or 2% and sometimes caused regresssions on some cards. People don't want to pay for that. You need to produce something people want to pay for, not something you need to beg them to pay for. Your reaction to the inevitable has been negative and has had the effect of turning off many customers making the situation worse. It would help if you accepted the reality that the big gains in Maxwell are done. You should focus on new algos and prepare for Pascal and Cuda 8. If you get a head start it could give you a market advantage which means more profit for you. Imagine being the first to advertise a Pascal optimized miner. I'm sure poeple would be willing to pay for that. Shit I just tipped off the competition. Oh well better for customers. |
|
|
|
|
I have a question about the bonus interest rate which decreases with every new block.
How does this rate get applied to existing coins. Is their rate reduced or does the lower
rate only apply to new deposits. This question applies to regular deposits as well as TDs.
TIA
|
|
|
|
I'm looking to build a small 3 GPU rig using the following hardware?
1 x Sempron 2650 or 3850
1 x 4GB PC-1333Mhz
1 x Gigabyte GA-AM1M-S2H
1 x 32-60 SSD
3 x EVGA GTX 950 02G-P4-2957-RX
3 x PCIe x1 to x16 risers
1 x 100-B1-0600-KR
This is a side project for my dad so long ROI 6 - 9 months isn't an issue.
anyone know if you can run this many GPU's on an AM1 board and have it see all of them?
Shouldn't be a problem but I'd recommend more RAM. I usually budget the same amount of extra RAM as the total of all the GPUs. So if those are 4 GB GPUs you should get 16 GB RAM. Regarding the thread title I couldn't resist... http://www.supermicro.com/products/motherboard/Xeon/C600/X10DRX.cfmwhy the overkill with ram? i'm usually fine with 8 giga of ram i can't see the reason to go nutt with it, they also start to be expensive at 16 gb It mostly depends on the algo you want to mine. You can probably get by with increasing the virtual memory but for the incremental cost of 4 GB RAM per GPU I think it's worh it. And it's not a step function, shit won't happen when you cross the line. But if I'm thinking of adding a 3rd GPU to a rig with 8GB RAM I'd also be thinking about more RAM. It's just a guildeline I follow, not trying to force anyone to agree. I have a couple more: The CPU should have as many cores as there are GPUs so each GPU has a dedicated CPU core serving it. A dual core Celeron would be sufficient with 2 GPUs. And I always use powered risers on PCIE-x1 slots unless it's a board specifically designed for mining with extra power inputs on the bus. I find these guidelines simple to undertsand for non-techies. Geeks, of course, would do their own engineering and wouldn't be asking the question in the first place. YMMV. |
|
|
|
I like it. I've thought about something similar and played around with running two miner instances in parallel, each one mining a different algo without much success. Depending on the algos I choose I can get a bit over 100% but not much. Each algo hashes at a significantly reduced rate but the sum is greater than either ine alone. Complementary algos work best, one CPU bound, the other memory bound. I have no idea how Claymore managed to hash a second algo without reducing the performance of the first. There seems to be a priority order with ethereum being higher. |
|
|
|
|
Show Posts
