Topic: [1200 TH] EMC: 0 Fee DGM. Anonymous PPS. US & EU servers. No Registration! - page 175. (Read 499811 times)

Hmmm... I'd refer you to BurningToad's comments re: poolserverj and arsbitcoin.com. I'm an old Mac Ach forum guy (as in back in the G4 days) so went with arsbitcoin after MMC closed their doors due to terrorist threats (regardless of arsbitcoin not being formally associated with ars technica, etc.) and it appears that poolserverj requires a fair amount of keeping on top of.

Let's put it this way - I wish them the best of fortune (because BT seems to be dealing with external issues that are of a higher priority) - but my miners were running at an average of 2-3 GH/s - and that's *with* me watching like a hawk and restarting miners when necessary. BT admitted that poolserverj and other software locked up after a while (memory leak sounds normal) and needed restarting, which he didn't always get informed of.

Fair enough if external issues are the main priority. But your system is clearly stable as a rock, and if the flakiness of arsbitcoin was down to poolserverj... I'd rather you not bother unless you are satisfied that it meets your currently (obviously very high) standards.

To me - I don't care about the actual technology / language used to run the pool server - only that my electricity bill represents accepted work from the pool, and that my miners aren't sitting there 20% of the time burning kilowatts but with no work from the pool.

I'm sure that you won't deliver a half-baked solution though - doesn't look like your style. Let us all know if old configs like mine (11.04 ubuntu natty minimal, 11.6 catalyst, 2.4 APP SDK, 1.50 phoenix, various phatk kernels and a load of really shoddy catfish scripting in ruby and bash) are potentially going to be unsupported though. I've trialled the latest (AFAIK) phoenix - 1.62 - and it works but doesn't offer any performance improvements to me, nor does it change the crazy monster-stdout verbosity (I redirect phoenix output to a file and then use that to extract performance statistics, after a week it's over a gigabyte per instance), so I haven't bothered updating globally.


OTOH - my aim with the Linux Minimal build isn't to try to do any better than you - your guide works and is perfect for anyone who has 10 minutes or more shell experience. Mine is just an attempt at giving something back - all my homebrew code that starts up and stops arbitrary numbers of phoenix miners on each rig (mine tend to have 4 GPUs per logic board, but there's no limit other than ATI's), and periodically updates an html page with formatted data for each instance. Consolidating the instances to one webpage (as I do) is left to the user - it's tricky on OS X Server due to various idiosyncrasies of the apache version used, but really it's just a question of linking the HTML from each mining rig into one webpage. It works with SSI but obviously you need to be careful with security - it's simple data though with no scripting other than 'include' for each miner instance's table rows.

It won't be for everyone, but after installing my miners on full Ubuntu Desktop installs with all the patches, I was wondering why the hell I needed compiz, apparmor, and a load of fancy GUI eye candy (that *does* affect the 'first' processing GPU). I'm henceforth working on trying to get a happy, compatible miner build that starts with the Ubuntu Minimal installation. I've got a couple of GH/s lying idle whilst I faff about - hashing power that should be working for the pool - so I'm on the case...

All of my scripts are commented to hell (as has always been my style) and your guides are cited and credited, but I'll run my proposed release past you beforehand. After all, they're all effectively the same, it comes down to whether you download source and compile, use apt packages, downloaded deb packages, and/or tarballs that used to be hosted somewhere but aren't anymore. I will probably get the security-paranoid jump down my throat for potentially distributing malware... so I'll probably end up having to provide MD5 hashes for the recommended binary / deb downloads. Now AMD require a questionnaire to be answered in order to download a non-current (e.g. 11.6, which works) proprietary driver, it's not a question of scripting wget any more. And expecting new Linux users to play AMD's silly games is too much - though I'm sure that if I host the entire dependency file group (including ATI drivers) then I'll get aggro for distributing copyrighted material... sigh...

Does anyone have a feel for how double geometric scoring affects round size based variance?

Out of interest, have you compared your average payout/share to a theoretical prop payout/share for the same round?

If anyone's not sure what I mean then just pick a previous long round and divide payout by your submitted shares. Then divide the Difficulty for that round by the total shares for that round (theoretical proportional pool payout). Compare and contrast. If you can be bothered I'd like to see the results.

