 Show Posts
|
|
Pages: [1] 2 3 4 5 6 »
|
|
Cleveland Cavaliers 98 @ 89 Utah Jazz
|
|
|
|
|
New York Rangers 4 @ 3 Columbus Blue Jackets
|
|
|
|
|
username: OCedHrt
thank you duckdice
|
|
|
|
|
Memphis Grizzlies 92 @ 103 Golden State Warriors
|
|
|
|
|
Charlotte Hornets 98 @ 93 Boston Celtics
|
|
|
|
|
betking.io OCedHrt/412078
|
|
|
|
|
Columbus Blue Jackets 1 @ 4 Tampa Bay Lightning
|
|
|
|
I just tried changing my password and it says my current password is wrong.
So I cannot change to a new one now.
Is it likely that passwords were changed on many/most accounts or did you wipe out old ones at some point?
BTW if the hacker still has some fingers in here then forcing us to enter our password for changing would expose the password. So hopefully some script wasn't modified to send passwords to him when an attempt was made to change it...
(Not a big problem for me as all my passwords are different and random 25 char strings)
And also possible that simply logging in sends out your password. Good thing I use junk passwords for forums. |
|
|
|
haha sigh ive decided to just give up on bitclockers their system doesnt seem to handle more than 230Gh and everyone start to get cycled, it has nothing to do with being a hopper since I saw other users reporting they also keep getting idle miner, 20second reconnect.
Till they upgrade its just not sane to waste gpu cycles there.
Yeah, I noticed they're lagging like crazy. The lag detection also interferes with cgminer's submit work queue which is submitting timed out shares to the new pool during LP switch-over. With the bitclockers lag this is adding up to 20% rejects for me. Is there a way to configure how many connection failures/or how long before a server is considered lagging? If not, I am going to look into this. And a way to order backup pools like we could do with ryouiki's fork? It seems a scheduler would need to be created? I have been running btcg as backup (crazy?) because of their recent insane luck +60% under difficulty. The connection is also a lot more stable than ars/eligius at <2% reject. I'm getting about 0.000049105/share. I haven't been following this thread for a while and now have a lot of catching up to do  |
|
|
|
are you sure you switched to the api method suggested by mrsam?
for me its working.
and he already announced HERE that he will fake stats when accessed through the https site (which i am fine with and which i can understand)
Well, it's not about fake stats through https. The stats are correct in the browser but incorrect in bitHopper. I assume they are filtering by user agent - changing the user agent got the correct stats. There isn't a ryouiki release with the correct api pull for triple. It just parses the website. Seeing as there is a json for the round shares, I just updated my local copy to use that. |
|
|
|
the SMPPS by arsbitcoin at 0% fee pays at a minimum 10% more than PPS from deepbit.
Not sure how you could work on 'feel' when in practice there is no chance deepbits PPS @ 10% fee will pay you more.
Regarding bitcoins.lc, I have a feeling they changed their Prop to score based Prop or something, I just got screwed over by them just finishing a 3hr 30mins block, I mind pretty much solidly for 2hrs 30ms of the block however my original estimate earnings for that period would have been 2.8BTC, and I received 0.18BTC for missing 1hr of the period ? sounds like they should be avoided.
Yeah, I'm not talking about PPS on deepbit, just using the straight prop. Not so much a 'feel' as a comparison to what I was pulling when I was mining just on Deepbit (prop) vs. the coins that are stagnating at eligius and ars. Ars won't pay until .50, eligius won't pay until .33 but Deepbit will pay out above .01 As long as those coins sit in an account at eligius or ars they are at risk (ban and keep) vs. pulling into my wallet where they are actually "mine". Before they are confirmed in my wallet, I can't count them as earned. What makes you think deepbit wouldnt ban you faster for hopping than ars or eligius? Also, prop at deebit is 3% fee, SMPPS is non-variance 0% fee at arsbitcoin. Not sure at what hashrate you are mining but if 1BTC min withdrawal at arsbitcoin is to much, then I assume you arnt hashing fast. Min at Ars is 0.01 BTC. |
|
|
|
Didn't click through But, shouldn't also: - bits = bits[2:len(bits) - 1] In that case? This is to remove the 0x and L. |
|
|
|
Does the current git run? Traceback (most recent call last):
File "C:\Users\Michael Hsu\Desktop\m0mchil-poclbm-1b5ec3e\HttpTransport.py", l
ine 45, in loop
self.queue_work(work)
File "C:\Users\Michael Hsu\Desktop\m0mchil-poclbm-1b5ec3e\Transport.py", line
122, in queue_work
self.process(work)
File "C:\Users\Michael Hsu\Desktop\m0mchil-poclbm-1b5ec3e\Transport.py", line
81, in process
self.set_difficulty(work.difficulty)
File "C:\Users\Michael Hsu\Desktop\m0mchil-poclbm-1b5ec3e\Transport.py", line
76, in set_difficulty
self.true_target = np.array(unpack('IIIIIIII', true_target.decode('hex')), d
type=np.uint32)
File "c:\Python27\lib\encodings\hex_codec.py", line 42, in hex_decode
output = binascii.a2b_hex(input)
TypeError: Odd-length string |
|
|
|
its a getwork request from your miner to get something to do
its forwarded to the selected pool (eg arsbitoin
A bit off-topic but what's a reasonable getwork interval anyways? Shouldn't the client complete the work before asking for more? |
|
|
|
Sample output on exiting now: Summary of runtime statistics:
Started at [2011-07-19 14:40:09]
Runtime: 2 hrs : 31 mins : 18 secs
Average hashrate: 1680.1 Megahash/s
Queued work requests: 3317
Share submissions: 3489
Accepted shares: 3489
Rejected shares: 0
Reject ratio: 0.0
Hardware errors: 0
Efficiency (accepted / queued): 105%
Utility (accepted shares / min): 23.06/min
Discarded work due to new blocks: 0
Stale submissions discarded due to new blocks: 9
Unable to get work from server occasions: 16
Work items generated locally: 330
Submitting work remotely delay occasions: 33
New blocks detected on network: 10
Pool: http://ozco.in:8332
Queued work requests: 3253
Share submissions: 3426
Accepted shares: 3426
Rejected shares: 0
Reject ratio: 0.0
Efficiency (accepted / queued): 105%
Discarded work due to new blocks: 0
Stale submissions discarded due to new blocks: 9
Unable to get work from server occasions: 15
Submitting work remotely delay occasions: 33
Pool: http://bitcoinpool.com:8334
Queued work requests: 64
Share submissions: 63
Accepted shares: 63
Rejected shares: 0
Reject ratio: 0.0
Efficiency (accepted / queued): 98%
Discarded work due to new blocks: 0
Stale submissions discarded due to new blocks: 0
Unable to get work from server occasions: 1
Submitting work remotely delay occasions: 0
Summary of per device statistics:
GPU 0: [419.9 Mh/s] [Q:913 A:901 R:0 HW:0 E:99% U:5.96/m]
GPU 1: [420.1 Mh/s] [Q:912 A:865 R:0 HW:0 E:95% U:5.72/m]
GPU 2: [420.5 Mh/s] [Q:908 A:865 R:0 HW:0 E:95% U:5.72/m]
GPU 3: [419.6 Mh/s] [Q:910 A:858 R:0 HW:0 E:94% U:5.68/m]
Btw, forgot to mention this doesn't seem to be working on Windows. And should the run time output include hash rate per thread? I only see per device. |
|
|
|
There's an issue with some users's btcmine accounts for that time period, because I can't access old btcmine stats.
Pool hopping doesn't really work with BTC Mine anyway, so I think people will be happy if you just share the coins for the unpaid shares equally for that site and spend the time on fixing bitcoins.lc instead. Sounds good to me: just divvy up coins based on your shares' percentage of total shares from btcmine for that period? That's probably what I'll end up doing. Can anyone/everyone else who's having this problem please let me know? If it's just a couple users, it's going to be far easier for me to just do this manually. You shortend my Shares from 22K to 15K, 3K still pending: http://multiclone.us.to:18080/user/?address=17L8TsmgcaJowgpuYBzMx9iXUfiQxCVv4TMay you look into this? My understanding was that the total wasn't correct. But Nick should confirm this. |
|
|
|
how does one specify phatk110714.cl or poclbm110717.cl ?
One does not. The poclbm kernel is far far behind the phatk kernel in speed and any hardware that can run the phatk kernel is given it. The poclbm kernel is reserved for nvidia cards and ATI 4x cards only. The phatk kernel, even without bitalign patching, crashes on these lesser mining cards. Phoenix with phatk worked on my 4850, and that was faster than poclbm. |
|
|
|
Nvidia cards under win7 are working 100% with 1.2.8 How do i run cgminer to only use the cpu (disable Gpu) ? so that i can run 2 instances ? (one for cpu, one for gpu) Also getting [2011-07-18 17:01:37] HTTP request failed: Recv failure: Connection was rese
[2011-07-18 17:01:51] Share e34b098c accepted from GPU 0 thread 0
[2011-07-18 17:01:53] Share cad4e4ac accepted from GPU 0 thread 0
[2011-07-18 17:01:56] Share 86bbdd54 accepted from GPU 0 thread 2
[2011-07-18 17:02:03] Share 0a93ea28 accepted from GPU 0 thread 0
[2011-07-18 17:02:03] Share 1d0a2b8d accepted from GPU 0 thread 2
[2011-07-18 17:02:07] longpoll failed, sleeping for 30s
[2011-07-18 17:02:13] Share 57c1eff6 accepted from GPU 0 thread 2
[2011-07-18 17:02:22] Share ed20f93e accepted from GPU 0 thread 2
[2011-07-18 17:02:24] Share f8b59049 accepted from GPU 1 thread 3
[2011-07-18 17:02:29] Share 37edc62c accepted from GPU 1 thread 1
[2011-07-18 17:02:38] HTTP request failed: Recv failure: Connection was reset
-g 0 will give you only CPU mining Looks like the longpoll dies when communicating with your pool's server. Should be harmless since it can detect block changes itself, but it's not ideal. Something funny going on with longpoll, and it seems to be every time I try converting from post to get. DiabloMiner also uses POST I believe, but poclbm uses GET. I have no issues using poclbm though. Update: GET is working fine for me. Great work. Have you had a chance to look at the updated phatk kernel from 7-17? It would require interface changes between cgminer and the kernel, but it's the smallest kernel (least AUOPs) yet. Update2: Or not...seems same issue everyone else is getting. [2011-07-18 08:36:13] New block detected on network before longpoll, waiting on
fresh work
[2011-07-18 08:36:25] longpoll failed, sleeping for 30s |
|
|
|
So heres a thought, anyone here consider putting together a theoretical luckbased approach ? I know its been discussed here but I think it would still be interesting to actually do it. Pull the last 2 or 3 blocks and see how far out of the difficulty range the avg is ie. 3blocks(just a number i like) combined gives 6million, that avg out at 2million per block so not terrible unlucky, however a different pool have their last 3 blocks at combined of 10million, thats > double avg difficulty per block thus we work a formula into the duration hopper should stay at this pool for this new block which would be the 1st block after the last 3blocks used for sample. My rough approach would assume the following: Right now we seem to use a 40% of diff approach, now if we use that as our base value and apply the difference of the last 3 blocks in example above we will get the following. 10million shares across 3blocks = 3333333.33 shares per block This means the last 3 blocks lasted on avg 213% longer We will then calculate our 40% into current difficulty which would be 625211.2 and add 213% which gives 1331699.85 difficulty thus the new difficulty for the selected pool to stay on for the 4th block(block just after the previous 3) Now the reverse would be implied when a pool got really lucky in last 3blocks, thus we would be avoiding them or leave them far earlier than 40% of difficulty. I hope this makes somewhat sense  it does in my twisted mind. please note: This is some hectic thumbsucking, would be nice to check it out in practice. Hate to be the wet blanket that rains on your parade, but blocks are solved as a poisson process. Part of the definition of a poisson process is that it has no 'memory' of prior events. This means that each new block has a the same probability of being solved before <difficulty> as any other block. So a 'luck' based approach would only work randomly and increase variance. Sorry. Now, who's going to open up another forum thread called 'Hoppers here!'. c00w must be getting sick of our meanderings, much as I enjoy them  Indeed but the luck averages out over time: Luck this difficulty (1563027) 1724037 shares (-9.3%) Luck at difficulty 1379223 1384144 shares (-0.4%) Luck at difficulty 876954 875473 shares (+0.2%) If a large pool has significantly worse luck than that you can usually suspect some foul play. |
|
|
|
|
