One thing to keep in mind is that I capture the stats once a day and it just so happened that today the exchange rate for doge was significantly higher than yesterday, mining proceeds over 24 hours roughly the same, so the end result was 0.008+ instead of ~0.006. I could easily go the other way, e.g. exchange rate could drop next day and BTC profitability could be 0.004. If I had been exchanging coins e.g. every hour then the profitability would be probably less erratic because I would be tracking the difficulty / exchange rate correlation more closely (although it's not perfect either). Plus I had better than average luck recently, which won't last forever.

I believe than over long term a good multipool will outperform Doge or LTC. Although my own charts are proving me wrong at the moment, I think it's just short-term variance.

To be honest I don't know of a good Doge pool to recommend, which is part of a reason I'm running my own node. Not having to pay any fees is a nice bonus. MH/s doesn't really matter if you're in for the long run, but anything less than 2-3 MH/s might be boring during the less lucky periods.

Removed GHash multipool. The website was down at the time when I needed to collect stats, which made the decision easy. It's been underperforming anyway.

And yes, that is Doge going to the moon. Or at least its exchange rate is, 30% up since Monday.

Just as yesterday I'm still on my 72-hour lease on LeaseRig, while the current rates have doubled to ~0.011.

UPDATE www.wafflepoolmonitor.com :

Due to a bug in code, the graph would jump showing incorrect past values for hashrates and balances, also for some non regular miners on this pool past values would flatline at 0. The bug has been corrected and no such error should be seen now on.

hi, it happens when wafflepoolmonitor is not able to get the data through the api from wafflepool for a address. The values are set as 0 leading to spikes.It is a temporary issue and should be resolved soon.

You used 1B49qTqGUm6ukgNhzv7YNEdnj3h5k4JKoj instead of 1B49qTqGUm6ukgNhZv7YNEdnj3h5k4JKoj when connected for the first time and this is how your username was created. This was an invalid BTC address so payouts weren't made. I just renamed it and you should expect payout today.

Sorry about that. Some kind of glitch at Google. The chart works ok in my editable spreadsheet (that's how I made the screenshot for the OP) but for some reason breaks when the spreadsheet is published. I'll try to fix it tomorrow.

workers hash rate falling its almost 0 with all my rigs, whats happening? but yet all my rigs are still mining

Scripta does not really work with gridseeds if you have more than a couple it keeps dropping the miners

IMO 25 MHz increments work the best, one of my miners runs stable at 925 MHz, but throws HW errors at 856 MHz. The 25 MHz increments have the lowest PLL frequency and other PLL dividers set at 0. I have also found that the cgminer forks does not take in account the hashing time lost when finding an invalid nonce (HW error).

The example on the main page indicates that you can pass an optional dif value as the password. But one of the features listed in this announcement thread is automatic difficulty adjustment.

So is the example obsolete and there is no need to specify difficulty via the password? If not, and specifying difficulty is recommended, is there a guideline for the dif value per MH/s?

Thanks in advance.

That's "the whale" (sfire on these forums).  He has about 10-12 GH of GPUs and Gridseed miners and he jumps around the multipools according to what's trending higher.  You usually seem on Clever, Waffle and a few others, but he got his start on Middlecoin.

I'm still seeing disconnects where after running for a while units disappear and are rediscovered. I'm on a Raspberry Pi running 10 GS units with the girnyau version of cgminer that I built from sources, plus Scripta as the web front end. Most of the units are on an Orico P10 U2.

After a disconnect, the device always reconnects a couple of seconds later. This leaves a "zombie" in the API because cgminer doesn't mark the device's status as dead. Sometimes more than one device at a time disconnects.

Here's an example of a disconnect from the log:


The errors are *always* in the "prepare_work" method of the driver. In the sources, the function name is gridseed_prepare_work. I never see any other USB errors in the log. I've reviewed the various Linux system logs but don't see a correlation to the problem there.

When this error happens, the thread associated with the device exits. But the code doesn't mark the device as dead. That, in combination with the way that Scripta detects "live" devices by verifying that the last 5 second hash value is non-zero, results in irritating and bogus device info and hash rate totals in the web front end.

I don't have a spare 10 port hub, so I can't swap that out. I do have some poorly behaving Gridseeds that have excessive hardware failures, so I've tried further under-clocking them. But I still get disconnects.

One thing I've noticed is that all of the failures in the log are aligned on 5 minute boundaries within a few seconds. Here's the most recent ones:


Scripta has several cron jobs that run on 5 minute boundaries. Most of the cron jobs call the cgminer API for status, which should be harmless.

But the timing of these events is very suspect. I'm starting to think that there's a cgminer race condition where sometimes an API status call can interfere with the general operation of cgminer.

As a binary chop, I'm going to try disabling the Scripta cron jobs to see if the problem goes away.

If anyone else has any suggestions, I'm all ears...

this version gives me around 10% lesser hashrate then the orginal cgminer .... I did a test with 20 miners ....

I asked for it ... with PM no answer ... so far ...