You might need to compare a few sequential rounds rather than just one round. To do this, divide your actual total payout by the total shares you submitted. Then (assuming Difficulty didn't change between the rounds you are looking at) compare with (Difficulty*number of rounds)/(total shares in rounds).

damn damn damn these rounds from hell!

Hi Inaba

Nice little pool you've got here. I'm a firm believer in supporting the medium-sized pools rather than defaulting to the big players, so I've dropped my baby mining rig onto Eclipse and hope we beat the evil long blocks.

TBH, whenever I move pools, it's like a curse followed by a blessing... I join a new pool and there's immediately a 2-day block or some other evil that stops payouts for ages But after the first 'catfish turned up' long block, there are usually a load of lucky short blocks. Yes, your long block started before I dropped in, but I'm not predicting (or desiring) another big one

I hope to release my version of your Linux install - I've taken your advice re: 64-bit but the scripts will deal with either 32-bit or 64-bit; the difference is that my build is a single job that runs on 'Minimal' Ubuntu, and shouldn't break and confuse the noobs when source to python-jsonrpc or pyopencl moves from the URL in the original script. Yes, that means it's stuck on an old version of Catalyst and APP SDK - but it's one that I've tested and works on a decent variety of hardware.

Anyway I've managed to claw the catfish onto your pie chart. Excellent stability BTW - absolutely excellent. I was considering that my rig was badly set up due to regular dropouts on my previous pool. Since running on yours - everything has run at full utilisation with no dropouts - must be the quality of your infrastructure.

Impressed. Nice one. Hope to contribute a block or two in due course.

cheeeers
catfish

Thanks catfish.  There's a lot that can be done with the guide for mining in particular.  I just put together the guide for the easiest/quickest/simpliest of methods to get it up and running, but as for optimization, it's definitely not a good guide for that.

As far as python-jsonrpc - I don't think you need it anymore and if I recall, it's not in the guide.  Only pyopencl is required now.

Anyway, the pool is pretty stable unless I am poking at it with a stick, then it gets uppity... but I haven't had to poke any sticks into the pool in a while.  I do need to make some adjustments to the internals of the getwork server now that we are no longer doing proportional... it's still got the proportional code running but doing nothing. 

I'm also considering switching to Poolserverj when that is a bit more stable.  Although if it ain't broke, I shouldn't fix it.  But I always do.

Oh, nice... ok, I will see what I can do about integrating that this weekend or early next week.  Thanks for the tip!

Hi Inaba,

if you are interested, i currently use this api for exchange rates:
http://exchange.bitparking.com:8080/api/ticker

your full disclosure is threatening my bottom line inaba.....

=]

'monkey

It may be "normal" in so far as it's the going rate in Australia, but it is still utterly ridiculous.  The state of your Data Centers in Australia are like our wireless carriers here - they are crying about artificial bandwidth shortage, which simply does not exist, and then charging you for it.  Bandwidth is cheap the world over.  Australian bandwidth isn't any more expensive than US bandwidth - they all run on the same hardware.  The intercontinental links may be more congested, but this has very, very little to do with your ISPs and the Data Centers.  Traffic in and around Australia is counted towards the artificially low caps, even though the IC links are not utilized... so you're being charged a premium for this artificial bandwidth scarcity.  Our wireless carriers, and to an extent our wireline carriers are trying to pull the same thing over here, most egregiously AT&T and Comcast.

For 99% of the population, they have no idea what bandwidth capacity is (or even what bandwidth really is), but for the few people who actually work in the industry and work with the equipment, we know what a joke the whole thing is.  There is a glut of bandwidth.  The backbone in the US is at a fraction of it's current capacity and adding capacity is dirt cheap. There is no bandwidth shortage in the US or worldwide.  Anyone who tells you differently is lying or severely misinformed. The only people crying about bandwidth shortages are those that stand to make money from charging you for your usage.

It is quite normally, nothing ridiculous. This is Australia pricing, you can be sure other parts of the world had similar pricing.  Just a few years ago, my IDC only allow 20 GB/mth traffic per rack and comes at USD$800 with 1.5kVA!

This has probably been explained somewhere in the previous 50 pages of this topic, but what exactly is the prop differential?

Yep, I killed the block stats!

Meni found a bug earlier today in how shares are transferred from block to block with the DGS.  It did/does not affect payout negatively, just the calculation of how many shares you submitted for a given round.  The payment calculation is handled in a different table than the block stats display and I had mistakenly had the SQL taking the last shares submitted from the last block you mined in and putting it in the block stats table, even if you didn't mine in a block - it just kept putting the same number of shares in each subsequent block statistic.

The upshot is that everyone got paid for more shares than they submitted!  Jackpot! (Total overpayment was about 7 BTC across all blocks, so it was a fraction of a BTC per person)

Anyway, the bug is fixed now, or should be, but block stats may or may not display a slightly lower number/prop differential than expected, due to the calculation "missing" the phantom shares.  Going back to fix it would result in people getting a negative balance that I would have to fix manually, so everyone gets free BTC yay!  Your stats will show a lower prop differential boo!  In either case, though, you should be paid properly from now on... no more free rides!

While working on this bug, I also found another bug that was over calculating the amount of shares in a block (by a few tens or hundreds of shares per block) - so they were removed from all blocks as appropriate - our "luck" is actually better than has been reported... luck display should be accurate now.

If you notice something is not correct, let me know and I will look into it right away.

Are block stats messed up for anyone else?

busy busy!

=]

'monkey

Donation currently is set the same for both NMC and BTC.  I will spit it up so that you can set it individually.

As soon as I can find a reliable API for gathering the exchange rate between NMC and BTC, I will make the ability to convert available.

Please, add an option to convert NMC to BTC.

Is the donation % now taking from BTC and NMC?  It would be nice to have a separate donation for each, or a NMC donation address for the pool.

there are a limited number of big fat pipes into AU. its these international links to/from our island continent that cost,
plus the established billing structure of providers in AU - if you are on a good thing, why change? :/

there are cheaper hosts, but quality of service generally drops quicker than cost

At those prices, they better be REALLY good to you!   

I'm sure they are a good company, but their prices are insane... I suppose that's what the market is in AU though.  Someone needs to come in and provide a cheap alternative and eat all the other ISPs lunch.  How can prices be so much less here in the US?  For the same as a basic $250 package for WebInABox, I can get the saem for about $50 here in the US.

coolio

'monkey