Bitcoin Forum
November 17, 2024, 06:08:57 PM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 [411] 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 ... 499 »
  Print  
Author Topic: PhoenixMiner 6.2c: fastest Ethereum/Ethash miner with lowest devfee (Win/Linux)  (Read 784943 times)
miner29
Full Member
***
Offline Offline

Activity: 1281
Merit: 141


View Profile
March 13, 2021, 05:02:04 PM
 #8201

Is there any way to delay the application of overclock on the core during dag creation. I know its possible on the memory with -mcdag but Im having issues on the coreclock during dag creation process. I know increasing memory will increase the hashrate but in my case, increasing the coreclock increases the hashrate as well. Weirdly it only happens on my gtx 1070.

Have you tried using -lidag 3

or 2 or 1.  0 is default but it slows down dag creation and may solve your issue. 


earlybird36
Newbie
*
Offline Offline

Activity: 15
Merit: 0


View Profile
March 13, 2021, 05:12:38 PM
 #8202

Is there any way to delay the application of overclock on the core during dag creation. I know its possible on the memory with -mcdag but Im having issues on the coreclock during dag creation process. I know increasing memory will increase the hashrate but in my case, increasing the coreclock increases the hashrate as well. Weirdly it only happens on my gtx 1070.

Have you tried using -lidag 3

or 2 or 1.  0 is default but it slows down dag creation and may solve your issue. 




i have tried -lidag already. Same issue
lordsandwich
Newbie
*
Offline Offline

Activity: 4
Merit: 0


View Profile
March 13, 2021, 05:17:04 PM
 #8203

Oh great, another stellar djeZo post. If only every Redditor would see the posts here instead of the ones that get censored/locked/deleted on r/NiceHash.
miner29
Full Member
***
Offline Offline

Activity: 1281
Merit: 141


View Profile
March 13, 2021, 05:30:33 PM
 #8204

Is it me or has Mega always been a bit sketch?


Wikipedia article for more info : 

https://en.wikipedia.org/wiki/Mariposa_botnet

Very last line is important.....

apocalypse_milk
Newbie
*
Offline Offline

Activity: 7
Merit: 0


View Profile
March 13, 2021, 05:32:27 PM
 #8205

and we are are sure that most miners have much better things to do with their time than reading about this storm in a teacup. We know we do.
Hey now. I just woke up and reading this with my coffee is a great start of my day. Smiley



Cheers to that! I also fired up a cup of coffee and sat down to read the unfolding drama. This is the best sitcom since Trump.
Searinox
Full Member
***
Offline Offline

Activity: 147
Merit: 100


Do you like fire? I'm full of it.


View Profile
March 13, 2021, 05:41:48 PM
 #8206

There are many reasons why MEGA would take mining software links down that aren't as straightforward, from hosting servers in China where there is currently a crackdown, to deciding they can't be bothered to check the safety every upload to see if it's legit when so many more of them are re-uploaded altered versions with malware versus only a handful of legit ones.
globula_neagra
Newbie
*
Offline Offline

Activity: 1
Merit: 0


View Profile
March 13, 2021, 07:46:28 PM
Last edit: March 13, 2021, 11:06:16 PM by globula_neagra
 #8207

Hello all,

Want to mention first that I am not here to blame anyone, probably the only one to blame is just me for not enabling 2FA.


I got hacked and here is the story.
Been using NH for about two weeks, I was like, let me jump on the train with the rest.
At the beginning I used Phoenix miner, that was the default miner in which NH was going but I noticed that after 10+ hours was getting many errors so after about 4/5 days I decided to go on Excavator.
In the whole time I managed to mine till last night about £50 worth when the account got hacked.

The hacker got full access on my PC (Main rig, because the one that I was planning to use for mining was keep crashing), used chrome and  he went in to nice hash, he enabled 2fa on his phone and goodbye account. Went on my email and deleted the emails from nice hash.
This happened last night at 00:29. At 00:52 I woke up and checked my phone and saw notifications that I enabled 2FA on my NH account, straight away I could not log in as he was receiving the notifications for 2FA, and went for forgot password on NH.

Started sending them emails and look after anyone available from NH on Twitter, Discord.
Amazingly no one answered Smiley so there are almost 24H now passed and no one bothered to answer to my account hacking emails.

