Why 50% of the time when I try to browse https://leaserig.net/index.jsp?page=admin it's offline or down? I have to refresh few times, sometimes it's start working, sometime don't tried in few different browsers and noticed same behaviour.
It's a DNS Problem, used to happen to me lots, add the following to your hosts file
290x/win7 x64/13.12cat before(2%-version): -w 256 -tc 20481 -g 1 -I 21 -----> 3.85mhs after(free-version): -w 256 -tc 20481 -g 2 -I 15 ----->2.75mhs no way for -g 1/-w64/-w128-parameters - it`s always 2.6mhs or less
PS What are the optimal settings for 290x/290? I still think that the lack off "-I" (crash of miner when "-I" is above 15) is the main issue in reaching more mhs.
Same problem for a 290/W7/cat14.4
2% version : I 15-> 2800 Mhs, I 19 ->3900 Mhs free version: I 15-> 3050 Mhs, crashes for I > 15
On BAMT 1.3, I only get 2850 Mhs for I 15 and crashes for I > 15.
Edit : 3080 Mhs with TC 8192 and gpu-threads 2
Post
Topic
BoardService Announcements
Re: [ANN] LeaseRig.net Rent & Hire Scrypt(Jane/Nfactor)/SHA3/SHA256/X11 HashPower!
What does everyone think about not letting rehires to happen for x amount of minutes?
I'm getting more people renting my rigs for 1 hour and instantly rehiring it for additional hours at a lower rate. I like the discount incentive to rehire, but not when it's used just to lower my rates...
That needs to go in the development queue. Rehires should only be valid for the original rental term?
Only valid for renting plans shorter than the first one ?
Post
Topic
BoardAnnouncements (Altcoins)
Re: [ANN][DRK] DarkCoin | First Anonymous Coin | No Premine | DGW | ASIC Resistant
I tryed a few drivers, but the fact is that it happened only with Darkcoin mining, so it should put the driver/bios/hardware aside if I'm correct. I'm pretty sure that there is something in the miner that react baddly with the R9 290.
I just noticed one more thing: When the loss happened: all my cards (even the non-290) had a huge drop. After that drop, all the cards climb up again, the other model reach their max hasrate, and the 290 reach only 90% of max hasrate.
Since I'm not really fluent in English here is an example:
Coldreboot 290: 2.5 270: 1.3 10 minutes then a drop in the same second of all the cards in the rigg 290:1.5 270 0.9 Immediatly the hasrate started to recover and a few seconds later: 290: 2.3 270: 1.3 so a loss is visible only on the 290 If I restart the miner, I keep that last hasrate. If I coldreboot: It starts over.
PS: it happend the same way without overclocking: 290 went from 2.0 to 1.8.
This reminds me of a problem I had when I was mining ultracoin during last N change. I was looking for a new cgminer config and came up with TC=56xxx. Hashrate was very good till it drops for 3 cards (rig have 4 R9 290) after ~several minutes. The solution was to lessen TC count. Give it a try.
So the coin is, in essence, ''miner resistant'' no matter what device mines it. pfft, advertise asic resistant when asics won't be mainstream for another few months. This changes everything and once again, hidden and tweaked info. utc seeming more and more like a sophisticated pump and dump since all ''miner-attainable coins'' will have been mined in 1 month with millions of coin inaccessible, in the blockchain. Diff will drop dramatically when gpu's no longer able to mine, so its good for the cpu's until the next nfactor after this next nfactor in april. Then pointless to mine completely.
I don't get it. Everybody will suffer the same drop in hashrate for each N increase so diff coin output will stay the same unless people stop mining. And I think GPU are still ahead of CPU for 10 months+.
Anyway I prefer utc not being cpu efficiently minable else it'll mean botnets, aws instances ...
We need to know how n-factor affected cpu miners, if hashes halved. Is anyone even cpu mining?
I don't know for ultracoin but this is what was tested for Yacoin when it was cpu only. You can see hashrate is roughly halved with each N increase as long as it doesn't change of memory type. For example, the change 13->14 shows a big loss because dataset doesn't fit in L2 cache anymore.
Code:
NfactorNMemoryUNIX TimeDate/Time in GMTHashrate for 2x Xeon E5450 13163842MB1380574112Mon - 30 Sep 2013 - 20:48:32 GMT2,276 14327684MB1384768416Mon - 18 Nov 2013 - 09:53:36 GMT606
Post
Topic
BoardAnnouncements (Altcoins)
Re: [ANN][CACH] CACHeCoin released based on scrypt-jane
by
Puycheval
on 08/03/2014, 14:25:06 UTC
This coin has a really slow difficulty adjustment. Kind of old time coins. Global hashrate is only 10% of what it was before N change and diff just went down from 81 to 64 ! Is it dev's goal, only POS ?
i tried thread concurrencies (45000,56320,47930,42000), 45000 gave me same hash rate while the other 3 gave me either crash or no improvement. in doge and vert i had my optimum tc at 24550
i tried thread concurrencies (45000,56320,47930,42000), 45000 gave me same hash rate while the other 3 gave me either crash or no improvement. in doge and vert i had my optimum tc at 24550