GPUMAX | The Bitcoin Mining Marketplace

[smickles]

Wow.. sooo....

Whats the going rate?

I got two miners on it so far.. this is interesting..

I'll tell you for 10 btc.....   

i'll tell you for 9 ;P

[1713586939]

1713586939

[1713586939]

1713586939

[1713586939]

1713586939

[notme]

I'll tell you for 160,000 shares to the miner of my choice.

[pirateat40]

I'll tell you for 160,000 shares to the miner of my choice.

*pool

[notme]

I'll tell you for 160,000 shares to the miner of my choice.

*pool

right, pool

[rjk]

I'M NOT TELLING, I'M NO SNITCH!

[teflone]

Got my invite, and got a couple cards on this..

Looks fun, still learning..


But it seems down right now..

I was connected for a while there..


Correction, its back up..

[pirateat40]

Yep, more of the same guys.  We are moving as fast as we can to the new system but until then its touch a go here.

[pirateat40]

Update:

Our old DC is doing an upgrade to their routers to address the issues we've been having.  GPUMAX will be down from 9:30PM to 1AM CST while they upgrade and configure the hardware.  We can't tell you how sorry we are about having to take the system down for this long.  Hopefully it's faster but we'll expect it take that long or longer.

We wish we could migrate during this time to our new system but I don't think it's possible.  I recommend everyone to setup a fail-over to their offline pools so you don't have much downtime.

If you have a purchase in the system during this time it will be suspended until the system comes back up or if you wish you can contact me or support@gpumax.com to have a refund issued.

Thanks and we'll see you on the flip side.

[phorensic]

What is it about bitcoin mining that seems to kill every server and every router that handles the traffic? lol

I mean seriously, if you run a Cisco router you don't update it to handle bitcoin traffic...you don't update it for virtually anything ever.

[bitlane]

Update:

Our old DC is doing an upgrade to their routers to address the issues we've been having.  GPUMAX will be down from 9:30PM to 1AM CST while they upgrade and configure the hardware.  We can't tell you how sorry we are about having to take the system down for this long.  Hopefully it's faster but we'll expect it take that long or longer.

We wish we could migrate during this time to our new system but I don't think it's possible.  I recommend everyone to setup a fail-over to their offline pools so you don't have much downtime.

If you have a purchase in the system during this time it will be suspended until the system comes back up or if you wish you can contact me or support@gpumax.com to have a refund issued.

Thanks and we'll see you on the flip side.

You need to set speed thresh holds......to force miners to failover on their own and not simply to PUBLIC work if no CONTRACT work is available.
As it seems, my miners are more than happy to stay connected to GPUMAX even at 50% speeds and NOT failover to my backup pool.
Waking up to find that I wasted a bunch of electricity while I slept is rather discomforting......
My setup is rather small right now and I know what it produces every minute with tons of backup data to support it.

As of posting this, my backup pool had reported NO CONNECTION in the past 15+ hours to the worker set as my 'Public' worker in GPUMax, nor have my backup workers accumulated anything significant, so where do I point the finger ?
(CGminer - latest version, Win7 x64, multiple months of stability on same hardware with monitoring stats)....

[imsaguy]

You need to set speed thresh holds......to force miners to failover on their own and not simply to PUBLIC work if no CONTRACT work is available.
As it seems, my miners are more than happy to stay connected to GPUMAX even at 50% speeds and NOT failover to my backup pool.
Waking up to find that I wasted a bunch of electricity while I slept is rather discomforting......
My setup is rather small right now and I know what it produces every minute with tons of backup data to support it.

As of posting this, my backup pool had reported NO CONNECTION in the past 15+ hours to the worker set as my 'Public' worker in GPUMax, nor have my backup workers accumulated anything significant, so where do I point the finger ?
(CGminer - latest version, Win7 x64, multiple months of stability on same hardware with monitoring stats)....

I'm not blaming gpumax or cgminer, because I dont know what caused it. I can verify that cgminer will sit there and continue to connect/disconnect from gpumax and not actually fail over to a different pool.  This dc move was a prime example.  Had I not gone and manually disabled gpumax, the miners would have sat there idling.  Win 7 x64, with a mix of 2.2.3 and 2.2.1 cgminer.

[siggy]

You need to set speed thresh holds......to force miners to failover on their own and not simply to PUBLIC work if no CONTRACT work is available.
As it seems, my miners are more than happy to stay connected to GPUMAX even at 50% speeds and NOT failover to my backup pool.

I've noticed this with CGminer also.. not quite to the extent above, but definately there..