As I said, not blaming anyone, already did another account and enabled 2FA, I enabled 2FA for all my email sessions and other crap like this, fixing the second rig that was supposed to be used for mining so I segregate everything that has to do with NH and all the rigs to Linux.

This is just more of a heads up for everyone, the shit is real, something did happened  and we have the below scenarios:
1) Pheonix got hacked
2) NiceHash got hacked and someone changed the binaries for Phoenix and they are trying now to blame them.
3)Excavator got hacked
4)All the above Smiley)

Seeing the Phoenix posts here he seems a legit guy/group so I am starting to discard scenario 1.
The fact that NiceHash can`t be bothered to answer my emails and don`t have any Customer Support in weekend makes me to go for Scenario two. I have emailed them on both the CS email and the 2FA one, you would imagine that they would considering the money that they spin.





LE:
Looking thru my hard drives I noticed a file created last night at 00:31, text file.
15PWpx4vXagY5cGDEvaKV2ZcW6kq8RfDNX
This is the wallet that he used, he even named it Trazor.

Phoenix mentioned about a windows bug so I will post the session from event viewer from my hacked pc.
http://

Stay safe all

An account was successfully logged on.

Subject:
   Security ID:      SYSTEM
   Account Name:      DESKTOP-XXXX
   Account Domain:      WORKGROUP
   Logon ID:      0x3E7

Logon Information:
   Logon Type:      5
   Restricted Admin Mode:   -
   Virtual Account:      No
   Elevated Token:      Yes

Impersonation Level:      Impersonation

New Logon:
   Security ID:      SYSTEM
   Account Name:      SYSTEM
   Account Domain:      NT AUTHORITY
   Logon ID:      0x3E7
   Linked Logon ID:      0x0
   Network Account Name:   -
   Network Account Domain:   -
   Logon GUID:      {00000000-0000-0000-0000-000000000000}

Process Information:
   Process ID:      0x3d4
   Process Name:      C:\Windows\System32\services.exe

Network Information:
   Workstation Name:   -
   Source Network Address:   -
   Source Port:      -

Detailed Authentication Information:
   Logon Process:      Advapi  
   Authentication Package:   Negotiate
   Transited Services:   -
   Package Name (NTLM only):   -
   Key Length:      0

This event is generated when a logon session is created. It is generated on the computer that was accessed.

The subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

The logon type field indicates the kind of logon that occurred. The most common types are 2 (interactive) and 3 (network).

The New Logon fields indicate the account for whom the new logon was created, i.e. the account that was logged on.

The network fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

The impersonation level field indicates the extent to which a process in the logon session can impersonate.

The authentication information fields provide detailed information about this specific logon request.
   - Logon GUID is a unique identifier that can be used to correlate this event with a KDC event.
   - Transited services indicate which intermediate services have participated in this logon request.
   - Package name indicates which sub-protocol was used among the NTLM protocols.
   - Key length indicates the length of the generated session key. This will be 0 if no session key was requested.
micdee
Newbie
*
Offline Offline

Activity: 11
Merit: 3


View Profile
March 13, 2021, 10:00:39 PM
Last edit: March 15, 2021, 04:51:49 AM by micdee
 #8208

Situation:

We are no experts miners..
First we used 6 Radeon RX 580  GPU's (mixed brands) with Ubuntu as OS and Phoenixminer 5.5c as miner for a while.. Then we added a 7th 580 which came available and with no hussle we got it running. I have been busy to get the best settings for each card and got decent hashrates..

Now we wanted to up the hashrates by replacing the 580's GPU's with RX 5700 XT's one by one.
But for some reason we do not get the first one to be recognized in Phoenixminer.
It shows in the PCI list of Linux..

To make sure the 580's would run kind of optimized and since I do not know yet at what GPU number the 5700 would be set by phoenixminer, I wrote following lines in the config file:

-cclock RX*580:1150
-cvddc RX*580:850

-mclock RX*850:2175
-mvddc RX*580:860

As I understood from the help for the config file this should set the core/mem clock and voltage for all GPU's that are named RX AND 580 with the specified numbers.. all other cards (the RX 5700 XT) should use their default.
But when the miner is started the settings are not used and the RX 5700 is not displayed and we start mining with only 6 iso 7 cards.

I tried to look for any sollutions already but came without any..

Any help, ideas are highly appreciated.
PhoenixMiner (OP)
Full Member
***
Offline Offline

