Search content
Sort by
Showing 14 of 14 results by bark0de
The new beta version is ready. It is mostly a bugfix release, the more significant upgrades are coming next month. You can download PhoenixMiner 6.0a from here:
PhoenixMiner_6.0a_Windows.zip
PhoenixMiner_6.0a_Linux.tar.gz
The new features in this release are:
The updated list of known issues (driver incompatibilities, etc.) and workarounds:
AMD Linux driver 21.40.1 has a bug preventing proper setting of clocks and voltages on older cards (RX4x0/RX5x0/Vega/RadeonVII). Given that these drivers are also
usually slower than the older drivers for these cards, we recommend using Linux drivers 20.30 for anything older than RX6000 series.
If you are using Linux drivers 21.40.1 with Radeon VII cards, you need to add the option -fpwm 1 in order to have proper fan control.
AMD Linux drivers 21.40.1 has finally removed the requirement of PCIe atomics but there are problems when you try to mix Polaris (RX4x0/5x0) cards and Vega or newer
cards on the same rig.
Some Nvidia cards will report a lot of stale shares under Windows 11. Using the same driver version under Windows 10 resolves the issue.
PhoenixMiner_6.0a_Windows.zip
PhoenixMiner_6.0a_Linux.tar.gz
The new features in this release are:
- Full LHR disable mode -lhrdis <n> 1 - yes (default), 0 - no
- Show the GPU vendor name in the list of GPUs to make it easier to identify the GPUs
- Added support for the latest AMD Linux drivers 21.40.1. There are some bugs in these drivers, particularly the clocks and voltages can't be set properly with older
cards (RX4x0/RX5x0/Vega/RadeonVII) - Validated support for the latest AMD Windows drivers up to 21.11.2
- Fixed issues with AMD RX6700XT cards with the latest AMD and Linux drivers
- Fixed issues with AMD Vega and Radeon VII cards on latest Windows and Linux drivers
- Fixed crash with very old Nvidia drivers (3xx.x)
- Other fixes and small improvements
The updated list of known issues (driver incompatibilities, etc.) and workarounds:
AMD Linux driver 21.40.1 has a bug preventing proper setting of clocks and voltages on older cards (RX4x0/RX5x0/Vega/RadeonVII). Given that these drivers are also
usually slower than the older drivers for these cards, we recommend using Linux drivers 20.30 for anything older than RX6000 series.
If you are using Linux drivers 21.40.1 with Radeon VII cards, you need to add the option -fpwm 1 in order to have proper fan control.
AMD Linux drivers 21.40.1 has finally removed the requirement of PCIe atomics but there are problems when you try to mix Polaris (RX4x0/5x0) cards and Vega or newer
cards on the same rig.
Some Nvidia cards will report a lot of stale shares under Windows 11. Using the same driver version under Windows 10 resolves the issue.
I know it's a small amount in difference, but it kinda stinks that I ordered one last week and now it's .065 BTC cheaper. I would have been better off continuing to mine with the cubes I had and waited 5 more days for this thread to be updated 
C'est la vie, I suppose. I just figured that jumping on the promotion for group 34 customers was going to give me a great discount.
Cheers anyhow to your outstanding service. I am still happy with your efforts
C'est la vie, I suppose. I just figured that jumping on the promotion for group 34 customers was going to give me a great discount.
Cheers anyhow to your outstanding service. I am still happy with your efforts
How much RAM is in your laptop? I thought someone mentioned having issues with that a little while back.
The laptop has 8 GB of RAM. Its a brand new HP Probook running Win7 x64 with nothing else installed (fresh install).
Yeah no problems there.
Have you tried running each miner on it's own for 10+ mins?
Have you connected them without using the DSL modem?
I have it running on the DSL because that is an extra internet connection that I have in my office just in case shit hits the fan with our redundant FIOS connections. It isn't being used for anything otherwise, so its an isolated network that doesn't pass through our firewall. I did it this way because for some reason I could not get the proxy to work behind my firewall. I tried opening ports 3333 and 8332 from Any to the three IPs (laptop, blade, and cube), and from the three IPs to ANY, but for whatever reason the proxy doesn't communicate with the miners when its on my firewalled network
The IP of the machine running the proxy is static (192.168.1.50) and the IP of the miners are static (192.168.1.100 and 192.168.1.101), and there is nothing else on this network. The entire network is just 1 laptop, 2 miners, a small switch (which I tried replacing already to rule that out), and a DSL modem which acts as the router.
Yes, the hardware is rebooting itself, but to answer your question, the proxy does eventually pick it back up and it starts to mine again automatically. But these constant disconnects are keeping my average hash rate much lower than what it should be.
When I run bfgminer I get a strange message which sates "Pool 0 is hiding blocks from us" and then BFGMiner closes. I am running it with these command line switches:
bfgminer.exe --http-port 8332 -o http://stratum.btcguild.com:3333 -u bark0de_proxy -p x
I execute this via a batch file which I run from the same directory as BFGminer.
I reached out to CanaryInTheMine and he told me that the miners are hardcoded to reboot themselves if they stop receiving work for a while. The question is, why do they stop receiving work?
When the miners stop getting work, I check the proxy console and I see that it stops showing the really fast messages that say " Submitting ####### from bark0de_cube accepted" and it only shows messages that say something like "new job #######" i forget what exactly it says, but basically it stops mentioning the ASICs and seems to just show messages that say something to the effect of "I just got another job from the pool and I am waiting for a worker to take this job"
Thanks for your help. I hope someone can help me get to the bottom of this
Yes, the hardware is rebooting itself, but to answer your question, the proxy does eventually pick it back up and it starts to mine again automatically. But these constant disconnects are keeping my average hash rate much lower than what it should be.
When I run bfgminer I get a strange message which sates "Pool 0 is hiding blocks from us" and then BFGMiner closes. I am running it with these command line switches:
bfgminer.exe --http-port 8332 -o http://stratum.btcguild.com:3333 -u bark0de_proxy -p x
I execute this via a batch file which I run from the same directory as BFGminer.
I reached out to CanaryInTheMine and he told me that the miners are hardcoded to reboot themselves if they stop receiving work for a while. The question is, why do they stop receiving work?
When the miners stop getting work, I check the proxy console and I see that it stops showing the really fast messages that say " Submitting ####### from bark0de_cube accepted" and it only shows messages that say something like "new job #######" i forget what exactly it says, but basically it stops mentioning the ASICs and seems to just show messages that say something to the effect of "I just got another job from the pool and I am waiting for a worker to take this job"
Thanks for your help. I hope someone can help me get to the bottom of this
How much RAM is in your laptop? I thought someone mentioned having issues with that a little while back.
The laptop has 8 GB of RAM. Its a brand new HP Probook running Win7 x64 with nothing else installed (fresh install).
Quote
What power supply are you running?
What mining program are you running & stratum proxy?
Any other relevant information you could share? Like, what is the LED doing? What does the web interface tell you.
What do you mean they "restart". I assume they continue to run in standby mode? If you prefer to keep this on the public board. feel free to quote this and reply back on the board. cheers.
What mining program are you running & stratum proxy?
Any other relevant information you could share? Like, what is the LED doing? What does the web interface tell you.
What do you mean they "restart". I assume they continue to run in standby mode? If you prefer to keep this on the public board. feel free to quote this and reply back on the board. cheers.
My power supply is a Corsair CX800
I am connecting the blade and the cube via slush's proxy (since I can't seem to get the BFGminer proxy to work right)
I have tried both slush's pool and BTCGuild (i prefer BTCGuild)
They blade and cube are properly cooled in a server room with dedicated AC kept at 60 degrees F and fans blowing directly on them
They are connected directly to a dedicated DSL line (not the best, but I chose to do it this way because it bypasses my company firewall)
I haven't actually sat to observe the status LED, but I just went down now to check it out and I just see it blinking repeatedly.
They will hash fine for about 10 minutes and then they just suddenly stop receiving work. When this happens, I see on the mining proxy that it stops showing the messages where it shows the username for the blade and the username for the cube doing work, and it only shows messages like "new job xxxxxx" which seems to me like the proxy is still requesting jobs from the pool, but it's just not passing it to the ASICs for some reason.
On the web config, I notice that the running time for both the blade and the cube are always the same, meaning that they are restarting themselves at the exact same time.
My blade is the new blade model. My cube is from CanaryInTheMine's most recent batch.
I hope this is enough information
Is your IP for the proxy static?
My initial thought was this, something related to a networking issue. But he stated that the hardware is actually restarting themselves.see below.
On the web config, I notice that the running time for both the blade and the cube are always the same, meaning that they are restarting themselves at the exact same time.
But the thing is, if the hardware is rebooting itself, why isnt the software picking them back up again and relaying work to them. Strange.
bark0de, you mentioned that you couldnt get BFGMiner to work properly. I found it to be easier set up wise.If you are running windows PC
Have you tried passing this --->
Code:
--http-port 8330
in the target area. For example, on the gui I right click the gui and in the target area at that script Code:
C:\mine\bfgminer-3.8.0-win32\bfgminer.exe --http-port 8330
and work from there, later saving to config file (forgive me if your way past this step and/or running linux. Then again, maybe your better off with slushes proxy because I am still wondering if BFGMiner is responsible for my "Long Poll: inactive" question
The IP of the machine running the proxy is static (192.168.1.50) and the IP of the miners are static (192.168.1.100 and 192.168.1.101), and there is nothing else on this network. The entire network is just 1 laptop, 2 miners, a small switch (which I tried replacing already to rule that out), and a DSL modem which acts as the router.
Yes, the hardware is rebooting itself, but to answer your question, the proxy does eventually pick it back up and it starts to mine again automatically. But these constant disconnects are keeping my average hash rate much lower than what it should be.
When I run bfgminer I get a strange message which sates "Pool 0 is hiding blocks from us" and then BFGMiner closes. I am running it with these command line switches:
bfgminer.exe --http-port 8332 -o http://stratum.btcguild.com:3333 -u bark0de_proxy -p x
I execute this via a batch file which I run from the same directory as BFGminer.
I reached out to CanaryInTheMine and he told me that the miners are hardcoded to reboot themselves if they stop receiving work for a while. The question is, why do they stop receiving work?
When the miners stop getting work, I check the proxy console and I see that it stops showing the really fast messages that say " Submitting ####### from bark0de_cube accepted" and it only shows messages that say something like "new job #######" i forget what exactly it says, but basically it stops mentioning the ASICs and seems to just show messages that say something to the effect of "I just got another job from the pool and I am waiting for a worker to take this job"
Thanks for your help. I hope someone can help me get to the bottom of this
Quote
What power supply are you running?
What mining program are you running & stratum proxy?
Any other relevant information you could share? Like, what is the LED doing? What does the web interface tell you.
What do you mean they "restart". I assume they continue to run in standby mode? If you prefer to keep this on the public board. feel free to quote this and reply back on the board. cheers.
What mining program are you running & stratum proxy?
Any other relevant information you could share? Like, what is the LED doing? What does the web interface tell you.
What do you mean they "restart". I assume they continue to run in standby mode? If you prefer to keep this on the public board. feel free to quote this and reply back on the board. cheers.
My power supply is a Corsair CX800
I am connecting the blade and the cube via slush's proxy (since I can't seem to get the BFGminer proxy to work right)
I have tried both slush's pool and BTCGuild (i prefer BTCGuild)
They blade and cube are properly cooled in a server room with dedicated AC kept at 60 degrees F and fans blowing directly on them
They are connected directly to a dedicated DSL line (not the best, but I chose to do it this way because it bypasses my company firewall)
I haven't actually sat to observe the status LED, but I just went down now to check it out and I just see it blinking repeatedly.
They will hash fine for about 10 minutes and then they just suddenly stop receiving work. When this happens, I see on the mining proxy that it stops showing the messages where it shows the username for the blade and the username for the cube doing work, and it only shows messages like "new job xxxxxx" which seems to me like the proxy is still requesting jobs from the pool, but it's just not passing it to the ASICs for some reason.
On the web config, I notice that the running time for both the blade and the cube are always the same, meaning that they are restarting themselves at the exact same time.
My blade is the new blade model. My cube is from CanaryInTheMine's most recent batch.
I hope this is enough information
My cube and a blade that I have keep restarting every 10 minutes or so. They hash fine during the 10 minutes, but then they just decide to restart. They're not overheating, they just stop getting work for some reason. Anyone know what might be wrong here? .1 BTC bounty if you can please help me fix this
I am trying to use bfgminer as a proxy, I have the run parameters all set for connecting to BTCGuild but when I run the batch file bfgminer it says "Pool 0 is hiding blocks from us" and promptly closes. Anyone know how to fix that? Here is how I am running bfgminer:
bfgminer.exe --http-port 8330 -o http://stratum.btcguild.com:3333 -u -p x
Thanks!
bfgminer.exe --http-port 8330 -o http://stratum.btcguild.com:3333 -u -p x
Thanks!
You've gotten farther than me with bfgminer... I have the exact command line but mine says "looking for device, press [M] to add device, [Q] to quit" and then if I press M it closes.
I might try messing around with it later tonight, but I am happy with Slush's pool for now. Just glad to have the damn thing running at 97% efficiency.
For some reason it doesn't work well for me using slush's proxy. The damn thing keeps rebooting because it stops getting work.
I am trying to use bfgminer as a proxy, I have the run parameters all set for connecting to BTCGuild but when I run the batch file bfgminer it says "Pool 0 is hiding blocks from us" and promptly closes. Anyone know how to fix that? Here is how I am running bfgminer:
bfgminer.exe --http-port 8330 -o http://stratum.btcguild.com:3333 -u -p x
Thanks!
bfgminer.exe --http-port 8330 -o http://stratum.btcguild.com:3333 -u -p x
Thanks!
Re: [CLOSED] batch #35 1.0 btc per CUBE 30Gh/s - 38Gh/s, 49 port hubs
What does it mean if the cube keeps restarting itself? I am using a corsair power supply which I previously used to power 4 of the old generation of blades. Followed the guide and all, but it keeps restarting after about 10 minutes running.
What does it mean if the cube received jobs but the accepted/rejected numbers stay at 0?
EDIT: Actually it does start working but then it gets up to 37000 MH/s and then it starts going downwards towards 22000 MH/s and then it reboots itself. I have all O's on the chips though. Any thoughts?
EDIT: Actually it does start working but then it gets up to 37000 MH/s and then it starts going downwards towards 22000 MH/s and then it reboots itself. I have all O's on the chips though. Any thoughts?
Just want to introduce myself as a newbie on this forum. I am somewhat new to bitcoin. I've been reading about it for a while, but never thought it was going to really establish itself the way it has. I recently started mining, and have been frequenting this forum for about a month now. I finally decided to create an account, and hopefully provide some useful contribution to this community.
Cheers
Cheers