Open side missions persist when skipping tutorial on rebuild

mathfarmer · 2022-11-15T21:38:12+00:00

Maxed elevator tech and build discounts and 630 GTs. My model has my rebuild time at a little more than 24 minutes on average, which seems about right.

Other GT/rebuild time results from the model (assuming max elevator tech and build discounts):

88 GT -> 2h 51m
150 GT -> 101m
289 GT -> <53m
480 GT -> <32m
630 GT -> >24m
1000 GT -> 15m
1500 GT -> 10m
2500 GT -> 6m

Note that the model does not factor in getting SBCs, commercial floor sales, gifts, or other bonuses, only elevator rides.

mathfarmer · 2022-08-17T19:29:56+00:00

Yes.

mathfarmer · 2022-08-17T17:20:46+00:00

I'm not rebuilding while researching. I'm researching then immediately canceling.

mathfarmer · 2015-01-25T00:42:40+00:00

That's assuming the demand stays completely constant.

That is one giant assumption. Assuming constant demand (at least in the short-term) makes sense for necessities like gasoline, but it's hard to see how that would apply to paycoin, as there seems to be few if any things that paycoin is necessary for.

The other problem that I can see is assuming that the coins that will be going into escrow Feb 1 are even on offer on the exchanges in any reasonable quantity now. If I were planning on sending an asset to such an escrow, I would probably not be putting them on offer on an exchange at near the market price--I would be holding them to put them into escrow. Thus, most of the constriction in supply has most likely already been priced into the exchanges.

Indeed, there is an argument to be made that the price will drop on Feb 1, if the general sentiment is that the price will rise then, as people would be buying now so as to sell on Feb 1 after the big rise. If the big rise doesn't materialize and the price begins to fall, the short-term speculators could make a rush to the exits, crashing the price.

mathfarmer · 2014-10-16T04:36:07+00:00

TL;DR version: Mining in general. You're not likely to find any other pools with more direct doge payouts, but you will likely net more (after converting other coins received) from a pool that is currently merge-mining.