Activity: 357
Merit: 101


View Profile
March 14, 2021, 02:17:58 AM
 #8209

@PhoenixMiner

Any plans for monitoring and allowing fan control based on memory temperature?

Aside from the weirdness going on lately, Nicehash Quickminer does have some really nice new features.  Itcan set fan speed based on monitoring of 'Hot Spot' memory temp in DDR6 cards and Memory TJ on 3080/90 cards.
  Yes, there will be several options to control the junction temperatures and memory temperatures with the fan speed in the new version but only for AMD cards that report these temperatures. We are working on the same feature for Nvidia 3080/3090 but we are not sure it will make it for the next release.


Is it me or has Mega always been a bit sketch?
  Everyone used it for hosting mining software when we started, and we usually don't try to fix things that aren't broken. Of course, after terminating our account, we had no choice but move elsewhere. It is encouraging that other miner software survives fine on github, so hopefully it will be our new hosting solution.



Is there any way to delay the application of overclock on the core during dag creation. I know its possible on the memory with -mcdag but Im having issues on the coreclock during dag creation process. I know increasing memory will increase the hashrate but in my case, increasing the coreclock increases the hashrate as well. Weirdly it only happens on my gtx 1070.
   Not that weird  - the TLB cache is part of the core, and its speed is the limiting factor of the hashrate of GTX1070 with the current DAG sizes. We could add it but not in the next release.



Hello all,

Want to mention first that I am not here to blame anyone, probably the only one to blame is just me for not enabling 2FA.


I got hacked and here is the story.
Been using NH for about two weeks, I was like, let me jump on the train with the rest.
....
  It's hard to tell - could be anything. We know that the (non-fake) releases of PhoenixMiner are clean but we can't speculate for the rest. It could even be some kind of vulnerability at a browser, or OS level. We would recommend using firewall that is blocking outgoing connections (in the default state Windows firewall only asks for permission for incoming connections and allows all outgoing connections). With such firewall even if something is compromised, at least it won't be able to "phone home". These firewalls are a bit of pain in the ass to configure though, as a lot of things connect to the Internet all the time.



Situation:

We are no experts miners..
First we used 6 Radeon RX 580  GPU's (mixed brands) with Ubuntu as OS and Phoenixminer 5.5c as miner for a while.. Then we added a 7th 580 which came available and with no hussle we got it running. I have been busy to get the best settings for each card and got decent hashrates..

Now we wanted to up the hashrates by replacing the 580's GPU's with RX 5700 XT's one by one.
But for some reason we do not get the first one to be recognized in Phoenixminer.
It shows in the PCI list of Linux..

To make sure the 580's would run kind of optimized and since I do not know yet at what GPU number the 5700 would be get by phoenixminer, I wrote following lines in the config file:

-cclock RX*580:1150
-cvddc RX*580:850

-mclock RX*850:2175
-mvddc RX*580:860

As I understood from the help for the config file this should set the core/mem clock and voltage for all GPU's that are named RX AND 580 with the specified numbers.. all other cards (the RX 5700 XT) should use their default.
But when the miner is started the settings are not used and the RX 5700 is not displayed and we start mining with only 6 iso 7 cards.

I tried to look for any sollutions already but came without any..

Any help, ideas are highly appreciated.
  The commands look fine but you need to check how the cards are listed by the miner when you run ./PhoenixMiner -list. Some cards may be named differently and won't match the selector in the commands. You should also check the log for applying the clocks and voltages for all cards. For example:
Code:
2021.03.14:04:14:44.503: hwmc GPU1: set GPU clocks to 1090 MHz (Vddc 920 mV)
2021.03.14:04:14:44.510: hwmc GPU1: set VMEM clocks to 2000 MHz (Vddc 900 mV)
shidocs
Newbie
*
Offline Offline

Activity: 1
Merit: 0


View Profile
March 14, 2021, 06:59:11 AM
 #8210

Hello Dev,

I started mining a month ago and used PhoenixMiner most of the time.

Every 2 or so days all my cards start getting about 30% invalid shares on my 12x 3070 rig on HiveOS. At first I thought I had an issue on the rig, maybe the mobo since it was all cards at once. But everything seemed normal and even cards at 39c had the issue. Restarting the miner always solved it.

