Deadline exceeds limit, but it didn't

Hello,

Been Burst mining for a few months. The odd issue along the way but generally it’s gone fine. However today I’m experiencing a problem I haven’t been able to find a solution to so far so I decided to register here and ask. Hopefully some one can help me out.

I’m mining with just under 10TB using Blago miner. I’m getting “[ERROR 942682161] deadline exceeds deadline limit of the pool” which is fairly self explanatory and searching for it confirms that the pool is rejecting the deadline because it’s too long. But the thing is the deadlines I’m submitting aren’t too long. I’m using the 0-100 cryptoguru pool and their max. deadline is 1 year. My miner has just submitted a 37 day deadline and received the same error message so I’m at a loss as to what’s going on here.

I even forged a block a few days ago so it was working fine then.

I’ve rebooted the mining rig but that hasn’t helped at all. I’ve got Connection 100% showing so it’s not that either.

Please can any one offer any suggestions as to the issue here and how to fix it?

Cheers, Mike…

1 Like

I’m having the same issue, just started this morning.
0-100-pool.burst.cryptoguru.org
Blago miner v1.170820_AVX2

I could understand a few deadline errors, but I’m not able to submit anything valid right now.

Thanks, Paul

I noticed that my last active blockheight was 501999, so I figured that I needed to update the miner for the recent changes. Now I’m running v1.170911 and everything is working again.

1 Like

Hi Paul,

Where did you get 1.170911? I can only find 1.170820 on Github.

Please can you let me know?

Cheers, Mike…

Hi,

Ignore my last. I’ve found it and it resolved the issue for me too. Thank you for pointing me in the right direction.

As a newly signed up member I can’t post links so I can’t put it in here for any one else searching but it seems that newer versions of the miner have moved to somewhere else on Github. Just search for “blago miner 1.170911” and you’ll find it.

Cheers, Mike…

1 Like

You are welcome. I used Qbundle to pull down the latest version.

You will notice that your read times will double with the newer version. This is where you will want to start converting your plot files from POC1 to POC2 in order to get your speed back up.

Here is one tool to do the conversions in place. I’m experimenting with it right now.

Here is the start of a good write up:

2 Likes

Ah, that’d explain the “(POC1<>POC2)” thing then. Had a suspicion that’s what it meant. Thanks for the links, I’ll look into those.

Cheers, Mike…

Hmmmm, that’s not what I expected. I’ve converted one of my discs to POC2 plots and it’s now 4 x slower than before. The remaining 6 POC1 plotted discs scan at their previous speed. I expected, from the above article, it to be faster than before. I’m rather hesitant to convert the rest now. I’m wondering if the miner doesn’t like mixing POC1 and 2 discs so when they’re all converted they’ll become faster. If that’s not the case then there doesn’t seem much point in converting. Will POC1 plots stop working completely at some future date?

Cheers, Mike…

If you are using POC1 right now, the miner literally has to read the data twice in comparison to POC2 so it should be faster to read POC2.

I don’t see how POC1 will ever stop working unless it’s written out of a future version of Blago. The data is essentially the same, it’s just repositioned to read faster and to prevent the time-memory trade off exploit.

Take a look at this if you want to know more about POC2.
https://www.burstcoin.ist/2018/03/01/poc2-explained-a-needed-security-upgrade/

Once you have your head round POC1 and POC2, POC3 will be on the way :grinning:

Have you been able to see if that is the case when you are mining a round with just that PoC2 plot? (4x slower)?

@TaxCollector thanks for the link, I’ll try and get round to digging into that a bit.

@ryanw I was perhaps a little hasty there, it is taking longer and showing 4 x less MB/s on the POC2 plot reads, but what I failed to notice before was it is using /significantly/ less CPU % so I’m hoping/expecting to see POC2 reading faster (as it should, as TaxCollector said) once all plots are converted. I’m guessing the CPU cycles freed up by the POC2 plots are being devoted to the POC1 plots so I’m not seeing any speed up yet. That’s my theory any way. I’m still working on converting the rest of my plots. I’ve completed 2 x 500GB drives and 1 x 1TB drive. Currently working on a 2TB drive, that’ll be running overnight now. Would probably convert faster if I pulled the drives out of the machine one by one and converted on another machine that wasn’t mining but I don’t want to do that.

One thing I have noticed, I seem to be finding a lot more valid deadlines than I was before. I suppose that could be if lots of capacity has been taken offline for conversion?

Any way, I’ll convert the rest of the discs (another 2TB, a 3 and a 1.5) I have and see how it goes. Hope you all do well too.

