Show Posts
|
Pages: [1]
|
Какой-то странный вопрос... Конечно же постоянные отношения лучше. Надежнее, это тебе и друг, и любовник. А отношения на одну ночь фиг знает, что принесут, тем более, когда человека не знаешь
|
|
|
На НГ вообще никому ничего не подарила, ибо зима - это период дней рождения, и приходится огогого как потраться из-за этого.
|
|
|
Быть абсолютно счастливым невозможно. Можно искать счастье в мелочах, можно строить счастье, но быть "всегда счастливым" невозможно
|
|
|
Нет, я как девушка ответственно заявляю, что цветы - самый отстойный подарок. Они же завянут! Лучше книгу, косметику, украшения на крайняк.
|
|
|
username: JDog
awesome promotion
|
|
|
Amazing that it actually runs! I had imagined the biggest problem with the porting would have been the sockets. Perl on Windows possibly doesn't implement all socket features, like maybe nonblocking mode, or the can_read function of IO::Select. Look in the rpc_server_alt function that handles all client connections. There is a big while loop which iterates over all connected clients, reads any request data available up to that point, and then sends response data when sufficient request data (such as basic authentication) has been obtained. Trace the execution of this loop to see what runs normally and at what exact point the execution gets stuck.
So I've gone through the rpc_server_alt function and it doesn't appear to be hanging anywhere, the loop runs normally whether the worker is connected or not. But what I did find that seemed odd, was the it moves into code that appears to process the getwork request *as the worker disconnects*. Here's a short section of code I'm referring too. (Can't give line numbers as the unix2dos converter added a ton of whitespace, in theory it's after line 1400) } else { if ($vars->{longpoll}){ $vars->{rec}=2; last; } $user->{getworks}++; my $user_ip=$user->{host}; $user_ip=~s/:.*//; my $limiter=$user_limiter{$user_ip}; my $lawful=user_lawful($limiter); my $pair; if ($lawful){ #only give good shares to lawful users <-indicative comment $pair = $work_queue->dequeue_nb; <-confirmed code is executed only when worker is disconnecting } if (!$pair){ $pair=$solo_queue->dequeue; } $limiter->{got_works}++ if $limiter;; my ($work, $pool_name) = @{$pair}; { lock $work_dequeues; $work_dequeues++; } logd("rpc getwork from $vars->{host} ($pool_name ".substr($work->{data}, 16, 8)." ".substr($work->{data}, 72, 8).") queue: ".$work_queue->pending."/".$WORK_QUEUE_SIZE."w ".$solo_queue->pending."so ".$submit_queue->pending."sh\n");
The rpc getwork message does appear, but only when the worker disconnects. Again, I'm not strong with my Perl, so maybe this code is only supposed to run during disconnection, but the comment and the rest of the code implies it's removing a getwork from the internal queue and giving it to the worker. Would this be accurate?
|
|
|
Hey guys, I hope you can help with this one.
I'm trying to set up Multipool on a Win7 machine (yes, I'm a masochist), and things seem to be more or less working. I can see Multipool connecting to the regular pools and get shares. I can see my miner connect to it, but for some reason the miner never receives any shares from Multipool. The miner sits connected, but idle and no errors on either side. I've played around with ports and I'm sure it's connecting properly (firewall deactivated and such), but I just can't get the miner to get any shares.
I'm a coding 'hobbiest', but I've learned Perl in the last 48 hours for this project. I understand about 1/2 of what the code does, but I can't find the section that assigns shares to the workers. It could be a porting issue (had to change several lines to make it work with wget for windows), could be a config error(IP addresses or such), could be who the heck knows what??
I don't know what other kind of information anyone would need to help me, but I'm grasping at straws at this point.
|
|
|
For reasons I can't explain, my % of stale shares has gone through the roof this morning (just woke up). Yesterday, they were averaging (as usual) single digit stales. Now I'm seeing 10%, 20% even more than 30% on some of my machines. Nothing has changed on my end. Any idea why this might be? What miner do you use ? Have you tried to restart it ? I'm using guiminer from 6.09. I have restarted recently but I've not switched modes since. I'll switch and see what happens, then I'll get the 6.14 version of guiminer and switch back to see if that makes any difference. Edit: or I could be answering totally the wrong comment and just ignore me. *embarrassed*
|
|
|
While I'm happy to hear there isn't a penalty (I wasn't really expecting one), the behavior was still very much present. I know I switched modes at approximately 10:30 and at 22:30. While I could understand the current block not being switched, the change actually took 6 blocks each way, equal to about 5 hours on average after I changed the settings. This happened on two different occasions. I have two miners running, both were switched at the same time. I apologize for the wall of numbers.
Expected payouts 25.06 03:28:35 0h 36m 299 2001647 0.00724478 48.5(299/2001647)=0.00724478 (100%) 25.06 02:52:30 0h 29m 235 1636591 0.00696417 48.5(235/1636591)=0.00696417 (100%) 25.06 02:22:47 0h 10m 81 574429 0.00439045 48.5(81/574429)=0.00683897 (64.2%) 25.06 02:12:14 2h 09m 1096 7082333 0.00360891 48.5(1096/7082333)=0.00750544 (48.1%) 25.06 00:03:05 0h 16m 162 905648 0.00423067 48.5(162/905648)=0.00867556 (48.77%) 24.06 23:46:28 0h 46m 390 2496051 0.00378899 48.5(390/2496051)=0.00757797 (50%) 24.06 23:00:25 0h 31m 258 1714441 0.00342298 48.5(258/1714441)=0.00729859 (46.9%) 24.06 22:28:40 0h 18m 165 972916 0.00174475 48.5(165/972916)=0.00822527 (21.21%) 24.06 22:10:34 0h 14m 118 763544 PPS
.... loads of PPS blocks in between here.....
24.06 14:22:50 0h 39m 253 2100701 PPS 24.06 13:43:44 0h 41m 258 2235103 0.00110666 0.00559840 (19.77%) 24.06 13:01:56 1h 13m 632 3941647 0.00377748 48.58% 24.06 11:48:14 0h 32m 271 1742611 0.00364597 48.34% 24.06 11:15:43 0h 32m 312 1729115 0.00426345 48.72% 24.06 10:43:23 0h 16m 154 898982 0.00420809 50.65% 24.06 10:26:38 0h 10m 81 553690 0.00402933 56.79% 24.06 10:16:22 0h 17m 141 916842 0.00745876 100% 24.06 09:59:18 0h 27m 236 1483278 0.00771669 100%
|
|
|
Any idea on when it will be back up and running?
Edit: Sorry, just found the other thread. You're still waiting on the websockets to start sending data.
|
|
|
Is there a penalty for switching to PPS and back to Prop too often? I've had several instances where I would switch to PPS and then get the next 5 blocks at 50% of normal Prop payout. The 6th block would be 20% normal and then full PPS. The reverse was true when I went back to Prop, (20% then 5 @ 50% before full Prop payout).
I noticed back about 10 pages someone was commenting that they were being paid out less than expected, they were getting the same percentages, but they didn't specify any other conditions.
|
|
|
I agree, I was so excited about finding this pool and less than 1/2 day later it's MIA.
|
|
|
Excellent advice, thanks!!!
|
|
|
Gratuitous 5th post. At least I'm not spamming a real thread.
|
|
|
It's probably a test transaction by the admins.
|
|
|
5 Posts and 4 hours to get access to other threads. More posts for access to other options. It's in the first post of the thread.
|
|
|
Just saying hello to all the smart people that got into Bitcoins.
|
|
|
|