 Show Posts
|
|
Pages: [1]
|
We are getting close to the 0.3.8 release, watchdog is ready, it catches init errors and stuck gpus and runs a user-defined bat/.sh Trying out the new release now! I don't see any information in the ReadMe as to how to use the watchdog feature. Can we specify a user-defined script by passing a parameter? |
|
|
|
|
My findings are similar to what some others have reported.
I tested TUBE on the latest version 0.33b5 on two different identical rigs, each with 6 x 8GB RX 580, with the only difference being one is on Adrenalin 18.6.1 drivers and the other is 18.5.1.
With each rig, only one GPU out of 6 reaches maximum hashrate (approx 1220 h/s), and the other 5 GPUs level out around 990 - 995 h/s. I have tried various multihash settings as well as other greeks but this issue remains regardless.
If I use the --no-warmup switch, 3 (sometimes 4) of 6 GPUs (for both rigs) will reach maximum hashrate (up to 1180 h/s) and the others will remain in the upper 900s h/s.
|
|
|
|
Hi JCE, When using your GPU miner, can you advise as to whether or not you are currently verifying the GPU result by cross checking with CPU that is is valid before submitting to the pool? Some other miners perform this check and will avoid submitting if there is a discrepancy, merely noting it as a 'Compute Error'. If you aren't, would you consider adding the functionality, even if only via a config or switch? If it slows down performance, it can still be beneficial when testing more aggressive clocks and multi_hash/intensity settings to have this check before submitting when trying to find the performance vs stability sweet spot and not wanting to get banned by the pool for invalid shares. I received this error in JCE while testing the reasonable limit of each GPU so it got me wondering about this. My static difficulty is definitely appropriate as it's not even 25x my hashrate. I am sure that lowering my clocks will reduce or eliminate this issue, but I thought I'd include this result for informational purposes. 21:40:57 | Rejected by the pool.
21:40:57 | Message from the pool: Low difficulty share
21:41:45 | GPU 7 Thread 14 Lane 1526 finds a Share, value 400015
21:41:45 | Rejected by the pool.
21:41:45 | Connection failed: The pool kicked you out as Unauthenticated, its Difficulty 400015 is probably too high for your computing power. If the pool allows fixed Difficulty, fix it to a lower value.
21:41:45 | Connection interrupted, waiting 5s then retry, attempt #1
21:41:45 | Connection failed: Socket receive error: A blocking operation was interrupted by a call to WSACancelBlockingCall.
21:41:45 | Connection interrupted, waiting 5s then retry, attempt #2
Thank you for considering this. As things stand now only having the ability to specify one pool, it can result in complete downtime if invalid shares are submitted that are outside the proper difficulty level and the pool issues a ban. |
|
|
|
does the gpu miner compile fresh kernel every run? It seems to be lot slower with multi GPU rigs.
EDIT: Just read the posts above.
Yes, every run is freshly compiled and tied to that individual card for security purposes. JCE is aware that those of us with bigger multi-card rigs would love to see the total time spent at startup reduced and has commented that he will continue to look for ways to improve upon this startup time without compromising security. EDIT: Just saw your EDIT after I posted!  |
|
|
|
hello, When i say the fees are included, that means the displayed hashrate is the same no matter if you're in a devfee session or not. This is the raw physical hashrate. If you punch h, you lock the mining thread to force it to update the hashrate counter and display it on screen, so if you punch again and again, it will lower the hashrate, that's normal. This is the same for the CPU version. Better use the JSON http output which is updated in the network thread, and does not cause such a problem. From your browser, you can press F5 as much as you want. But not H from the console. Effective hashrate should converge mathematicaly to lower than the average physical hashrate. Normaly by ~2% on a very long term. If it's higher, so you had a good luck biasis. You can check that number two ways : 1. Look at your pool, you should get a similar hashrate (the computation range of the pool may be different from JCE, but on the long term, they should converge). 2. Get your total hashes and divide it by the uptime. You should get the same value. The hashes themselve can be checked against your pool history, or JCE log, and the uptime by... your wall clock  A difference can be explained by some instant peaks from your cards that make you mine faster but may not be reported by the blue instant hashrate, if you mine so fast that the 512 hashes are obsoleted fast. I admit that 512 was good for CPU, which can mine at 150h/s per core at best, but that's just half a second for a Vega. Average rate over half a second is too low. This is the problem. Good remark, i'll increase the time period for average of fast cards like Vega  Version 0.30c onlineNetcode fixes
Bittube v4 Thanks for the thorough reply. I will indeed use the JSON to monitor moving forward. I fully understand the way luck is involved and that a hashrate shown poolside based on shares found will need considerable time to converge with physical hashrate. I now see that you are simply multiplying shares found for the non-dev pool x difficulty value and that luck is included in this Effective Hashrate number. I suspect that you are right about the possible spikes in physical h/s on Vegas causing confusion since the current sample size for physical averages is actually closer to .25 seconds! |
|
|
|
|
Hi JCE, I just started testing your miner (I opted for the a version due to noted regressions in b) and after about 15 hours of testing on my 8 x Vega 56 rig, things are looking very good. I can post more details once it has proven stable over time, but upon initial observation, I am quite pleased.
I understand that the h/s displayed in blue is the true average physical hashes per second over the past 512 hashes. In Advanced Topics, you state that the displayed number has no tweak, and includes the fees. If I understand correctly, could this be a reason why when I refresh quickly using 'h', I see values drop considerably on one thread followed by the other, followed by yet another? The only reason I ask this, is that a highly variable h/s on any given thread can sometimes be an early warning sign that the card/thread is not stable due to overly-aggressive configuration settings or clocks/voltages). Based on my observations, the numbers come right back up into a normal and stable range, so it seems that this is by design and that you are mining to your dev pool on a thread-by-thread basis, and that this is not necessarily a sign of instability. I just want to be sure before I spend more time tweaking performance.
Also, Effective Net Hashrate as calculated by total hashes / total seconds spent mining is often much higher than my average physical hashrate, even over an extended period of time. Since this number is supposed to take into account stale/invalid shares as well as fees, this is surprising. I would expect the number to be lower. Do you have any thoughts on this matter?
Keep up the good work!
|
|
|
|
Hi, any intensity tips for StelliteV4? Rx580 rig here, 13000 total in CN heavy, 11900 in Stellite. Is this expected?
The optimal Stellite algo configuration and h/s is very similar if not identical to the v7 algo due to the way it is coded. |
|
|
|
V1.6.0Do you have any success with per.mem on ? Using it should allow to go for a bigger intensity setting, on my test card (580 8g) algo normalv7, the best setting was i:54 / w:8 / t:2 i got ~926hs , now i can go to i:60 without problems, and have ~933-936hs edit: i:63 ~940hs  I am running on an 8xVega 56 rig. So far I have only tested v7 algo. With unchanged i:/w:/t: settings here are what my initial tests show (only ran for 15 mins each): Unchanged i:/w:/t: settings (i:112/w:8/t:2), average h/s per card:1.5.8 - 2016 h/s 1.6.0 - 2012 h/s (pmem: false) 1.6.0 - 2020 h/s (pmem: true) I can provide more test results later with different intensities and algos if helpful. |
|
|
|
V1.6.0
- Added support for Haven new algo after fork (block 89200)
- Added support for Masari new algo (fast) after fork (block 204000)
- Job timeout default is now 20 minutes
- More logging on miner startup
- Added option 'persistent_memory' in gpu_conf
Hey Dok, thanks for the update. I just started playing with persistent_memory. I know that your notes in CAPS after each option shown in the ReadMe are meant to be purely informational, but you may want to change the TRUE OR FALSE to lower case or use it in an example config to limit potential confusion, since the parser will throw an error if true/false is in CAPS when loading. Keep up the great work! |
|
|
|
@Doktor:
Stellite will Hardfork next Week. Can u please implement th new Code so that it is also Mine able?
THX
Hayzam from XTL said that they will be reaching out. I too hope that @Doktor83 is willing and able to implement their upcoming custom algo. Please keep up the good work, Dok! wtf they fork again? where can i get some info about this? You can check here: https://twitter.com/Stellite_QA/status/1001901290065100800t.me/Stellite_EN/40349 Doktor, you will find a lot more detail in the XTL discord here: https://discord.gg/S7qKV6EI can put you in touch with the team directly if needed. |
|
|
|
@Doktor:
Stellite will Hardfork next Week. Can u please implement th new Code so that it is also Mine able?
THX
Hayzam from XTL said that they will be reaching out. I too hope that @Doktor83 is willing and able to implement their upcoming custom algo. Please keep up the good work, Dok! |
|
|
|
|
