 Show Posts
|
|
Pages: [1] 2 3 4 »
|
Balthazar, mining at 1260kh/s with two 7970s I frequently get a difficulty above 500. Isn't it a bit too much? I personally would like better something around 200 (300 at most) as for now. Or a value a bit quicker (I feel like it's very quick to climb up, but very slow to fall down). Let me explain myself: of course even a difficulty of 2000 wouldn't be a real issue - and, some months ago, I used to BTCmine at 999-difficulty with a mining power of just about 1350Mh/s, so... go figure  )) I'm just curious about it: do you need to force so high difficulties to keep the traffic low? As the pool is growing, will they grow as well? Thanks. |
|
|
|
I am trying to withdraw and am getting this error
Transaction failed(incorrect address?)
??
The same to me, now, at notroll.in. It's actually unbelievable. Who's administrating this pool? A bunch of monkeys playing with keyboards? I'm starting to think that I've given enough chances to this once-upon-a-time really good pool. And Nicksasa has reased the fee to 5%, too. Nice move! My humble suggestion is: switch everything back to what you were using one month ago, or so. Fuck vardiff, fuck the eu server, fuck everything else that is new. Just use stratum with a fixed difficulty of 256. This should give you the ability to manage an increased traffic, and should lower your traffic too (as you like). It isn't fair to raise your fee when you're causing so many incredible problems - and it isn't fair to cause all these problems, too. Sorry, but I've never ever seen a BTC/LTC serious pool so unstable. Never! Sad but true! |
|
|
|
And @ Lem, once the pool has reached the point where it has paid out 1mil LTC, the fee will be 0% for 200 blocks.
Thanks, sir, I really appreciate it. Regards. |
|
|
|
There isn't exactly much I could do against a DDoS, especially when I'm sleeping.
This. It is a shitty deal for all of us, and taking it out on Nicksasa doesn't help anything. He has a great deal of motivation to keep things running......if we aren't getting paid, neither is he. I'm sorry, yochdog, but IMHO the point is: since recently we have seen accepted but unpaid shares - which is something actually unusual and scary, at least in my experience, in BTC and now LTC world - and since, if the pool website is down, we cannot check if the accepted shares number and the balance are correctly growing, well, in a spot like this one, a quick message "DDOS on website, but no prob for your shares" IMHO would be greatly appreciated. As for the sleeping time: thousands dollars/day IMHO mean more than something. I think it wouldn't be too much of an effort to set a ring on the box, just in case something should go wrong... or even to pay someone who stays awake.  IMHO the keywords here are: QUICK and INFO. Nobody's asking for miracles. Regards. |
|
|
|
|
Notroll hashing power is currently above 2500MH/s. Its 4% fee means above 100MH/s: a fee of thousands dollars/day. Where the fuck is Nicksasa? How long have we to wait to know if our shares are accounted even if the website is down (mostly because of what has recently happened)?
Are you fucking kidding?
|
|
|
|
|
Also litecoinpool and kattare are offline now. WTF???
|
|
|
|
Not trolling (no pun intended) but why should I join a pool with a 4% fee over one with 0% or even 2%? I'm just trying to figure out what makes it popular. Help appreciated.
You've to take into account many factors: of course the type of reward (proportional, PPS...); the fee itself; whether the pool pays for stale shares (and, if it doesn't, how many stale shares you get with that pool); whether the pool pays for orphaned blocks too; whether there are LTC withdrawal fees; pool downtime;... the risk of losing shares (the pool says "accepted" and then it doesn't pay for'em)... |
|
|
|
It has already been fixed since 15 minutes ago.
thanks, do we have lost shares? Yes, I do. |
|
|
|
It has already been fixed since 15 minutes ago.
What has been fixed, exactly? Thanks. |
|
|
|
I don't know what's going on, but this is bad.
Normally when something is wrong with the pool, my rigs switch to backuppool.
Not in this case. The shares simply seem to flow into nirvana.
This is awfully bad! However, there could be an easy solution. For each hour of unaccounted shares (one hour means a bit more than a 4% loss on a daily income), we could have a whole day without the 4% fee. Or we could just switch pool... and never come back. |
|
|
|
its going back normal now but.. i think there are lost shares.
It'd be completely unacceptable, in my humble opinion, if those shares haven't been accounted. |
|
|
|
|
Now the pool speed has come back to life, but my balance and my shares count aren't changing.
|
|
|
|
However -g 1 is now almost mandatory with these higher TCs.
YOU DA MAN!!!! Excellent work!!! |
|
|
|
7970 @ 1135/1890, LG 2, TC 22392: GPU 0: 72.0C 3413RPM | 714.6K/715.7Kh/s | A:0 R:1 HW:0 U:0.00/m I:20
Uhm. With LG 2 and TC 22392 I get: [2013-03-15 16:04:33] Maximum buffer memory device 0 supports says 805306368
[2013-03-15 16:04:33] Your scrypt settings come to 1467482112
[2013-03-15 16:04:33] Error -61: clCreateBuffer (padbuffer8), decrease CT or increase LG Ok, the above error seems going away using: export GPU_MAX_ALLOC_PERCENT=100
export GPU_USE_SYNC_OBJECTS=1 (I never ever needed this thing before). However, I get: [2013-03-15 16:39:49] Error -5: Enqueueing kernel onto command queue. (clEnqueueNDRangeKernel)
[2013-03-15 16:39:49] GPU 0 failure, disabling!
[2013-03-15 16:39:49] Thread 1 being disabled
[2013-03-15 16:39:49] Error -5: Enqueueing kernel onto command queue. (clEnqueueNDRangeKernel)
[2013-03-15 16:39:49] GPU 0 failure, disabling!
[2013-03-15 16:39:49] Thread 0 being disabled
[2013-03-15 16:39:49] Thread 1 being re-enabled
[2013-03-15 16:39:49] Error -5: Enqueueing kernel onto command queue. (clEnqueueNDRangeKernel)
[2013-03-15 16:39:49] GPU 1 failure, disabling!
[2013-03-15 16:39:49] Thread 2 being disabled
[2013-03-15 16:39:49] Error -5: Enqueueing kernel onto command queue. (clEnqueueNDRangeKernel)
[2013-03-15 16:39:49] GPU 1 failure, disabling!
[2013-03-15 16:39:49] Thread 3 being disabled
[2013-03-15 16:39:49] Error -5: Enqueueing kernel onto command queue. (clEnqueueNDRangeKernel)
[2013-03-15 16:39:49] GPU 0 failure, disabling!
[2013-03-15 16:39:49] Thread 1 being disabled
[2013-03-15 16:39:49] Thread 1 being re-enabled
[2013-03-15 16:39:49] Error -5: Enqueueing kernel onto command queue. (clEnqueueNDRangeKernel)
[2013-03-15 16:39:49] GPU 0 failure, disabling!
[2013-03-15 16:39:49] Thread 1 being disabled |
|
|
|
For all you crazy scrypt/LTC mining fanatics, I have finally found the reason you cannot set very high thread concurrencies or intensities on 79x0 cards. It shall be fixed in the next version. I'm able to run my 7970s at TCs of 22392 now.
And how much faster is it? :-p |
|
|
|
Stratum always starts at diff 1 [...] Perfectly clear. Thanks one million. |
|
|
|
Sounds to me like a HHTT stratum implementation issue rather than anything else. Thanks for your quick reply. Sorry to bother you. Since I don't know anything about the protocol and about your code, let me know whether I understand correctly (so I will contact HHTT and I will be able to explain better the issue): that nonce isn't real, is it? Cgminer never found it and never sent it: it is faked by HHTT. Otherwise I don't understand why cgminer didn't log it. Thanks again. |
|
|
|
I've noticed a strange behaviour. Perhaps, in some circumstances, some shares are sent to the wrong pool. Please look at my cgminer log: [2013-02-24 09:57:24] Switching to stratum+tcp://stratum.hhtt.1209k.com:3333/
[2013-02-24 09:58:20] Pool 0 stratum+tcp://stratum.hhtt.1209k.com:3333/ not responding!
[2013-02-24 09:58:20] Switching to http://pit.deepbit.net:8332
[2013-02-24 09:58:20] Pool 0 stratum+tcp://stratum.hhtt.1209k.com:3333/ alive
[2013-02-24 09:58:20] Switching to stratum+tcp://stratum.hhtt.1209k.com:3333/
[2013-02-24 10:03:58] Lost 1 shares due to stratum disconnect on pool 0
Where has that share gone? HHTT pool log says: sockthing/dub 2013-02-24 08:58:30 N H-not-zero 999 0.00000000 00000000 faacb474 815f8e93 BTW: 9:58 on my log, 8:58 on HHTT log. That's correct, there's one hour difference. This is why i've been able to notice it: only 999 (and above) difficulty shares should go to HHTT, and 00000000 faacb474 815f8e93 of course has a much lower difficulty. It shouldn't have gone there: most probably that nonce had been generated for Deepbit, I think, but in the meantime cgminer switched back to HHTT, so somehow the share was sent to HHTT. It's strange, too, that cgminer never logged that nonce (I mean, it never said: "... Rejected faacb474..."): lem@biggy:~$ grep faacb474 /tmp/mining/minerlog
lem@biggy:~$ From time to time, I have some of these "H-not-zero" hashes on HHTT logs. This has been happening since HHTT switched to stratum. I never saw an "H-not-zero" before. My only other stratum pool is slush: but slush doesn't show a log of all received shares: so I cannot know if this same behaviour is common to slush too. I'm a bit concerned: if a 1 difficulty share goes to the wrong pool, who cares? But if one of my 999 difficulty shares goes to the wrong pool (let's say it goes to slush instead of going to HHTT, while cgminer is switching between these two pools), I'd be surely pretty sad. Thanks. |
|
|
|
Aren't stale share paid anymore on stratum? I have two issues. First: 2013-02-19 02:37:18 N quite stale 999 0.00000000 My cgminer says: [2013-02-19 03:36:20] Stratum from pool 0 detected new block
[2013-02-19 03:36:20] Rejected 0028e704 Diff 1.6K/999 GPU 0 pool 0 Second: 2013-02-19 03:58:39 N quite stale 999 0.00000000
2013-02-19 03:58:35 N quite stale 999 0.00000000 This time the situation is a bit different, with a possible stratum pool problem too. My cgminer says: [2013-02-19 04:57:26] Switching to http://rpc.hhtt.1209k.com:3333
[2013-02-19 04:57:40] JSON stratum auth failed: (null)
[2013-02-19 04:57:40] Pool 0 http://rpc.hhtt.1209k.com:3333 not responding!
[2013-02-19 04:57:40] Switching to http://pit.deepbit.net:8332
[2013-02-19 04:58:51] Accepted c54857d1 Diff 1/1 GPU 1 pool 2
[2013-02-19 04:58:54] Accepted 1485902d Diff 12/1 GPU 1 pool 2
[2013-02-19 04:58:54] Accepted 49c168d7 Diff 3/1 GPU 1 pool 2
[2013-02-19 04:58:57] Accepted 5f504435 Diff 2/1 GPU 0 pool 2
[2013-02-19 04:59:04] Accepted e71eac09 Diff 1/1 GPU 1 pool 2
[2013-02-19 04:59:06] Accepted 99bc9666 Diff 1/1 GPU 1 pool 2
[2013-02-19 04:59:11] Pool 0 http://rpc.hhtt.1209k.com:3333 alive
[2013-02-19 04:59:11] Switching to http://rpc.hhtt.1209k.com:3333
[2013-02-19 04:59:27] [b]Lost 2 shares due to stratum disconnect on pool 0[/b] Thanks. |
|
|
|
|