Would it be possible to give us miners an option to have GPUMAX simply disable workers when no public work is avaliable at that worker's pricepoint?  Let us worry about our own fail-overs when no public work is avaliable.  This could be something as simple as changing the worker's password to "no_work" when it needs to be disabled, and change it back when life is good...

Granted you'd still be getting some traffic with the periodic re-connect attempts, but I don't think you'd be seeing as much as if you were passing through hashes ... I see this as a win-win.

dats my 2 satoshi's take on this

Sigg

[joulesbeef]

how do I get an invite to get on this thing?

[bitlane]

Would it be possible to give us miners an option to have GPUMAX simply disable workers when no public work is avaliable at that worker's pricepoint?  Let us worry about our own fail-overs when no public work is avaliable.  This could be something as simple as changing the worker's password to "no_work" when it needs to be disabled, and change it back when life is good...

I like the above idea.
Adding an additional 'bridge' point of failure doesn't really make sense, passing through shares.

Right now, I am sending 4 workers @ 4.8GH/s to GPUMAX and I only connect to 2 places, regardless of the situation.
My GPUMAX 'Public Pool' and my locally set 'Backup Pool' are 1 in the same (BTCGuild) as it's stable as shit and I never have to worry about it (my backup pool) yet my STALES/INVALIDS are always greater when passing through work using my single GPUMAX managed 'Public' worker, compared to my directly connected 4 backup worker threads sent to BTCGuild.

I really like the service, but I can manage my workers well enough on my own and would rather just have the option to connect to GPUMAX when Contract work is available.

My 3 satoshi's take on things....lol

[pirateat40]

Update

Well we did it, we've moved to our new DC and did a few updates while the site was offline.  

Enjoy,

[imsaguy]

Update

Well we did it, we've moved to our new DC and did a few updates while the site was offline.  

Enjoy,

Coming soon! It has come!

[Bananington]

how do I get an invite to get on this thing?

Go to GPUMax.com and sign up for an invite. It took me about a week to be invited.

Which I appreciate!

[pirateat40]

Update:

Our old DC is doing an upgrade to their routers to address the issues we've been having.  GPUMAX will be down from 9:30PM to 1AM CST while they upgrade and configure the hardware.  We can't tell you how sorry we are about having to take the system down for this long.  Hopefully it's faster but we'll expect it take that long or longer.

We wish we could migrate during this time to our new system but I don't think it's possible.  I recommend everyone to setup a fail-over to their offline pools so you don't have much downtime.

If you have a purchase in the system during this time it will be suspended until the system comes back up or if you wish you can contact me or support@gpumax.com to have a refund issued.

Thanks and we'll see you on the flip side.

You need to set speed thresh holds......to force miners to failover on their own and not simply to PUBLIC work if no CONTRACT work is available.
As it seems, my miners are more than happy to stay connected to GPUMAX even at 50% speeds and NOT failover to my backup pool.
Waking up to find that I wasted a bunch of electricity while I slept is rather discomforting......
My setup is rather small right now and I know what it produces every minute with tons of backup data to support it.

As of posting this, my backup pool had reported NO CONNECTION in the past 15+ hours to the worker set as my 'Public' worker in GPUMax, nor have my backup workers accumulated anything significant, so where do I point the finger ?
(CGminer - latest version, Win7 x64, multiple months of stability on same hardware with monitoring stats)....

If your miner is running at 50% speed then you have something else going on.

[bitlane]

If your miner is running at 50% speed then you have something else going on.

Let's take one of my miners, as an example. A quad 6950 rig that does a steady 22+ shares/minute and does so continuously.
It will stay connected to GPUMAX and struggle to maintain 16 shares/minute, so perhaps 50% was hyperbole.....regardless.

I can watch this happen in real time, using my monitoring app to switch pools manually.....
Connecting to BTCGuild, my shares/minute seem to skyrocket, switching back to GPUMAX has a near immediate 20+% negative effect at times on shares/minute.

Knowing this setup better than I know my wife these days, it's easy to see performance issues and know that nothing on my end is causing them, due to stellar performance elsewhere.

[siggy]

I can watch this happen in real time, using my monitoring app to switch pools manually.....
Connecting to BTCGuild, my shares/minute seem to skyrocket, switching back to GPUMAX has a near immediate 20+% negative effect at times on shares/minute.

bolded what is for me, the most important item in the above..  when doing public work, I fly, when doing private work, I usually fly .. but there are some times when private work gets a lot of disconnect/reconnect resulting in reduced performance .. I just assumed this was a side effect of going through a proxy.  the benifits still far outweigh the penalties, so i just live with it..  

Sigg