A few weeks later I made a 2 new rigs on a different city, 3000km away (2x 12x 3070). The issue happened again, on all 3 rigs at once. This ruled out local issues.

I changed one of the rigs to a different miner just to troubleshoot if it was an issue with PhoenixMiner, and apparently is. The two rigs on PhoenixMiner exhibited the same issue a couple times, while the rig on the other miner didn't.

I searched a bit and found a post on reddit with someone with the same issue, he didn't name PhoenixMiner but said many miners are experiencing the same issue on 3060 and 3070: https://www.reddit.com/r/EtherMining/comments/lz7a3f/best_mining_software_and_how_to_choose_it/gq0s4my/?utm_source=reddit&utm_medium=web2x&context=3

Apparently it has something to do with epoch changes, I researched a bit and an epoch change occurs in eth between 8 and 48 hours, which is in line of the issue happening every few days. If a new DAG needs to be generated, the issue is likely the same when we start the miner with overclocking and get tons of invalid shares. That's why HiveOS have a config option to overclock only X seconds after miner start.

If I correctly diagnosed the issue, the solution will likely be to either restart the miner on a new epoch or send some message to HiveOS to bring the cards to default settings during epoch changes, or some other software change that makes the cards be in a stable state when loading DAGs while overclocked.

I will happily change back to PhoenixMiner when there is a solution for this issue, keep up the great work!

Thanks!
msrti
Newbie
*
Offline Offline

Activity: 8
Merit: 0


View Profile
March 14, 2021, 10:58:46 AM
 #8211

Hello Dev,

I started mining a month ago and used PhoenixMiner most of the time.

Every 2 or so days all my cards start getting about 30% invalid shares on my 12x 3070 rig on HiveOS. At first I thought I had an issue on the rig, maybe the mobo since it was all cards at once. But everything seemed normal and even cards at 39c had the issue. Restarting the miner always solved it.

A few weeks later I made a 2 new rigs on a different city, 3000km away (2x 12x 3070). The issue happened again, on all 3 rigs at once. This ruled out local issues.

I changed one of the rigs to a different miner just to troubleshoot if it was an issue with PhoenixMiner, and apparently is. The two rigs on PhoenixMiner exhibited the same issue a couple times, while the rig on the other miner didn't.

I searched a bit and found a post on reddit with someone with the same issue, he didn't name PhoenixMiner but said many miners are experiencing the same issue on 3060 and 3070: https://www.reddit.com/r/EtherMining/comments/lz7a3f/best_mining_software_and_how_to_choose_it/gq0s4my/?utm_source=reddit&utm_medium=web2x&context=3

Apparently it has something to do with epoch changes, I researched a bit and an epoch change occurs in eth between 8 and 48 hours, which is in line of the issue happening every few days. If a new DAG needs to be generated, the issue is likely the same when we start the miner with overclocking and get tons of invalid shares. That's why HiveOS have a config option to overclock only X seconds after miner start.

If I correctly diagnosed the issue, the solution will likely be to either restart the miner on a new epoch or send some message to HiveOS to bring the cards to default settings during epoch changes, or some other software change that makes the cards be in a stable state when loading DAGs while overclocked.

I will happily change back to PhoenixMiner when there is a solution for this issue, keep up the great work!

Thanks!
I have 6*5700xts on my rig and this sometimes happens to me also but not too much. thanks for the description. hope the phoenix team solves this issue soon.
miner95
Newbie
*
Offline Offline

Activity: 28
Merit: 2


View Profile
March 14, 2021, 05:40:40 PM
 #8212

Nicehash now sponsoring LinusTechTips for restore their lost reputation:
https://www.youtube.com/watch?v=swOj0wvuCO8

But really why would someone want to work with Nicehash and mining ETH but receive BTC with those super high fees instead?
I used Nicehash a few years ago for 2 weeks but not only BTC fees not worth it but also their pool always make less profits than ethermine.org even in exacts same situations.
W.T.R.
Newbie
*
Offline Offline

Activity: 10
Merit: 0


View Profile
March 14, 2021, 07:17:29 PM
 #8213

Quote
Is there any way to delay the application of overclock on the core during dag creation. I know its possible on the memory with -mcdag but Im having issues on the coreclock during dag creation process. I know increasing memory will increase the hashrate but in my case, increasing the coreclock increases the hashrate as well. Weirdly it only happens on my gtx 1070.
   Not that weird  - the TLB cache is part of the core, and its speed is the limiting factor of the hashrate of GTX1070 with the current DAG sizes. We could add it but not in the next release.

