That's good, since we recently found out what happens when people leave their entire wallet on an EC2 instance!
searched and searched but somehow i seem to have missed this event you are referring to... can anyone point me to the incident sirky is referring to? he speaks about the www.bitomat.pl accident: http://news.ycombinator.com/item?id=2828445This is correct. EC2 is not persistant!!!!! And you are welcome MintCondition! |
|
|
|
I am throwing some hashes at you.
Thanks for the hashes; you're chugging along nicely! As you can see your current stale rate is below 0.2% now, and those stale shares are included in your balance. Our buffer is 'considerable', although we store most of it offsite as a security precaution. That's good, since we recently found out what happens when people leave their entire wallet on an EC2 instance! Anyway, I think my accepted shares are way to high, as are my stales. I should be around 700/0, not 9000/20  My rewards seem about right though |
|
|
|
|
Just out of curiosity, what sort of BTC buffer do you have? At 2%, your risk of ruin (mathematically speaking) is probably pretty high unless you have a lot of BTC.
|
|
|
|
|
Any reason that you can see that the server load indicator seems to randomly move between high, mid, and low?
|
|
|
|
|
I am throwing some hashes at you.
|
|
|
|
Did you fix the 0 byte issue?
No, it's happening on 3 machines, any of which have SDK 2.4 on them. I'm trying to roll back to 2.1 on some of them, but they're giving me some issues. Ah, just sounded like you may have. Carry on! |
|
|
|
Nice, looks like that works. If anyone is using Windows 7 and want's something similar to what I'm doing I added the batch file code below. Basically I've created a single batch file that includes all the information needed to launch the cgminer processes for all of my miner's and stuck it in a network share. I then set up a scheduled task on the mining machines set to run at login and launch the batch file in the network share. This way I can make mass configuration changes all in one location instead of having to jump to individual boxes and modify each one. REM Grab Local Machine Name and set to variable %host%
set host=%COMPUTERNAME%
REM Check variable %host% to determine and launch correct machine subroutine.
if %host% == Miner1 goto:Miner1
if %host% == Miner2 goto:Miner2
goto:eof
REM Individual machine launch subroutines - Timout value to allow for MSI Afterburner to fully load before miners start up.
:Miner1
echo Miner 1 Batch Startup...
TIMEOUT /T 75
cd /d C:\cgminer-1.5.1
start "Miner 1 CGMiner Status" /AFFINITY 0x1 /NORMAL cgminer -o http://mainserver:port -u userid -p password -I 8 -o http://backupserver:port -u userid -p password
goto:eof
:Miner2
echo Miner 2 Batch Startup...
TIMEOUT /T 75
cd /d C:\cgminer-1.5.1
start "Miner 2 CGMiner Status" /AFFINITY 0x1 /NORMAL cgminer -o http://mainserver:port -u userid -p password -I 8 -o http://backupserver:port -u userid -p password
goto:eof
:eof I don't believe the timeout function is available on other versions of windows, but this seems to work fine on W7. It can easily be expanded out for multiple boxes as well by just replicating the host variable checks and subroutines for more machines. Did you fix the 0 byte issue? |
|
|
|
Anyone having problems with SDK 2.4/2.5 and CGMiner 1.5.1 on Windows? With SDK 2.1 I fire up fine, but if I try 2.4 it crashes immediately on launch.
On one of my boxes it works perfectly. On another I get the 0 byte whatever error. So, sort of. |
|
|
|
Hi ckolivas, today I decided to give your miner a try, it has so many features that I could not resist anymore Sadly, after a couple of minutes both GPUs in my rig ( a 5850 and a 5870 on a linuxcoin v0.2b system) are declared SICK and then DEAD. This is without any fancy parameters, just -o -u -p and -I 8 (it is a dedicated rig) and -Q 2 to have a little more buffer (so I thought). Is there some other parameter I can try? spiccioli ps. my rig is running since june with phoenix and poclmb without problems, so I don't think this is due to hardware/OS issues. ckolivas is on a two week vacation. Are you running persistent? I had the same problem before I starting running in persistent mode with a r/w file. Yes, I'm persistent. I've found that with a -g 1 it does not happen anymore (it's been running for half a hour now), but I loose a couple Mh/s. spiccioli. ps. I had to install curl since it's not installed in linuxcoin by default. Do you have linuxcoin final? Everything should just work with it. |
|
|
|
Hi ckolivas, today I decided to give your miner a try, it has so many features that I could not resist anymore Sadly, after a couple of minutes both GPUs in my rig ( a 5850 and a 5870 on a linuxcoin v0.2b system) are declared SICK and then DEAD. This is without any fancy parameters, just -o -u -p and -I 8 (it is a dedicated rig) and -Q 2 to have a little more buffer (so I thought). Is there some other parameter I can try? spiccioli ps. my rig is running since june with phoenix and poclmb without problems, so I don't think this is due to hardware/OS issues. ckolivas is on a two week vacation. Are you running persistent? I had the same problem before I starting running in persistent mode with a r/w file. |
|
|
|
That said, I've posted a discussion on the simplecoin forum if anyone wants to weigh in there.
I wish you didn't have to log into simplecoin and then log in again to the forum |
|
|
|
* We pay for Stale Shares: up to 3% extra income; because we think a pool should be responsible for delivering new work to you in time!
Be careful. There are people who will try to game this. I know other pools have seen people try to do really sneaky stuff, like submitting the same work several times, submitting the same work over several miners (ie if any miner finds a share, all workers submit it), and stuff like that. Also, there are miners out there (cgminer) that, even if you are offline, will continue mining for the last known block. You don't want someone to just connect every hour to upload mostly useless work that you pay them for. Best of luck with your pool though! |
|
|
|
So, going forward: It seems the cheat-proof method is no longer the payout-method du jour.
Would anyone prefer Max-PPS, or PayPerLastNShares to the current implementation?
*MPPS is a terrible method. PayPerLastNShares is much better, and cheat-proof, so I would prefer that! The only downfall to maxpps I see is slower payout and a larger balance in the site wallet. That said, I've posted a discussion on the simplecoin forum if anyone wants to weigh in there. Read this thread, especially around the second and third pages: https://bitcointalk.org/index.php?topic=27698.0 |
|
|
|
I tried cgminer on a couple of my boxes last night and woke up to find 3/4 GPU marked as DEAD on one and 2/4 DEAD on another. Trying to restart the DEAD GPU doesnt seem to do anything on either machine (restarting the ones still running did seem to restart them OK). Both boxes have been running for weeks using poclbm without errors. Running the 1.5.3 binary on Ubuntu (3xHD5870 and HD6310).
Anyone else seeing problems with DEAD GPU that won't recover unless cgminer is restarted?
BB.
I do too, but only on my linux boxes. Actually, I have switched to persistent mode of Linuxcoin, and this does not seem to be happening anymore. Are you just running off of a USB stick? Perhaps persistent mode will fix you as well. |
|
|
|
|
I just looked this thread over, and I have to say that I think this is a great idea. I am not religious in any way, but I do believe in fellowship and helping others out, and those seem to be the ideas behind this enterprise (and probably most of the major religious texts in the world, though it is easy to forget that sometimes).
Let me know if you need any assistance.
|
|
|
|
thank you for your new release...
Anyway I am sorry to tell you, that there are still the same errors than before:
If I try to login via SSH, it still is asking me for a usernam and a password. Simple pressing enter does not work...
Is there a password?
It talks about this on the first page. Anyway it is: user live |
|
|
|
Really starting to miss the realtime stats  Why? I fully support the delay to bounce out the hoppers, I just dislike being in the dark about how long the current round is taking... Have yet to fully understand the "estimated shares this round" and a few others. BTCG is much more transparent than deepbit though. I understand that information is good, and it is just nice to know. But with a proportional pool, you simply cannot give out live stats. Even with a one hour delay, it isn't completely hopper proof, only hopper resilient. The only way a proportional pool could be hopper proof is to have the delay be longer than any round could ever legitimately be (for guild, something like 8 or 12 hours). And even then there is some longpolling nonsense that can be done to try and guess if a block has been solved by Guild or someone else. The estimated shares this round are the number of shares that the round would approximately be if the block was not found in the last hour. |
|
|
|
I was discussing a method I'd call "PPLNShifts" via PM a while ago. It would work like this:
To make it easier for pool operators on the database calculations and to allow for potentially huge "N"s, freeze the database in "blocks" of (for example) 500 000 shares. If a block is found, only pay the shares in the last (for example) 5 "shifts" proportionally, which you already have put in a nicer and leaner database format.
|---| means a complete block of X shares
* means a block was found
|---|---|---|---|---|-*
^ these last 5 "shifts" get paid, the "shareholders" in the shift during which the block was found have to hope for another block. It's not hoppable in my opinion, as you cannot benefit from jumping in on lucky "shifts" as they only benefit past shifts.
This makes it also much easier to for example dump all 500 000 getworks + solutions + account id in a csv and put it (seeded with bitTorrent) in a public archive on the pool's website, so anyone can verify and audit all solutions. This should keep a database small enough to still function well, while having all benefits of PPLNS.
Maybe this helps to have PPLNS pools with huge "N"s (I've sometimes seen now in the forum that people think "N" means "current difficulty"... maybe also clarify that N is just a radnom number - if it is "1", it is equal to solo mining) so the "I don't get paid anything on long blocks with PPLNS!!!11112" critics can calm down.
About PPLNS I'd also like to see if it is relevant and changes expectation values that some pools implement an "N" that is dependent on (and changes with) the current difficulty. As far as I understood it, N should be a constant, not a dynamic value that changes every 2 weeks.
I am not sure what advantage your system has over traditional PPLNS. I mean, is it really simpler from the database side or from the auditing side? I mean, if you want to have estimates, they would only need to be updated every N, instead of every share, but still, this seems like overkill. Having stats update every minute, or every 5, or something else is probably easier for everyone. Not paying out the most recently submitted shares seems like it would disincentivize people from joining? After all, they can mine somewhere else where they will be paid right away. Especially at the beginning of an N round, they are going to be theoretically N - current shares in N round + difficulty shares away from being paid. It seems that theoretically you would be getting paid sooner at a pool where the N round was almost over, so you would rather mine there. Especially when you think of small pools compared to the current difficulty. If it takes a really long time just to reach the end of N, you would never mine there since you wouldn't be paid for a long time at minimum. In regular PPLNS, you don't have this 'waiting period', so it makes no difference. The way Meni and I have discussed N for traditional PPLNS, the N would be a factor of the difficulty, so it wouldn't change. However, since Meni suggested that the payout is score based, with difficulty as a factor, the "N" as you are referring to it would change based on difficulty. In my opinion, having N only update sparingly (and not having it score based) is much better than a proportional pool, or something like that, but know that it does allow a bit of pool hopping around difficulty changes (you would mine at a fair pool at the end of a difficulty, and at a PPLNS pool at the beginning of a new difficulty). You need score based (which relies on difficulty) to defeat this. |
|
|
|
You may also want to consider adding the command "xhost +" I know to launch my SmartCoin on the Prefinal from ssh I have to run the following DISPLAY=:0 xhost +
DISPLAY=:0 sudo smartcoin Otherwise SmartCoin will error There is a more secure way to do this i can't remember off the top of my head but please note doing this compromises the security of your build. I will update the wiki on this  On a side note has anyone noticed the ssh is a lot faster now  I have! |
|
|
|
Do this before using the gpu's or use a root terminal This fixes my issue with aticonfig as well! lol should of said I've restricted this to root only I just sent you a BTC to the LinuxCoin donation address as a thanks for all your hard work! |
|
|
|
|
Show Posts
