Thanks, after the first shock the difficulty has been adapted automatically and there are practically no new dead shares. So that part is fine.

Here are 3 images - first from cgminer console, second from p2pool console and third of cointerra web console. The first two seem to be more in agreement now - I guess they all have different time window, so in average they must agree (though web console shows consistently the lowest value). However the numbers are not encouraging.

http://s10.postimg.org/fomcg5ssp/hashrates.png

well, I installed the p2pool server, but the hash-rate still varies and is mostly low (under 1T or so). The server does not look overworked. Got a lot of dead on arrival shares, but seems it adapted difficulty and it worked pretty clean since. Except for the hashrates :-/

I guess I get back to mining BTC and think about this...

Edited, what else - the hashrate reporting is quite surprising:
Terraminer web console reports about 1TH/s, cgminer (avg) 1.2-1.3Th/s and p2pool 1.5TH/s
at least the two first should agree (?), but still the difference is quite large.

I think they promised and promised and then backtracked, so only May batch should have full 2TH/s. 1.6-1.7TH/s is most you could expect today.

Thanks guys, server might be the answer, though I did not want to go there. But it looks like cgminer bombs the daemon with getwork requests that probably is not the most efficient way of handling this.

Moving the coin daemon to other machine and/or running several in "balance" mode seems to improve the speed, although it still does not come close to BTC mining rates.

I assume at these speeds there is lots of talking between miner and coin daemon going on and even slight delays in http responses from daemon accumulates and results in lost hashing power.

I'm trying to use my 1.6TH Terraminer to solo mine altcoins. It kind of works, but the hashrate is about 900G-1T. If I mine the same coin in the pool, the rate is normal (1.5-1.6TH/s)

The coin daemon is running on another machine (VM) in the local network. The network does not seem to be busy.

Any ideas what might be the bottleneck? Anything I could tweak on cgminer side or in daemon configuration?

thanks Kano, I thought I tracked it to cgminer, but was a prob in my own code :-) Great soft!

Edited: my own problem, disregard 




I've got a problem with API command addpool. It looks like it always forces username to lowercase. It looks neat, however when using P2P pools and using bitcoin address as a username this is quite a problem.

Version I'm using is cgminer 4.1.0 (embedded in Terraminer IV). I do not really dare to try to fix this on my own and recompile as it might be tricky to compile for their embedded linux.

Are there any workarounds?

what's funny is that NMC block are still found. Should not they go always together with BTC? I do not know the real mechanics, but iI see in the history of ALL blocks that they always come in pairs.
Edited: I guess I understand. BTC hash should be more "difficult", hence if we find a hash fit for BTC, it's good also for NMC, however the inverse is not true. :-/

can I kindly ask you which version are you running? I downloaded it yesterday and as far as I tell there are no later versions than 0.8.6.1; I downloaded the source code as well (and compiled Linux version that also stays on the same block); code also has not been changed yet.

Well, talking about latest changes - there is one that could affect:

-    enum { nMedianTimeSpan=11 };
+    enum { nMedianTimeSpan=13 };

The AcceptBlock() routine uses median time span to decide if timsetamp is valid or not. I assume changing it might affect certain blocks with not fully cosher timestamps.

Edited: that was it - I changed it back to enum { nMedianTimeSpan=11 }; re-compiled and it works now. Do not want to compile QT client on Windows, but at least Linux version is on the way of getting the full chain now... Thanks guys for inspiration to look around 

Definitely, that's why I'm asking - but if it is recent code fix (I looked at the latest commit and nothing there looks suspicious), or (?)

If I check peers, I see them having normal number of blocks. However for some reason they do not land in my blockchain.

When looking at log I see such entries:
2014-04-13 05:56:02 received block 44f36ca4115dae3ed9c73cf3cb10ee7deef36d0cb12477a080ee0f1db550e691
2014-04-13 05:56:02 ERROR: AcceptBlock() : block's timestamp is too early
2014-04-13 05:56:02 ERROR: ProcessBlock() : AcceptBlock FAILED

This (block 33583) looks like to be a valid block, but corresponds to the attack timeframe and therefore might contain some timestamp manipulation. Could it be that the current code denies such blocks as invalid, however historically they have been accepted and now are part of the "official chain"?

are there any problems for the new users? I cannot find anything, but yesterday I downloaded a new (seemingly latest) wallet (version v0.8.6.1-beta) on Windows 7 and it does not download past block 33582.

I also downloaded the source code and compiled daemon on Linux - same thing.

I've tried deleting data and restarting - it stick again on the same block.

Apart from this block number being in a fork abandoned during 2013 June attack, I have not found any other significance of this number. Could I be landing on the wrong fork?

I'm running a number of other coin daemons and feathercoin is the only with this kind of problem.

1) I wonder what fix? To block award algorithm? isn't that local dogecoind that assigns award? And other peers should confirm it? So unless everybody/most are on the same version nothing will change?
2) I just switched from dogechain pool to see if elsewhere there is the same problem and it looks like there is. Day after day average block times are higher than expected. And recently regularly about twice. And IMO this roughly corresponds to "less coins than calculated" problem. Having per 24h period average block lenght of 190% will result about half of earnings vs. calculation. That assuming that block-hopping exploit has negligible effect.
3) regarding the block-hopping exploit: probably something only operator can answer - does the pool has a "fair" "high reward block" distribution? Or value blocks are disproportionately mined elsewhere?
In any case I do not see how it could affect the strange trend of having disproportionate share of "long" blocks.

Unless there are many other pools who see mostly short blocks and balance out, the difficulty gets calculated wrong. If there are pools with short blocks, what are they doing differently(?) Who are they then? Is there a way to find out?

Edited:My bad. Of course average "longer blocks" in the pool will be the result of value blocks getting mined elsewhere with larger than average hashrate.