|
Which link do we need to write in the form? I put the link to this topic, is that OK? If not should I submit again with a different link?
|
|
|
|
I'm a bit confused by this ICO too. There doesn't seem to be any information after the ICO ended. They wrote on Slack they are going to post an update on Medium soon, but they didn't post anything. https://etherscan.io/token/0x65B9D9B96bccE0b89d807413E4703D2C7451593a only shows 66 "events", surely there are more token holders than that? And filtering by my address doesn't show anything, even though my transaction went through. No updates on twitter or anywhere really, really quiet. Supposedly the guy went to sleep. Like weird. On a side note I'm also a bit surprised that someone invested $2.5 mio (32,425 ETH) lol. |
|
|
|
|
dark8011: lookup-gap is only used with Scrypt. I think thread-concurrency also is only used with Scrypt, but in any case it is not used to calculate buffer size for non-Scrypt. I think your cards unfortunately just do not have enough VRAM for these algorithms. The only thing you can try is set gpu-threads to 1 if you don't already have that. Other than that I don't think there's much you can do.
For developers: Perhaps X11/X13... buffer size can be lowered? I remember that some miners had a formula to calculate it, while we use hardcoded values in sgminer 5.0.
|
|
|
|
I solved it. For some reason I had to add this switch. -d switch doesn't work but adding this does. --gpu-platform 1 setx GPU_USE_SYNC_OBJECTS 1
setx GPU_MAX_ALLOC_PERCENT 100
sgminer --pool-algorithm bitblock --no-submit-stale --gpu-platform 1 -o stratum+tcp://east1.us.stratum.dedicatedpool.com:6006 -u romes.15 -p x -g 2 -w 128 --gpu-engine 1020 --gpu-memclock 1450 --shaders 2048 --thread-concurrency 20481 -I 19 --worksize 256 --lookup-gap 0 --auto-fan --temp-target 77 --temp-overheat 83 --temp-cutoff 85
We're rockin' now. EDIT; The issue is with the AMD drivers which need that switch to work for some reason. I think -d should work too but you need to also set --remove-disabled |
|
|
|
Again in the Night the Rig close down SGMiner 23:21:05] NH x15 multi extranonce change requested
[23:21:05] NH x15 multi difficulty changed to 0.100
[23:21:08] Accepted Coin 182 Diff 0.113/0.100 GPU 1 at NH x15 multi
[23:21:12] Accepted Coin 182 Diff 0.892/0.100 GPU 2 at NH x15 multi
[23:21:30] Accepted Coin 182 Diff 0.330/0.100 GPU 0 at NH x15 multi
[23:22:14] Accepted Coin 189 Diff 0.112/0.100 GPU 5 at NH x15 multi
[23:22:26] Accepted Coin 189 Diff 0.171/0.100 GPU 5 at NH x15 multi
[23:22:55] Accepted Coin 189 Diff 0.306/0.100 GPU 0 at NH x15 multi
[23:23:16] Accepted Coin 189 Diff 1.319/0.100 GPU 1 at NH x15 multi
[23:23:26] Accepted Coin 189 Diff 9.627/0.100 GPU 0 at NH x15 multi
[23:23:41] NH x11 multi alive, testing stability
[23:23:41] Accepted Coin 176 Diff 0.394/0.100 GPU 5 at NH x15 multi
[23:23:49] NH x11 multi stable for 30 seconds
[23:23:49] Switching to NH x11 multi
[23:23:54] Stratum connection to NH x11 multi interrupted
[23:23:54] NH x11 multi not responding!
[23:23:54] Switching to NH x15 multi
[23:24:50] thread was not cancelled in 60 seconds after restart_mining_threads
[23:24:50]
Summary of runtime statistics: Dont know why it closed. SGminer didnt try to get on the Backup Pool  This has been fixed about a day or two ago. |
|
|
|
If any of you have been experiencing a problem with these new sgminers running under 14.6beta let me give you an example of what happened to me: I have 4 rigs of 7970s and 280xs. 3 rigs were fine running x11-x15 under the new AMD beta drivers. The other one would run for anywhere from 20 minutes to 2 hours and die with a BSOD no matter what engine speed, voltage, or memory speed I used. After days of troubleshooting it finally came down to doing a complete uninstall of all AMD software, reinstall 14.6 and remove GPU devices and drivers and reinstalling the device drivers for the GPUs. That finally fixed it. Even though I treated all 4 rigs the same, sometimes something glitches out. I hope this saves someone somewhere some time.
I am getting freezes with bin-files compiled with the 14.6 beta drivers. I guess now we know why they are beta...  |
|
|
|
|
I tried on a clean install of 32-bit ubuntu with latest (may23) 14.6 beta drivers, but I do not get any speed increase at all. I tried on x11mod both with djm34's version from github and latest sgminer v5.0.
A friend sent me pre-built .bin files from Windows and that works, I get 3.8 MH/s instead of 2.9 MH/s on my ASUS R9 280X. But if I build them myself on my Ubuntu, I get no speed increase (just normal 2.9 MH/s).
Any idea what I'm doing wrong? Does it have to be 64-bit?
|
|
|
|
|
MrBobC: why did you manually download .gitmodules? You don't need to do that...
|
|
|
|
|
badman74: that doesn't sound like a "hell of a time" if all you have to do is open git shell... In any case you also probably have an old version of MinGW.
breel: no, it's not the same issue, you need to read the new readme instructions on how to build now. it can't be the same issues unless you found a way to run MinGW on linux.
|
|
|
|
You guys really mucked up the implementation of the extranonce subscription extension. Of all the ways you could have done it, you chose the only option with the potential to create enabled mining clients that are incompatible with other pools by default. You had full control of your stratum server implementation, and full access to nearly all client miner implementations, but little or no access to oftentimes proprietary stratum implementations at other pools, so the fact that you decided to initiate extranonce subscription messages from the mining client side, demonstrates either your incompetence or ignorance as to how to extend an already well established protocol without introducing negative consequences elsewhere, or callous disregard for the effects upon miners and the other pool operators who are affected by your protocol extension.
Given the circumstances, you should be initiating the extranonce subscription from the stratum server side, at which point an enabled mining client can respond in the appropriate fashion, and an earlier version ignore the message as you can easily verify that most mining clients do. But as it stands now, you have created a situation where extranonce subscription enabled mining clients are sending unexpected messages to stratum servers at other pools potentially causing unknown consequences there. Or was sabotaging your competitors part of the original plan?
I have to agree with this (except the last sentance, which is kinda stupid).. I wonder if it is already too late to change this (also, this is just a feature nicehash added, or is it some standard?). I did not go into what this is actually useful for, if it's only for these rental/multipools, then we could simply turn this option off by default (opt-in instead of opt-out). Please do open github issues. I think most of the developers (including me), are not on forums that much, compared to github where we will see the issue very fast and can respond much faster. I guarantee you, things will be fixed faster if you open an issue for it, and especially do that if multiple people are having the same problem. For anyone who doesn't know, issues can be reported here: https://github.com/sgminer-dev/sgminer/issues (please mention if you are using the v5_0 version) |
|
|
|
|
Adz does that setting always crash on Windows? Or just in some special circumstances?
|
|
|
|
Thanks for this... Its great
I know this is in Alpha / Beta stage but the performance of Marucoin-Mod kernel is still slower than X13mod.
Maybe it is just because of SPH_HAMSI_EXPAND_BIG. There is a different default setting in different miners. I added a .conf setting for this in sgminer (not pool-specific) yesterday, what you need to add in your conf file is: "hamsi-expand-big" : "1", Default value is 4, but 1 works better for many cards (for example Sapphire R9 280X Dual-X). I don't think there is a Windows build out yet for this, but you can change it in the marucoin-mod.cl file ("#define SPH_HAMSI_EXPAND_BIG 4") - in this case you will need to delete the old .bin files. In newer versions of v5 you will see it from the filename, it will be something like "marucoin-modTahitigw256l4big1.bin" (big1 means the setting is 1). |
|
|
|
Hey guys. If you are using the v5 builds of sgminer and have problems, please let us know here: https://github.com/sgminer-dev/sgminer/issues/newFirst for those who cannot or don't want to help with the problems, you can run with a single pool and there should be no problems. The issues are usually happening when switching algorithms. We are aware of a few issues and are working to fix them (there has been significant progress already in the past few days). It helps if you run sgminer with "-v" option and show us a screenshot or copy-paste of text in sgminer when it crashes. For Linux users you can also use this configure "CFLAGS="-g -O1 -Wall -march=native" ./configure" and then make, which will enable better traces on crash. Also you can run with "-T -v" or even "-T -D" which will give much more information and thus make it easier to find and fix the problems. |
|
|
|
Error: clSetKernelArg of all params failed.
Can anyone help with this?
Are you using legacy AMD drivers (old graphic cards...)? |
|
|
|
|
Am I the only one that cannot mine on the X11/X13 ports anymore since today?
|
|
|
|
which coins use this algorithm? i see they call it "marucoin" algorithm in sph-sgminer, but is marucoin the first coin to use it or only the most famous coin?
Yep it's marucoin. it's the same as X11 it just has 2 additional sph algos (hamsi and fugue). By the way, once you earn enough from the donations (which I have nothing against), consider contributing some of your improvements to sgminer ( https://github.com/sgminer-dev/sgminer/tree/v5_0). Since it would not be possible to do this without sgminer (or cgminer in the first place), it is nice to give something back from time to time. Cheers! |
|
|
|
Hey guys, Since we merged all (or most) functionality from sph-sgminer into official sgminer ( https://github.com/sgminer-dev/sgminer/tree/v5_0), and also added both X11-mod and X13-mod kernels, it would be cool if we can work together there, so we can keep all the improvements in one place. I am happy to merge any improvements from this version into there. Also, I would be really interested to hear if you guys still get the SICK problem on our v5_0 branch (we did not increase the sick time)? Since there are many new bugfixes there and it could be that the issue is not directly caused by X11-mod. Personally I haven't had any SICK yet (I don't over-do it on the GPU settings though). |
|
|
|
|
Just added X13-mod (named "marucoin-mod" for now).
dhsc19: it could just be related to TeamViewer. it would be easy enough to find out since you say you can always reproduce it - simply reboot, do not run sgminer at all, use TeamViewer and do whatever causes the problem, and then start sgminer. if you still get a lower hashrate then sgminer can't do anything about it.
Old sgminers and cgminer 3.7.2 did indeed have leaks on the GPU, but I fixed them a few months ago when I did the "hot-switching" between Scrypt and Scrypt-N. So any semi-recent build of sgminer should not have leaks on the GPU, it is probably something else.
|
|
|
|
|
Why would you have decreased performance if switching algos? It's simply not the case and there is certainly no technical reason for that to happen.
The implementation itself has nothing to do with "somebody's" profit-switching algorithm. It just allows you to switch to a pool with a different algo without restarting the miner. Simply copying x13-mod of course will not work since it has 13 kernels and not 11.
|
|
|
|
|
Show Posts