Cheers, Mike…

1 Like

I’ve only got another 6 hours left on my first WD USB3 8TB external.
I’ll be happy to mine for 30 minutes with just that drive and then another identical drive that is still POC1 and compare the read times using the latest Blagominer.

I’ll post back my results.

Something that might help external drives is to make sure that the one that you are converting is on its own controller and your drives being mined are on a different one. It’s quite a lot of I/O during the conversion, but better than replotting from scratch.

Paul

Also, read speed is important, but if you are finishing the block before the next block comes out it is less important.

1 Like

You could take the links to your POC1 plots off your config, then run the miner with only a converted POC2 plot.
See how that works, then add the POC1 plots back in and carry on as you were until the rest are done.

That way you can be sure it’s going to do what you hope before you spend time converting the rest of the POC1 drives.

@MasterMC That would be interesting to see.

1 Like

@Burst_Mike Yeah the net difficulty has gone way down since POC2. It’s great! :+1:

1 Like

Hi all,

I’m using all internal drives for now, was the most economical way for me to get started with Burst mining. I’ve been moving a plot file to a “Temp” directory to convert so I don’t have to mess with the miner config file and it means I’m only one file down for mining at a time. Except over night when I took a whole load down so as not to have it idle from a converting point of view for too long.

Good news on the difficulty, hopefully we can mine some good coin whilst it’s down.

@MasterMC I’d be interested to know your results of that too. Thank you for offering to post the results.

Cheers, Mike…

1 Like

I started converting another drive, but your comment and devotion have made me want to really do a test. Give me another day and I will post results.
Thanks,
Paul

1 Like

Ok, so I am running Blago v1.170911 in AVX2 mode on a Ryzen 1500x with 8GB RAM and comparing 2 USB3 external 8TB WDs. 1 converted to POC2 and the other still at POC1.

First test was running just against the newly converted drive and I was seeing 136.21 MB/s consistently with each new block (or a restart of the miner to redo the last block).
Then against only the POC1 drive and I was getting 65.37 MB/s read speed. So, yeah, that is about half using a new miner with an old plot file.

For fun I ran it again using both drives in the config and while it started out at 240 MB/s (being multi-threaded I would expect it to add the two drive read speeds together, until it finished with the POC2 drive (which is twice as fast), and then the MB/s dropped down to about 130 MB/s by the time it was done. (I’m not sure of the actual math, but it kind of makes sense.)

Just to double check what I used to get I ran Blago miner-v1.170820_AVX2 against the POC1 drive and it showed my old rate of 126.24 MB/s.

In summary the new miner with new plots is about 8% faster than the old miner with old plots. And a new miner with an old plot is half as fast. So get those conversions running.

1 Like

Thank you for taking the time and effort to run those tests, very interesting and encouraging.

An update on mine. It almost seems like there is a tipping point because the read speeds of my POC2 converted drives seems to be going up a bit, still slower than the POC1 drives. Not as much as before but still slower. As an example, my J: drive is POC1, 1.5TB and reads in 13 seconds. My F: drive is POC2 and 1TB yet takes 13.5s to read. However, more interesting, I think, is the CPU usage. J: is using 65.57% and F: only 28.72% and considering it’s a dual core Celeron in that machine lower CPU usage has to be better.

I’m half-way through converting the 3TB drive and then there’s the 1.5TB drive to do and I’ll be all converted then. Will post back with numbers when they’re all converted.

Cheers, Mike…

1 Like

Thanks for the tests @MasterMC.

@Burst_Mike, I have all different brands and sizes of disk… I find read times all over.
I’m assuming multiple plot files vs one big plot file would be slightly different also.
Maybe the number of platters in the drive and the size of those platters (density) would also play a part.

I’m sure you’re right, all of those things do play a part, although unless any of them are extreme values I’d think the impact would be small.

My biggest concern now is that one of my plot files has become corrupt. Of course it’s on my biggest drive, the 3TB. I mapped out the bad sectors on that drive before I started mining, looks like they’re breeding :frowning: I’d never normally buy a 2nd had HD but for mining it’s okay, these things will just happen though. Only way I could afford a drive that size. My mining operation is very much shoe-string.

The Turbo Plotter 9000 plot checker shows 5 or 6 red blocks at the very beginning, does any one know if that means the whole plot is unreadable now or just the data contained in those blocks? If it’s just those few I may leave it be rather than re-plotting a 255GB file on a dual core Celeron! Don’t really want to pull the drive to plot on my main machine with a GTX 1060 in it if I don’t have to.

Cheers, Mike…