Is there any way to fix this TLB cache problem? I am one of probably many 1070, and 1080Ti users that would be grateful if there would be some kind of fix for this problem in the upcoming releases. We are losing 4-10 mh/s per card now as oppose to 2017.
Tnx.
OlympicSSJ
Newbie
*
Offline Offline

Activity: 7
Merit: 1


View Profile
March 14, 2021, 10:53:09 PM
 #8214

Could some one pls tell me what command must be entered in the bat file that replaces the pill for ether?
With the pill I have around 10 mh/s increase on my 1080ti, but somewhere was mentioned now there's a command that renders the pill useless.

Im currently getting around 47,7 mh/s on a palit 1080ti Jetstream 85 tdp, 220 core, 330 mem. At very few occasions it jumps to 49 mh/s when I put EXACTLY 200 core/ 230 mem, but if goes back down to 47 whe new dag file loads or smt.
Lowering tdp below 75% or core clocks drives the speed down significantly. Any idea on different settings that can push it to 49?
Thanks!
micdee
Newbie
*
Offline Offline

Activity: 11
Merit: 3


View Profile
March 15, 2021, 05:11:12 AM
 #8215


   The commands look fine but you need to check how the cards are listed by the miner when you run ./PhoenixMiner -list. Some cards may be named differently and won't match the selector in the commands. You should also check the log for applying the clocks and voltages for all cards. For example:
Code:
2021.03.14:04:14:44.503: hwmc GPU1: set GPU clocks to 1090 MHz (Vddc 920 mV)
2021.03.14:04:14:44.510: hwmc GPU1: set VMEM clocks to 2000 MHz (Vddc 900 mV)


Tnx. I will check the data and the logfiles.
When I run the miner in the console as far as I know it always starts with the card names.. (which GPU are found for mining) In this list it shows 6 times the same (type) cards RX 580

I even had fitted the RX 5700 as a single available GPU, but then I get the miner error "NO GPU for mining"

Is there any known hardware limit for getting the RX 5700 XT's to work in Phoenixminer, e.g. minimum of RAM used, or anything else, which we might have overlooked?
The rig is fitted with only 4 Gb RAM.  (We use the Asrock H110 BTC Pro+ mobo)
PhoenixMiner (OP)
Full Member
***
Offline Offline

Activity: 357
Merit: 101


View Profile
March 15, 2021, 05:27:32 AM
 #8216

Hello Dev,

I started mining a month ago and used PhoenixMiner most of the time.

Every 2 or so days all my cards start getting about 30% invalid shares on my 12x 3070 rig on HiveOS. At first I thought I had an issue on the rig, maybe the mobo since it was all cards at once. But everything seemed normal and even cards at 39c had the issue. Restarting the miner always solved it.

A few weeks later I made a 2 new rigs on a different city, 3000km away (2x 12x 3070). The issue happened again, on all 3 rigs at once. This ruled out local issues.

I changed one of the rigs to a different miner just to troubleshoot if it was an issue with PhoenixMiner, and apparently is. The two rigs on PhoenixMiner exhibited the same issue a couple times, while the rig on the other miner didn't.

I searched a bit and found a post on reddit with someone with the same issue, he didn't name PhoenixMiner but said many miners are experiencing the same issue on 3060 and 3070: https://www.reddit.com/r/EtherMining/comments/lz7a3f/best_mining_software_and_how_to_choose_it/gq0s4my/?utm_source=reddit&utm_medium=web2x&context=3

Apparently it has something to do with epoch changes, I researched a bit and an epoch change occurs in eth between 8 and 48 hours, which is in line of the issue happening every few days. If a new DAG needs to be generated, the issue is likely the same when we start the miner with overclocking and get tons of invalid shares. That's why HiveOS have a config option to overclock only X seconds after miner start.

If I correctly diagnosed the issue, the solution will likely be to either restart the miner on a new epoch or send some message to HiveOS to bring the cards to default settings during epoch changes, or some other software change that makes the cards be in a stable state when loading DAGs while overclocked.

I will happily change back to PhoenixMiner when there is a solution for this issue, keep up the great work!

