<p>Do you have a high latency connection to the pool? Try run stratum and test it again. Probably from the GPU waiting for work to do as the pool switches over. Worked for me like a charm.</p>

CC BY-SA 3.0
2013-05-28T09:01:23.250Z
2013-05-28T09:01:23.250Z
sunnyshenao
<p>How long does the fall last?</p>

<p>It's so that when a pool receives a new block, it has to remove all transactions that have been removed in that new block from the pool of transactions it was trying to put in their block.</p>

<p>So what I guess happens (I never wrote or examined any mining software) is that your miner receives a notification that a new block is found and so knows that it makes no sense to continue trying to find a new block because it will contain already-confirmed transactions. It will then wait until the pool received the new block as well, pruned its own transaction pool and started again with distributing work among miners.</p>

<p>I think this process can really only take mere seconds.</p>

CC BY-SA 3.0
2013-04-26T09:24:52.177Z
nope, it lasts forever unless I restart it. a bug in guiminer or poclbm perhaps?
Dreen
CC BY-SA 3.0
2013-04-26T02:03:25.423Z
2013-04-26T02:03:25.423Z
Steven Roose
<p>Very often my mining hashrate falls from the usual ~550 Mhash/s to about 400-500 khash/s, and I have noticed direct correlation in time with messages like these:</p>

<pre><code>btcguild.com:8332 25/04/2013 10:07:14, long poll: new block 0000014d5c6c4f89
</code></pre>

<p>This happens across different pools. Stopping and starting the miner puts it back on the normal hashrate, but it means I have to look at the window 24h. I'm still very new to this but it seems like it switches to CPU mining? Why?</p>

<p>My setup is:</p>

<ul>
<li>CPU i7-3770K</li>
<li>GPU HD 7970</li>
<li>16 GB RAM</li>
<li>Windows 7 64bit</li>
<li>Guiminer v2012-12-03</li>
</ul>

CC BY-SA 3.0
2013-04-25T15:48:30.387Z
Could it be overheating? You can use a program like speccy to look at how hot it is.
Nick ODell
CC BY-SA 3.0
2013-04-25T16:16:50.177Z
My thoughts too, I have HWiNFO64 logging on all sensors so I could post some graphs. But basically it doesn't go much above 70C, maybe thats not perfect but why would it bounce down precisely when it hits a new block?
Dreen
CC BY-SA 3.0
2013-04-25T16:22:51.717Z
The actual temp data is (min/max/avg): Internal: 40/68/51 Core: 36/73/51 VRAM: 38/64/48; Obviously the temp goes way down when the hashrate falls too.
Dreen
CC BY-SA 3.0
2013-05-26T05:20:22.227Z
You're using getwork or stratum?
organofcorti
CC BY-SA 3.0
2013-05-26T13:08:14.257Z
@organofcorti: i think that was stratum, but problem actually disappeared after few weeks. Weird.
Dreen
<hash><miner-configuration><hashpower><poclbm>
Hashrate falls by factor of 1000x when now block is found?
Dreen
# Hashrate falls by factor of 1000x when now block is found?

(Asked by: username_0 on 2013-04-25)

Very often my mining hashrate falls from the usual ~550 Mhash/s to about 400-500 khash/s, and I have noticed direct correlation in time with messages like these:
btcguild.com:8332 25/04/2013 10:07:14, long poll: new block 0000014d5c6c4f89

This happens across different pools. Stopping and starting the miner puts it back on the normal hashrate, but it means I have to look at the window 24h. I'm still very new to this but it seems like it switches to CPU mining? Why?
My setup is:

CPU i7-3770K
GPU HD 7970
16 GB RAM
Windows 7 64bit
Guiminer v2012-12-03

**Tags:** hash, miner-configuration, hashpower, poclbm

> **Comments:**
> **username_1**: Could it be overheating? You can use a program like speccy to look at how hot it is.  
> **username_0**: My thoughts too, I have HWiNFO64 logging on all sensors so I could post some graphs. But basically it doesn't go much above 70C, maybe thats not perfect but why would it bounce down precisely when it hits a new block?  
> **username_0**: The actual temp data is (min/max/avg): Internal: 40/68/51 Core: 36/73/51 VRAM: 38/64/48; Obviously the temp goes way down when the hashrate falls too.  
> **username_2**: You're using getwork or stratum?  
> **username_0**: @username_2: i think that was stratum, but problem actually disappeared after few weeks. Weird.  

---

## 2 answers

### Answer by username_3 on 2013-05-28. Score: 0 | Accepted answer

Do you have a high latency connection to the pool? Try run stratum and test it again. Probably from the GPU waiting for work to do as the pool switches over. Worked for me like a charm.


---

### Answer by username_4 on 2013-04-26. Score: 0

How long does the fall last?

It's so that when a pool receives a new block, it has to remove all transactions that have been removed in that new block from the pool of transactions it was trying to put in their block.

So what I guess happens (I never wrote or examined any mining software) is that your miner receives a notification that a new block is found and so knows that it makes no sense to continue trying to find a new block because it will contain already-confirmed transactions. It will then wait until the pool received the new block as well, pruned its own transaction pool and started again with distributing work among miners.

I think this process can really only take mere seconds.

> **Comments:**
> **username_0**: nope, it lasts forever unless I restart it. a bug in guiminer or poclbm perhaps?  

---

