 Show Posts
|
|
Pages: [1] 2 »
|
|
3
|
Economy / Service Announcements / Re: [ANN] MiningRigRentals.com - Web pool manager - Easy Mass Rentals - Algos!
|
on: November 20, 2014, 09:09:00 AM
|
For some reason a (very) high proportion of my rigs lock-ups (where it freezes up and doesn't reboot/restart) are occurring at the start of rentals, usually a short while into it. Does anyone have any idea why? At first I thought it a fluke, but it's happening enough, and across multiple algorithms, to make me think there is something in the connection with MRR that is causing the problem. For example on Neoscrypt I ran for almost a week just now without any lock-up, only to have it die a few minutes into a rental this evening. I don't have any clues on my end. Any insight/advice/ideas would be appreciated.
Did you set up backup stratums?, looks like EU stratums are having problems... from my experience, EU stratums are going offline very often (back and forth between EU and USA stratums) It's happening on rentals so I have no control over what pools the renter chooses. It would be nice if the rig defaulted back to our pools if a renter's pool dropped out for any reason. But I don't see why a dropped pool should lock up the miner. In my case it would lead to a 0-accepts condition which would force a reboot after 6 minutes, but then it would start trying to miner again, rebooting every six minutes. I don't think that is happening. I'm using a multi-algorithm setup with active pools listed on at least three algorithms at MRR typically, with another backup pool that does not go through MRR if MRR dies entirely. First of all excuse me for my bad english. I'm not talking about renter pools, I'm talking about the MRR stratums your miner connects to when rental starts. Let me try to explain... I'm located in EU, so my first option in miner configuration file is the European stratum ( http://eu-01.miningrigrentals.com:3333). If you don't set up a backup stratum and MMR's EU stratum goes down you are in trouble, so I always set up a second MMR stratum pointing to US servers (us-east01.miningrigrentals.com:3333). Please look at my CGMiner configuration file: { "pools" : [ { "name" : "MRR -NEOScrypt- EU", "url" : "stratum+tcp://eu-01.miningrigrentals.com:3333", "user" : "user_name", "pass" : "x", "Algorithm" : "neoscrypt" }, { "name" : "MRR -NEOScrypt- USA", "url" : "stratum+tcp://us-east01.miningrigrentals.com:3333", "user" : "user_name", "pass" : "x", "Algorithm" : "neoscrypt" }, { "name" : "MRR -X15- EU", "url" : "stratum+tcp://eu-01.miningrigrentals.com:3333", "user" : "user_name", "pass" : "x", "Algorithm" : "bitblock" }, { "name" : "MRR -X15- USA", "url" : "stratum+tcp://us-east01.miningrigrentals.com:3333", "user" : "user_name", "pass" : "x", "Algorithm" : "bitblock" }, ... As you can see, there are two MRR stratums (EU and US east) for each algorithm. When EU MRR stratum goes down (quite often), miner switches automatically to US stratum. Hope it helps! |
|
|
|
|
4
|
Economy / Service Announcements / Re: [ANN] MiningRigRentals.com - Web pool manager - Easy Mass Rentals - Algos!
|
on: November 19, 2014, 09:44:50 AM
|
For some reason a (very) high proportion of my rigs lock-ups (where it freezes up and doesn't reboot/restart) are occurring at the start of rentals, usually a short while into it. Does anyone have any idea why? At first I thought it a fluke, but it's happening enough, and across multiple algorithms, to make me think there is something in the connection with MRR that is causing the problem. For example on Neoscrypt I ran for almost a week just now without any lock-up, only to have it die a few minutes into a rental this evening. I don't have any clues on my end. Any insight/advice/ideas would be appreciated.
Did you set up backup stratums?, looks like EU stratums are having problems... from my experience, EU stratums are going offline very often (back and forth between EU and USA stratums) |
|
|
|
|
5
|
Alternate cryptocurrencies / Mining (Altcoins) / Re: [ANN] sgminer v5 - new unified multi-algorithm on-the-fly kernel switching miner
|
on: November 13, 2014, 04:49:57 PM
|
I have an interesting phenomenom with neoscrypt, on 280x. With intensity 13, I get about 298kh/s stable. If I then lower intensity to 12, hashrate rises to 305kh/s and stays there. However, if I start sgminer directly with intensity=12, hashrate is only 270kh/s or so, and does not rise any higher..  So it need to go through intensity 13, then lower to 12 to get max speed. This is with latest sgminer develop version, Wolf's kernel, catalyst 14.6. Same here! In my case at i13 I have lots oh HW errors, but after lowering intensity to 12, hashrate remains the same as in i13 but no more HW errors... But after a few minutes hashrate starts to slow down to i12 expected speeds. |
|
|
|
|
16
|
Alternate cryptocurrencies / Mining (Altcoins) / Re: [ANN][X11/X13] X11 (Darkcoin)/X13 (Marucoin) miner (based on sph-sgminer)
|
on: June 26, 2014, 04:01:54 PM
|
OK, guys, sorry to ask such a recap question but I missed some discussion here for some time:
What would be the fastest combination for Gigabyte R9280x cards in terms of kernel/driver/config/sgminer?
Currently I have W7 64bit with 14.6 driver, 4.1 sgminer and getting 2.55 MHs for each card with below.
"worksize" : "256,256,256,256",
"kernel" : "x13mod,x13mod,x13mod,x13mod",
"lookup-gap" : "0,0,0,0",
"thread-concurrency" : "8193,8193,8193,8193",
"shaders" : "0,0,0,0",
"gpu-threads" : "2,2,2,2",
"gpu-engine" : "1090,1090,1090,1090",
"gpu-memclock" : "1500,1500,1500,1500",
"x13mod" means the 31 kB (older) version.
This newer "X13mod" did not compile with some crazy error message (Some function made error at some specific line during compile.)
I can see people reporting 2.7 MHs for the same card. Can you point me to the right files and examples please?
For all of you having errors compiling X13, please update your hamsi_helper.cl file (located in kernel dir) with the code provided at: https://raw.githubusercontent.com/lasybear/sph-sgminer_x11mod/f10bf3a6f9db481611e85495eb793e21b94ed605/kernel/hamsi_helper.clThat worked for me! |
|
|
|
|