Thanks!

   The most probable reason is too much memory overclock. And if the extreme memory overclock is also applied during the DAG generation, this may lead to corrupted DAG, which then will cause a lot of invalid shares. In 5.5c you can use the option -mcdag 1 to reset the memory overclock during DAG generation. On Windows -mcdag 1 is all you need (provided that you let PhoenixMiner overclock the memory with -mclock +XXXX).

   However under Linux the things are more complicated because PhoenixMiner can't apply the memory overclock by itself. So, when you specify -mcdag 1 under Linux, PhoenixMiner searches for a shell script named daggen.sh, and if there is such a script, it is called once for each Nvidia GPU, passing the GPU index as the first argument, and PCIE bus ID as second argument. You must put in this script commands to reset the memory overclock, and to schedule re-applying the memory overclock after about 60 seconds (to be sure that the DAGs are already generated). The miner will then wait for about 7 seconds before starting DAG generation to allow the script enough time to reset the memory overclock.




Hi! Im new around here and registered here because i need little or big help with phoenixminer.

I have used it about 12 months now but recently it keeps crashing. Especially after Devfee.

example from log file:

Quote
2021.03.14:12:27:51.524: eths Eth: New job #89981f0a from ethash.poolbinance.com:1800; diff: 1073MH
2021.03.14:12:27:51.902: main DevFee: Disconnected and stopped
2021.03.14:12:27:54.975: main GPU1: 47C 77% 96W, GPU2: 49C 74% 98W, GPU3: 41C 75% 98W, GPU4: 46C 78% 93W
GPUs power: 385.0 W; cost: 0.55 USD/day
2021.03.14:12:27:55.376: main Eth speed: 158.749 MH/s, shares: 255/0/0, time: 0:30
2021.03.14:12:27:55.376: main GPUs: 1: 39.546 MH/s (67) 2: 39.759 MH/s (65) 3: 39.722 MH/s (67) 4: 39.723 MH/s (56)
2021.03.14:12:27:56.381: main Restart timeout reached

any ideas why?

After "restart timeout....." command panel just closes. No warning/error... nothing. Just closes.

config file look like this(i using -li 1 because stability no other reason):
Quote
-pool stratum+tcp://ethash.poolbinance.com:1800
-wal xxxxxxxxx
-amd -timeout 30 -lidag 2 -gt 6 -altinit -wdog 1 -wdtimeout 30 -li 1 -hstats 2 -prate 0.06 -rxboost 1

   You just need to remove the -timeout 30 option from your config.txt file as it literally forces the miner to restart after 30 minutes (do not confuse -timeout with -wdtimeout, these are very different options). Here is the help for -timeout:
Quote
-timeout <n> Restart miner according to -rmode after n minutes



Quote
Is there any way to delay the application of overclock on the core during dag creation. I know its possible on the memory with -mcdag but Im having issues on the coreclock during dag creation process. I know increasing memory will increase the hashrate but in my case, increasing the coreclock increases the hashrate as well. Weirdly it only happens on my gtx 1070.
   Not that weird  - the TLB cache is part of the core, and its speed is the limiting factor of the hashrate of GTX1070 with the current DAG sizes. We could add it but not in the next release.

Is there any way to fix this TLB cache problem? I am one of probably many 1070, and 1080Ti users that would be grateful if there would be some kind of fix for this problem in the upcoming releases. We are losing 4-10 mh/s per card now as oppose to 2017.
Tnx.
  We tried a lot of different approaches in the past but none of them worked. Only Nvidia knows if these GPUs (most of the Pascal series expect 1070Ti) even have the hardware ability to increase the virtual page size (the only thing that would fix the problem properly) like AMD did with the Polaris cards a few years ago. The whole point is moot now because even if Polaris GPUs are capable of larger page sizes, Nvidia wouldn't be bothered to release fixed drivers anyway.



Could some one pls tell me what command must be entered in the bat file that replaces the pill for ether?
With the pill I have around 10 mh/s increase on my 1080ti, but somewhere was mentioned now there's a command that renders the pill useless.

