GPUMAX | The Bitcoin Mining Marketplace

[bitlane]

I've had to re-start a few of my miners multiple times today. What is happening with GPUMAX that is kicking the crap out of me today ?

The work que seems to empty out, communication lost, then BAM! sick card(s) in CGMiner.

I've had this happen a couple of times in the past (once every couple of days or so) but today is once an hour or more.

What's happening ?

[1713947260]

1713947260

[1713947260]

1713947260

[1713947260]

1713947260

[jjiimm_64]

I've had to re-start a few of my miners multiple times today. What is happening with GPUMAX that is kicking the crap out of me today ?

The work que seems to empty out, communication lost, then BAM! sick card(s) in CGMiner.

I've had this happen a couple of times in the past (once every couple of days or so) but today is once an hour or more.

What's happening ?

interesting....  maybe backing my clocks down may have inadvertently helped me with this issue.  I have not had ONE sick card all day.

all     5870 at 850/300
most 5970 at 775/300

I only lost about a g of hash.

[wickss]

I've been getting frequently disconnected for about a week now.  My miner will run for a while then I will get kicked off and I'll have to restart it to connect again.

[BinaryMage]

I've had to re-start a few of my miners multiple times today. What is happening with GPUMAX that is kicking the crap out of me today ?

The work que seems to empty out, communication lost, then BAM! sick card(s) in CGMiner.

I've had this happen a couple of times in the past (once every couple of days or so) but today is once an hour or more.

What's happening ?

Same issue. Work queues empty every minute or so, takes minutes to get reconnected. Works just fine on other pools. 5x 5870 @ 980/300 on BAMT. Any suggestions?

[pirateat40]

We have had a few issues moving our database around and getting things working properly.  One of the big issues/bug is when your offline pool is pointed to a dead pool it puts a huge load on the system.  We are working to fix this but its been slow going with all the other work.  The system should be working as it should now but like I've said before, this is our beta and want to thank everyone for reporting issues like this so we can get them all worked out now.

[jamesg]

We have had a few issues moving our database around and getting things working properly.  One of the big issues/bug is when your offline pool is pointed to a dead pool it puts a huge load on the system.  We are working to fix this but its been slow going with all the other work.  The system should be working as it should now but like I've said before, this is our beta and want to thank everyone for reporting issues like this so we can get them all worked out now.

This is one hell of a beta system... 

Can't wait to see what's next.

[bitlane]

We have had a few issues moving our database around and getting things working properly.  One of the big issues/bug is when your offline pool is pointed to a dead pool it puts a huge load on the system.  We are working to fix this but its been slow going with all the other work.  The system should be working as it should now but like I've said before, this is our beta and want to thank everyone for reporting issues like this so we can get them all worked out now.

Is there any way we can simply REMOVE our Pool info, so that when there is no Leased Work to be done, our miners are free to connect directly to our backup pool rather than via proxy ?
I just find that my speeds suffer when doing so as well as an overall increase in Stales/Rejects etc.

Could this be a possibility ?

[pirateat40]

Update

Starting now, anyone that has a "Dead" pool as their offline pool will have their connection to GPUMAX blocked when we go to private work.  So please change your offline pools settings to a pool that is running.

Thanks,

[pirateat40]

We have had a few issues moving our database around and getting things working properly.  One of the big issues/bug is when your offline pool is pointed to a dead pool it puts a huge load on the system.  We are working to fix this but its been slow going with all the other work.  The system should be working as it should now but like I've said before, this is our beta and want to thank everyone for reporting issues like this so we can get them all worked out now.

Is there any way we can simply REMOVE our Pool info, so that when there is no Leased Work to be done, our miners are free to connect directly to our backup pool rather than via proxy ?
I just find that my speeds suffer when doing so as well as an overall increase in Stales/Rejects etc.

Could this be a possibility ?

No, our failover support coming will handle these type of issues.

[bitlane]

No, our failover support coming will handle these type of issues.

The only reason I am asking is, I am having a difficult time seeing the benefit of introducing another point of failure into the equation.

I use the same Pool for my GPUMAX Public Pool, as I do for my locally set backup pool in CGMiner and I see this quite a bit:



Even when GPUMAX is sending work via the single proxy account (worker#6) connection issues etc still send work to my (workers #1-5) locally setup backup worker accounts.

I figured it was worth mentioning.....

[jamesg]

No, our failover support coming will handle these type of issues.

The only reason I am asking is, I am having a difficult time seeing the benefit of introducing another point of failure into the equation.

I use the same Pool for my GPUMAX Public Pool, as I do for my locally set backup pool in CGMiner and I see this quite a bit:



Even when GPUMAX is sending work via the single proxy account (worker#6) connection issues etc still send work to my (workers #1-5) locally setup backup worker accounts.

I figured it was worth mentioning.....

If you are using cgminer without the --failover-only switch, the software will automatically leak shares to your backup pools....

[DILLIGAF]

No, our failover support coming will handle these type of issues.

The only reason I am asking is, I am having a difficult time seeing the benefit of introducing another point of failure into the equation.

I use the same Pool for my GPUMAX Public Pool, as I do for my locally set backup pool in CGMiner and I see this quite a bit:



Even when GPUMAX is sending work via the single proxy account (worker#6) connection issues etc still send work to my (workers #1-5) locally setup backup worker accounts.

I figured it was worth mentioning.....

That is normal spill over I see using cgminer there is always the odd share or two it submits. Now if I mine deepbit next to nothing gets by it so it would be smaller than you see there, but any other pool there is 50-100MH/s spillage all the time to my backups.

[BTC-engineer]

At the moment my miners have bigger problems with gpumax.

Connect
about 0-10 accepted shares
1 rejected share
Disconnect
Starting from beginning

This results in a effective hashrate of about 40-60%. After pointing the miners directly to the offline pool the problems disappear.
I will check from time to time if the problem still exists. 

[BurtW]

Paid purchase pending for 8 hours.

[pirateat40]

Paid purchase pending for 8 hours.

Yea we don't start purchases when we are sleeping. We are starting up shortly.

[BurtW]

You sleep?

[pirateat40]

You sleep?

I know, I'm sorry.

[filharvey]

Ah so purchases are not automatic? In which case what times are u usually up? As I had a purchase waiting for quite some time yesterday.

But I must admit the service is good. I'm making some good returns.

Phil

[pirateat40]

Ah so purchases are not automatic? In which case what times are u usually up? As I had a purchase waiting for quite some time yesterday.

But I must admit the service is good. I'm making some good returns.

Phil

Yea the system is not automatic yet so we run purchases from 9am to 11pm CST.

[filharvey]

Once it is automatic, are you going to display a wait time for purchases to kick off, if there are others in the queue?

Phil