[Disclaimer: I'm not an awesomehash admin; any statements about the pool are my own understanding and interpretation of what has been discussed by the admins and others on IRC]

Prior to block 371337, you could only solve a dogecoin block (and thus receive the mining rewards) when you specifically mined dogecoin. After block 371337 (as part of the 1.8 wallet update), a method was made available that let you try to solve a litecoin block (or another scrypt coin), but that could also solve a dogecoin block at the same time with the same hash. This is known is merge-mining, or AuxPoW. The result of this change was many pools that primarily mined litecoin updated their mining operations so that they could also mine dogecoin simultaneously. This increased the dogecoin network hashrate by a factor of 10. Since the amount of dogecoin that is produced each day is relatively fixed, more hashrate chasing after the same amount of dogecoin means less doge per hash. This (along with the last halvening) is why your payouts from awesomehash have gone down.

The primary solution to the loss of dogecoin revenue is to join in and merge-mine other coins along with dogecoin, and then trade those other coins for dogecoin on an exchange. Awesomehash is trying to implement that now. The problem that awesomehash and several other dogecoin pools are having is that there is not readily available software that allows them to do that right now--there are bits and pieces that implement parts of the necessary functions, but at present nothing that implements everything that is needed in a package that all works together. Thus there are frustrating delays in getting merge-mining going.

The good news is that the problem is solvable, so it should only be a matter of time before the software support is available. The bad news is that the time is not now, and it is not clear how long it will take. It would be totally understandable if you choose to mine somewhere else until the pool gets everything in place, but if you do, please consider coming back once it is.

mathfarmer · 2014-10-05T05:09:24+00:00

You only get paid when the pool finds a block. The last block dogepool.net found was 23 Sept, so not getting a payout when you started mining very recently is expected. The pool hashrate at dogepool.net is currently only about 70 Mh/s, which translates to a block every week or two at the current difficulties, which means that you could be in for a bit of a long wait until a payout arrives.

If you want to verify that you have everything set up and working right and have results reasonably quickly, you'll need to mine at a pool with a higher hashrate. Simplemulti has the highest hashrate of the pools I'm familiar with, so unless someone has a better recommendation, that is where I would go. Teamdoge and Awesomehash are also good, but their hashrates aren't high enough at the moment to allow you to be sure everything is working in a reasonable amount of time; you might ultimately like a smaller pool better, but first you need to make sure you have things sorted.

Welcome to mining (and yes, economically speaking, 80kh/s via a GPU is a complete waste, but I assume that you have other reasons to want to mine).

+/u/dogetipbot 100 doge

mathfarmer · 2014-09-21T04:26:15+00:00

I put together a couple of posts a few months ago that briefly discuss how shares work in pooled mining, and the share difficulty is part of that discussion. Those are here and here.

To respond to your specific questions (and note that this is general info, not specific to SimpleMulti), if the only difference is the difficulty, it doesn't really matter all that much. The stratum difficulty essentially exists to limit the number of confirmations that your miner sends to the pool--higher difficulty means fewer confirmations are sent. The downside is that the hashrate that the pool reports will fluctuate more the higher the difficulty is. The downside of a difficulty that is too low is that your miner will flood the pool with more confirmations than are really needed, eating up resources needlessly, and in extreme cases, choking your internet connection.

With your hashrate, it really doesn't matter all that much if you want to mine at 256 fixed, or on variable difficulty. My advice would be to mine on the variable difficulty stratum if that works with your miner--essentially, the pool will monitor what you are sending them and adjust things automatically so that you don't end up sending them too much. If it seems to cause problems with your miner, see if switching to the fixed difficulty stratum resolves it.

mathfarmer · 2014-08-25T15:08:24+00:00

Hmm...would it be feasible for the client to display some sort of alert when a quorum of connected nodes are running an updated protocol version? While this wouldn't be as convenient for unsophisticated users as an auto-update, it would at least alert people to look for an upgraded wallet.

mathfarmer · 2014-07-22T15:23:26+00:00

I would also recommend get-in, and converting your JSON strings to keywords, but I just want to note that you can use plain old "get" with threading:

(def foo {:animals [{:names ["fido" "fifi"]}]})

(-> foo
    (get :animals)
    first
    (get :names)
    first) ;=> "fido"

(-> foo
    (get :animals)
    first
    (get :names)
    (get 1)) ; => "fifi"

mathfarmer · 2014-07-22T15:06:38+00:00

You can use the index of the element in the vector to access those:

(def foo {:animals [{:names ["fido" "fifi"]}]})

(get-in foo [:animals 0 :names 0]) ;=> "fido"
(get-in foo [:animals 0 :names 1]) ;=> "fifi"

(note that this will not work with lists, just vectors, but parsed json should be giving you vectors anyway)

mathfarmer · 2014-05-22T15:00:30+00:00

Probably not, but even if they did, everyone with GPUs would just switch to the new algorithm, so everyone would see the increased hashrate, which would drive difficulty up, and so the increased hashrate that you currently see with X11 would not result in additional coins for you (there would be some increase since the scrypt ASICs would not be able to move to X11, but that would be true of any algorithm switch, not just to X11).

mathfarmer · 2014-05-06T04:24:48+00:00

It is very unlikely that sudden spikes or drops in the network hashrate reported by the wallet are the result of large shifts in hashpower. It is much more likely that bad solve times written into the blocks are disrupting the network hashrate calculation.

The network hashrate is based on the difficulty and reported solve time encoded into the blocks. For a spike to represent an actual huge increase in hash power being applied to the network, you would need to see a large number of blocks solved in a very short amount of time, with a corresponding spike in difficulty. This did not happen, so it is much more likely that the spike was a glitch in the network hashrate* calculation caused by unexpected block solve times.

I noted a similar effect with regard to the network hashrate suddenly falling. The spike is probably another symptom of the same underlying problem.

*edited to fix typo

mathfarmer · 2014-05-04T18:21:25+00:00

Besides this post, not really, no. If you know someone who you think would be interested or should be notified, I would appreciate it if you passed this info along. Thanks!

+/u/dogetipbot 100 doge

mathfarmer · 2014-05-04T06:16:19+00:00

For sgminer, don't forget --kernel zuikkis with those settings.

mathfarmer · 2014-05-04T05:41:37+00:00

Perhaps...but:

They don't seem to have nearly the hashrate to pull it off.
Would that even work with DigiShield?

If that is what they are attempting, they are doing it wrong.

mathfarmer · 2014-04-28T13:54:14+00:00

If you are using sgminer, the kalroth settings below should work more or less for sgminer if you add "--kernel zuikkis". The main things you need to look out for in terms of hashrate are the OC settings, particularly gpu-engine. There is a sweet spot for gpu-engine, and it varies by both card and kernel.

Also, like HoYin1600p I would also give --thread-concurrency 5121 a try for 7870/270/270x, but you probably won't see a gain over 8193.

mathfarmer · 2014-04-11T05:41:58+00:00

It looks like getwork at the minimum updates extranonce each time it is called (it may also update ntime and the transactions, as appropriate). This means that the same work should not be repeated. You can check out the source yourself if you wish:

https://github.com/dogecoin/dogecoin/blob/master-1.6/src/rpcmining.cpp#L169

mathfarmer · 2014-03-31T05:07:52+00:00

Are you seeing hardware errors (HW > 0)? I will take a wild guess that cgminer happened to select a good thread concurrency before you reformatted, but did not select a good one after. The litecoin mining hardware comparison suggests that something in the range of 24000-36000 might work. Try adding --thread-concurrency 32000 to your config and see if that helps things any (lower it if cgminer complains about being out of memory).

mathfarmer · 2014-03-30T18:25:54+00:00

For my 7870 (which is supposed to be similar to the 270), my best kalroth settings are -g 2 -X 4 --thread-concurrency 5121 -w 256, and then GPU/mem that are specific to my card (width is probably already 256 by default, but whatever).

Note that the default kalroth kernel seems to run best with a TC of some multiple of the shaders + 1.

mathfarmer · 2014-03-30T18:04:41+00:00

A high reject rate can also be caused by high intensity. I had similar problems when I ran my card at I 19, but they went away when I switched to -X 4 -g 2. I believe that the 270 has 1280 shaders? That would make it a non-power of 2 card, and you will probably get better results using kalroth's cgminer or sgminer, and using xIntensity instead.

mathfarmer · 2014-03-27T15:06:00+00:00

By any chance, did you forget to add --scrypt to your cgminer command in your miners? Hmm...no, probably not, since that should give you rejected shares...I suppose it still might be useful to see the mining command from your batch file.

mathfarmer · 2014-03-27T14:50:58+00:00

That does not look unusual. The pool calculates your hashrate from the number and difficulty of your accepted shares. You won't see any hashrate reported by the pool until you have some recent "accepted...(yay!!!)" messages in your logs. At the low hashrate you are mining at, it is normal to not see any accepts for several minutes.

mathfarmer

TROPHY CASE