Read-only forum archive. PROHASHING has closed. Posting, registration, and account access are unavailable. Preserved from the April 3, 2026 server backup.
Steve fixed the website this morning. We still don’t know what caused that issue, but restarting the web server fixed it. For the solo mined coins, I have updated the forum post with more information.
CritterDog wrote: Under rejected shares I found this message?? Miner is using an incorrect algorithm. 1 I have never change miners so why would I get this message
Are you getting it frequently? The mining server throws the error if the data submitted is not able to be verified as a scrypt hash.
CritterDog wrote: Under rejected shares I found this message?? Miner is using an incorrect algorithm. 1 I have never change miners so why would I get this message
Are you getting it frequently? The mining server throws the error if the data submitted is not able to be verified as a scrypt hash.
No just one share and now it’s gone. I never seen that before. But it seems fine now
gnode wrote: Block Explorers are down as of 5:15 AM ET
I took the updating offline as I am resolving corruption in the block explorer tables in our database. I’m not yet sure whether I can fix it or if I’ll have to reindex everything, which would take a few days.
Unfortunately, I think that’s a bug in the live statistics. Steve says that it is counting miners and hashrate multiple times when multiple workers use the same name. He is going to fix it sometime soon. It only affects the live stats though; all earnings and historical statistics are correct.
Good catch - that is a mistake, and I corrected it. That said, Monero transaction fees are the second highest of any coin we offer (only Dash is higher) which is why we have the high payout threshold for the coin.
I think it was the name change of workers that knocked me off.. I thought we were good as long as the names were diff on each miner. This was not real clear but it looks like we must change names every time we reboot? I lost half my miners until I gave them a new name
The reconnecting miners are causing high CPU load on our servers though since they don’t close the previous connection when they reconnect. That’s why it seems like there’s so many workers.
Yeah I don’t see any problem there. I am back up all looking normal but I did need to give a new name to workers.. As long as I know thats what I have to do no problem if it helps on your end be more stable or better profits
Guys is there any chance you can run some testing on your dev box before making these changes? I’d be happy to point a miner at your dev address for a few hours if you’d like to test these chnages before deploying into prod.
We do test these changes, but a misunderstanding of the cause was the fault here. We thought that the excess connections were caused by people with BFGminer because BFGminer creates a connection to every pool in its list but only submits shares to the primary pool. Instead, it was the A4s frequently rebooting and creating new connections each time. Was that a new firmware update that does this? A4s have been on the pool for a while and this only recently occurred. It's these miner-specific bugs that get us because we don't have every hardware configuration to test before release, so it seems inevitable that some configuration will have problems.
Figures it was the A4s.. I have seen sometimes on reboots a duplicate worker but the duplicate would go away after a bit. Only one of the 2 would submit shares though. The reboot option was added in one of the upgrades. It really is no improvement because usually you get dropped cards which require a power down cycle
hi A4 owners, my batch has the latest firmware v.201 and would like to try it out here. So far so good on pure LTC mining only and solo LTC. Over here and NH and elsewhere multi-coin switching - the A4 is all over the place but instead of dropping boards like batch 1 and 2, it just restarts everytime a new coin is mined. So I guess maybe a special port for A4s with longer switching delay timing perhaps? Comments?
All the x.x.3 versions of the firmware have a monitor which forces a hard restart. From my experience, the way to avoid the cards not restarting is to give the miner more Mv. This cures the problem for Batch 2. For batch 1, I still need to occasionally power them down at the switch and restart. Not sure what happened tonight but I tried to mine a single coin (still using static diff) and it was ok for a couple of hours but then poolside Mhs crashed. Have moved to CM for the rest of the night (10.30pm here), will check pool status again in the morning.
citronick wrote: hi A4 owners, my batch has the latest firmware v.201 and would like to try it out here. So far so good on pure LTC mining only and solo LTC. Over here and NH and elsewhere multi-coin switching - the A4 is all over the place but instead of dropping boards like batch 1 and 2, it just restarts everytime a new coin is mined. So I guess maybe a special port for A4s with longer switching delay timing perhaps? Comments?
Does that mean that the boards restart every time a new block comes in on an LTC-only pool?
vinylwasp wrote: All the x.x.3 versions of the firmware have a monitor which forces a hard restart. From my experience, the way to avoid the cards not restarting is to give the miner more Mv. This cures the problem for Batch 2. For batch 1, I still need to occasionally power them down at the switch and restart. Not sure what happened tonight but I tried to mine a single coin (still using static diff) and it was ok for a couple of hours but then poolside Mhs crashed. Have moved to CM for the rest of the night (10.30pm here), will check pool status again in the morning.
When did you have the problem? Read the "important mining server release" thread and see if that was around the time.
vinylwasp wrote: All the x.x.3 versions of the firmware have a monitor which forces a hard restart. From my experience, the way to avoid the cards not restarting is to give the miner more Mv. This cures the problem for Batch 2. For batch 1, I still need to occasionally power them down at the switch and restart. Not sure what happened tonight but I tried to mine a single coin (still using static diff) and it was ok for a couple of hours but then poolside Mhs crashed. Have moved to CM for the rest of the night (10.30pm here), will check pool status again in the morning.
When did you have the problem? Read the "important mining server release" thread and see if that was around the time.
i thought it was after this time but then I always forget you’re 16 hours behind me. It happened around 8pm my time Wednesday which would be 2am EST Wednesday. Does that conincide with your change window?
The only thing that happened around that time is that I had to restart the mining server, but there were no changes in the code compared to before the restart. About 8 hours before that we had the unsuccessful release, which I reverted. So the mining server code is the same as it has been for the past week.
Chris Sokolowski wrote: The only thing that happened around that time is that I had to restart the mining server, but there were no changes in the code compared to before the restart. About 8 hours before that we had the unsuccessful release, which I reverted. So the mining server code is the same as it has been for the past week.
That must have been it Steve. I just happened to be watching it and thought it was related so moved them to play it safe. I’ll give the c=gamecredit another run later. Trying to see if staying on a single coin has that much affect on my profits. I can see that some of the profitable scrypt coins have less that 1 Gh networks which is probbaly why I sometimes see my miners mine them for a second or two and I’m trying to workout if those short term coin switches are worth the downtime they cost in terms of card restarts. TBH, you’ve got all the data across all A4 miners so can probably answer that better than I can.
vinylwasp wrote: One other thing, per miner stats are taking a long time to appear. Most of my miners have been sittings on ’calculating hashrate’ for over an hour.
My A4 does the same thing..It always says calculating hash rate if I set to mine just one coin
Ok, it’s done it again, my poolside hashrate has dropped to less than 10% of it’s normal rate. I’ve never seen that happen before even when the cards are flapping like wild. The only way I can imagine this to be ok, is if all the miners have restarted at the same time, and that’s never happened before.
I haven’t found any connectivity problems between our servers and the internet. I am looking to see if the mining server is doing something unusual. The per-miner status would show "calculating" hashrate if the miners kept reconnecting and didn’t have enough shares on one connection to calculate a hashrate.
I’m making a change right now. The disconnections seem to have started around the same time as I had to reindex all the block explorers. I wonder if some system overload is causing the problem. I’ve been monitoring system resources and I don’t see anything overloaded, but I’m going to reduce the speed of indexing to see if it makes a difference.
Steve Sokolowski wrote: Thanks for these bug reports. Chris will look into the issues and get back to everyone soon.
If you have any of your system involved in the re-indexing on virtualised infrastructure, remember to watch the hypervisor/host resources more closely than the guests, especiially disc I/O on those big DB jobs. SSD’s generally help read speed more than write too..
Everything we run is virtualized, but as far as disks, the database and each of the coin VMs have their own dedicated RAIDs of SSDs. I’m not sure it’s virtualization as much as just one process overloading the database. That said, the number of connections is still an issue, even if it isn’t affecting performance.
Chris, my feedback is that the pool seems to be the most stable I’ve seen. My A4 miners are humming along at the best average hashrates I’ve seen them run at over 24 hours and profits are back to normal or better even. Whatever you did to throttle the re-indexing job seems to be doing the trick. Cheers
And since the server update i found nothing... 1 day before update i have many luck and found at Diff 3000-4500 whole 6 blocks (6.12). day after 2 Blocks (7.12) and since 50hours nothing...