Im currently getting around 47,7 mh/s on a palit 1080ti Jetstream 85 tdp, 220 core, 330 mem. At very few occasions it jumps to 49 mh/s when I put EXACTLY 200 core/ 230 mem, but if goes back down to 47 whe new dag file loads or smt.
Lowering tdp below 75% or core clocks drives the speed down significantly. Any idea on different settings that can push it to 49?
Thanks!
  You don't need the pill with PhoenixMiner. You need to add the option -straps <n>. Start with -straps 1, and the try the higher values to see how much tighter timings the card can take. You can also try fine-tuning the memory timings with the command-line options -vmt1, -vmt2, -vmt3, -vmr - check the documentation for more information about all these options.



Tnx. I will check the data and the logfiles.
When I run the miner in the console as far as I know it always starts with the card names.. (which GPU are found for mining) In this list it shows 6 times the same (type) cards RX 580

I even had fitted the RX 5700 as a single available GPU, but then I get the miner error "NO GPU for mining"

Is there any known hardware limit for getting the RX 5700 XT's to work in Phoenixminer, e.g. minimum of RAM used, or anything else, which we might have overlooked?
The rig is fitted with only 4 Gb RAM.  (We use the Asrock H110 BTC Pro+ mobo)
  Perhaps the driver version may be the issue. Do not use the latest AMD Linux drivers for anything other than RX6000 AMD cards.
brooklynite1
Member
**
Offline Offline

Activity: 630
Merit: 10

In BTCz we trust. Organic slow growth.


View Profile WWW
March 15, 2021, 09:31:52 AM
 #8217

owners of 1080ti whats the max MH without scam ethpill file you ve been getting ?

I have 3 , 1080 Ti cards running 5.4c and 5.5c with -straps 2 and they all get 44-48 mh/s, I would say avg is 46.2 ish


Do Not use ETHPill I downloaded from the OP and get trojan. Someone remote desktop into all 3 of my PCs and went though my browser and all saved passwords. Somehow Gmail notified me ( I have no idea why). They even did VNC from my PC into my dad's and went through his stuff too.

They were mainly looking for exchange login which I don't have.  They tried logging into Bittrex and I have no funds.

brooklynite1
Member
**
Offline Offline

Activity: 630
Merit: 10

In BTCz we trust. Organic slow growth.


View Profile WWW
March 15, 2021, 09:36:48 AM
 #8218

Could some one pls tell me what command must be entered in the bat file that replaces the pill for ether?
With the pill I have around 10 mh/s increase on my 1080ti, but somewhere was mentioned now there's a command that renders the pill useless.

Im currently getting around 47,7 mh/s on a palit 1080ti Jetstream 85 tdp, 220 core, 330 mem. At very few occasions it jumps to 49 mh/s when I put EXACTLY 200 core/ 230 mem, but if goes back down to 47 whe new dag file loads or smt.
Lowering tdp below 75% or core clocks drives the speed down significantly. Any idea on different settings that can push it to 49?
Thanks!


For me -straps 2 does exactly bwhat ETHPill did

Actually I downloaded ETHpill from OP relink and it was a Trojan virus. Someone remote desktop to all 3 of my computers and obtain my passwords and logged in to many of my accounts and attempted to reset passwords too.

brooklynite1
Member
**
Offline Offline

Activity: 630
Merit: 10

In BTCz we trust. Organic slow growth.


View Profile WWW
March 15, 2021, 09:39:19 AM
 #8219

Dear Phoenix Miner Dev,

With the impending end of life for ethereum mining in the near future any plans to add Ravencoin to the mix since other progpow crypto is already on the list?

Mine ETC. I believe it will replace ETH by 2024 as it runs the same Solidity code and the support is growing after announcement of EIP1559. ETC is at historic lows and has a lot of potential. RVN is just another crypto.

Littlegrand
Jr. Member
*
Offline Offline

Activity: 104
Merit: 5


View Profile
March 15, 2021, 01:38:59 PM
 #8220

I have a RX 5700 XT MIS Mech 8gb Windows 10.

It runs fine for 1-12 hours then cuts back to 47mh/s.  I have tried adjusting the clock/mem down with a starting hashrate from 57mh/s down to 52mh/s(almost stock).  1230-1340 clock and 1750-1896 mem, all do this reset to 47mh/s...

Any idea why this card would randomly cut back to 47mh/s or a way to diagnose it?  A restart of the software does not work I have to reboot the computer.  I have 2 RX 570 8gb running with they card at 31mh/s and they are not affected.

Thanks
Pages: « 1 ... 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 [411] 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 ... 499 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!