 Show Posts
|
|
Pages: [1] 2 »
|
all good at your resolver (k1k2)? Kano pls check NS records. The frontend has been down for a while, i believe? CKPool Monitor hasn't updated any data for about an hour so i'm guessing the API is down along with the frontend.
Yes, was just checking on 1 setup and it had switched over to solo-ck, so checked the S3+ and it's switched also, saying kano pool is dead. Same as above. PM me your IP ... but I'd doubt that I'd have hit your miner ... Yeah it's a DNS problem ... I'm chasing it down. |
|
|
|
Kano pls check NS records. The frontend has been down for a while, i believe? CKPool Monitor hasn't updated any data for about an hour so i'm guessing the API is down along with the frontend.
Yes, was just checking on 1 setup and it had switched over to solo-ck, so checked the S3+ and it's switched also, saying kano pool is dead. Same as above. PM me your IP ... but I'd doubt that I'd have hit your miner ... |
|
|
|
Is constant "(out-of-band)" normal? Sent transaction of size 815 (out-of-band) to relay server
Sent transaction of size 339 (out-of-band) to relay server
Sent transaction of size 373 (out-of-band) to relay server
Sent transaction of size 226 (out-of-band) to relay server
|
|
|
|
He runs one of the relay nodes  My bad  |
|
|
|
Guys, I have low getblock latency, Matt's relay, plenty of bitcoind peers and a handful of p2pool peers yet I'm seeing almost 50% orphan shares. What could be the issue?
I would try and find some closer peers and add them with -n when starting p2pool... Only 2 of your peers are under 100ms away, the others are much further: "218.16.212.194:9333": 335.9999656677246 "115.70.176.17:9333": 14.999866485595703 "178.63.18.3:9333": 312.999963760376 "59.167.237.19:9333": 31.000137329101562 "198.72.112.205:9333": 226.99999809265137 "73.20.171.64:9333": 233.99996757507324 "58.22.92.36:51905": 359.9998950958252 "92.251.43.47:1138": 383.00013542175293 "185.59.16.32:9333": 296.9999313354492 "95.154.200.216:9333": 289.0000343322754 Yeah that's because the server is in Australia. Not many peers to choose from nearby. Maybe this will help https://bitcointalk.org/index.php?topic=766190.0 |
|
|
|
Running ckpool as proxy. After putting into production commit as of Nov 8 my local p2pool started reporting higher dead share rate, from around 0.5G-5G to 30-40G. After removing proxy stats returned to the expected numbers. Screen shot illustrates this. Since I'm code illiterate not sure if this is due to code change and now proxy provides true stats or p2pool node and pron't work well together.  edit:corrected date, rate. |
|
|
|
...Bad CPU performance isn't necessarily a show stopper... upgrade from Pentium D 915 2.8Ghz (dual core) to i7 3.2Ghz reduced GBT latency by 1s on unchanged OS (linux), p2pool, and bitcoind config. ... the previous block was 86 seconds before it ...
So that was a fast block, probably expected to get 86 / 600 as much transaction fees as an average block. It's not empty, so got nothing to do with it ... as you can easily have seen by looking at the 3 blocks mined in the last 24 hours without having to guess which is the block I found ... even though my block is listed there in my post Probably but I'm lazy... You can check what your bitcoind includes in its coinbase with : currentblocktx is the number of tx in the coinbase and is obviously lower than pooledtx (the number in your memory pool). # ./bitcoind getmininginfo
{
"blocks" : 248451,
"currentblocksize" : 77889,
"currentblocktx" : 133,
"difficulty" : 31256960.72776893,
"errors" : "",
"generate" : false,
"genproclimit" : -1,
"hashespersec" : 0,
"pooledtx" : 1759,
"testnet" : false
}
#
Well that says something evil about bitcoind ... Not really evil, txs that aren't included with default bitcoind settings pay below-minimum fees. Some pools obviously have more permissive settings and it probably pays off. ... looks like I need to decrease those 2 'min' values to at least stop bitcoind from screwing over the BTC network ...
Your bitcoind isn't really screwing anyone as it includes txs paying the minimum fees. TXs with lower fees are eventually included (older inputs get higher priority and there's provision for txs with no fees in a block), not giving a standard fee gets the expected outcome: slower processing by the Bitcoin network. Someone else I was discussing this with suggested that p2pool decides to drops transactions itself based on performance, it wont use all the txns given to it by bitcoind ... is that correct?
I'll bet not. I didn't check the code but: - p2pool logs match what you would expect when modifying bitcoind settings
- it's easier (and probably faster) to let bitcoind compute the coinbase instead of fiddling with it
- my node has the settings given in my previous mail which includes more txs than average and it is sending more data to other p2pool nodes than it receives, which matches the expectation that it processes more transaction and need to forward them to other nodes so that they can verify its shares
Interestingly related to that is that python sucks badly.
On my Quad core Q9300 2.5GH/s with 8GB of RAM, that is running p2pool, it sometimes hits 9x% CPU ... ouch ... but will never go beyond that since it is single threaded ... so a low power CPU will indeed suck badly in p2pool CPU performance during e.g. block changes
python doesn't suck badly, it just isn't designed for HPC. Bad CPU performance isn't necessarily a show stopper: as long as p2pool finishes to process data before it's needed or not delay the process waiting too much (almost everything happens asynchronously in p2pool) it's fine. Recent changes have helped in this regard: p2pool can prepare work before it's needed with the new protocol. So it could be at 100% CPU for a whole second preparing work (that's assuming a slow CPU with multiple miners using a different payout address) and only delay the workbase communication to miners by ~3%. That said I actually don't like the language itself but that's a matter of taste. |
|
|
|
Explanation is provided https://en.bitcoin.it/wiki/P2Pool under section "Useful features", last two bullet points. Just noticed this:
Pool Speed: 2.03TH/s (12% DOA+orphan)
Guess some more asic's came online?
share difficulty is now at 12.6k as well. I saw a post earlier on how to change this, but I didn't understand it. Can someone give a clear example of how to decrease it? Dust transactions don't mean much if you get a block every day. I'm more concerned about getting shares. M You talking about this one: https://bitcointalk.org/index.php?topic=18313.msg816322#msg816322What don't you understand? An example of what you put where. The above refers to increasing difficulty, I want to decrease it, which I don't think is possible. However I do think during off the "dust" transaction prevention is possible. Forrestv said "use the / parm". But didn't give specifics. M |
|
|
|
thx ck. After cgminier restart the same unit that was showing that error now shows zero value for A: R: and /m but correct hashing speed. Is it safe to assume the unit is actually not doing anything? Anyone seen below error before and perhaps knows what it relates to? I'm suspecting it's some kind of limitation on USB hubs (1a40:0101 Terminus Technology Inc.). USB: AMU0 read1 buffering 252 extra bytes It means cgminer found a lot more information from the device than it was expecting, but it's harmless and the equivalent to a hardware error. |
|
|
|
Anyone seen below error before and perhaps knows what it relates to? I'm suspecting it's some kind of limitation on USB hubs (1a40:0101 Terminus Technology Inc.). USB: AMU0 read1 buffering 252 extra bytes |
|
|
|
reaching 3 to 5% additional fee income Any way to calculate this? These stats are obviously underestimating what you can get: they are based on what most miners do, not what they could do. The fees could easily be 2 to 2.5% with bitcoind 0.8.2 default settings. con: you get a lot more orphans & more processing power is needed, not altogether related to the getblock latency, but actual transferring within the p2pool network itself
Not if you configure bitcoind and p2pool to lower their network traffic as (again...) explained by the guide in my signature. TL;DR: I have an average ADSL connection and use it for several other traffic types (Bitcoind+P2Pool is ~30% of my BW). I can even use 1MB blocks and lower minimum fees without lowering my efficiency (reaching 3 to 5% additional fee income). I only had to limit the number of bitcoind (10) and P2Pool connections (5 outgoing + 5 incoming) to get this result. |
|
|
|
In that case additional four https://blockchain.info/tx/f5c97d21db735798c0ea2cb64066d2f2bc0165c1c7188ed71014eb740b3f3e91Thank you bicer. I have verified your address. Just waiting for 6 confirmations... This group is officially closed for new orders. I have emailed friedcat to get the payment info and to place our order. If anyone of you who placed orders with this group buy want to order more, now is the chance to do it. Once I get payment address from friedcat, I'll place our order immediately so if you want to get more you can still do it. Peter |
|
|
|
For some reason cgminer is "consuming" all available ports when run with '--fix-protocol' and p2pool on local machine. Not sure if one of distro updates is causing this or misconfiguration somewhere. Tried cgminer versions all the way back to 2.7.4 and Python 2.7 and 2.6. Anyone got idea what could be the cause? Below is part of very long list of netstat -tnp tcp 0 0 127.0.0.1:9332 127.0.0.1:39383 ESTABLISHED 25198/python2.7
tcp 0 0 127.0.0.1:9332 127.0.0.1:39355 ESTABLISHED 25198/python2.7
tcp 0 0 127.0.0.1:39417 127.0.0.1:9332 ESTABLISHED 29338/cgminer
tcp 0 0 127.0.0.1:39135 127.0.0.1:9332 ESTABLISHED 29338/cgminer
tcp 0 0 127.0.0.1:39183 127.0.0.1:9332 ESTABLISHED 29338/cgminer
tcp 0 0 127.0.0.1:39338 127.0.0.1:9332 ESTABLISHED 29338/cgminer
tcp 0 0 127.0.0.1:39729 127.0.0.1:9332 ESTABLISHED 29338/cgminer
tcp 0 0 127.0.0.1:9332 127.0.0.1:39739 ESTABLISHED 25198/python2.7
tcp 0 0 127.0.0.1:9332 127.0.0.1:39492 ESTABLISHED 25198/python2.7
tcp 0 0 127.0.0.1:39639 127.0.0.1:9332 ESTABLISHED 29338/cgminer
|
|
|
|
With 2.11.0 in windows7 I noticed usb based keyboard has intermittent key delay on either press or release.
Which (and how many) FPGA devices and what sort of computer CPU (netbook, low power, ?) do you have? I suspect with ASIC that will get worse - i.e. whatever problem your computer has with the small amount of USB accesses at the moment, will only get worse as that increases with ASIC devices. With ASIC, cgminer will be hitting the USB port a lot harder. USB shouldn't have this problem with the low amount of USB access occurring at the moment. Is it every 5 seconds? Is it every key? Or is it once in a blue moon? Edit: also what is your USB layout - hubs, multiple motherboard ports, etc. No fpga or asic devices, just 7970 gpu. MB asus p9x79 with mouse and keyboard connected to usb 2.0 via 4 port kvm, no other devices on any other usb. It may happen once or twice within 5 seconds. This is very noticeable in content requiring constant user interaction, i.e. pc game. With 2.10.5 and kernels from 2.11.0 (renamed cl's to match 2.10.5) keyboard delay no longer occurs. |
|
|
|
|
With 2.11.0 in windows7 I noticed usb based keyboard has intermittent key delay on either press or release.
|
|
|
|
The server is down. I sent a message to the guy who runs the server. Maybe he is on vacation, but I think it is more likely that he stopped paying for the server. He hasn't been on the forum or contacted me fort a while. Anyway, I am going to post the code on github next week after the new year. Someone else can give it a go.
or forgot to renew domain name. Expiration date: 18 Feb 2013 17:42:00
^^^^^ Does p2pmining.com resolve? |
|
|
|
The server is down. I sent a message to the guy who runs the server. Maybe he is on vacation, but I think it is more likely that he stopped paying for the server. He hasn't been on the forum or contacted me fort a while. Anyway, I am going to post the code on github next week after the new year. Someone else can give it a go.
or forgot to renew domain name. |
|
|
|
Yep same issue here, 7/64, atikmpag.sys BSOD. Update: I mined stable for months after installing 7/32. Yesterday I retried to install 7/64 and the same story happened, no matter what driver or combination of them I used. Then I restored my 7/32 system backup and patched it for PAE (since 7/32 "sees" just 2.75 GB of my 4 GB Ram, and the patch allows it to use all the Ram available). Then guess what? atikmpag.sys BSODs restarted. They happen even if I don't mine. So it must be something related to the use of the Ram.
I wonder if anyone else with 7/64 experienced anything like that and what drivers are they using.
|
|
|
|
Inaba were you able to resolve this? I'm running into exactly the same issue. Ok, so I'm at stumped, maybe someone has an idea:
I have a W7 x64 box that I reloaded recently. I loaded the ATI drivers and the SDK... firing up CGMiner, it mines just fine. However, when I q out of CGminer, W7 will BSOD with a SYSTEM_SERVICE_EXCEPTION in atikmdag.sys. I've Googled the hell out of it and tried all the suggestions and nothing seems to work. I've uninstalled and reinstalled several different drivers versions, including 11.2 which I know worked with v2.4, v2.5 and v2.6 of the SDK. Nothing changes the behavior.
I realize it's not directly a CGMiner problem and something is wrong somewhere in the system, but bugger all if I can figure out what it is. Does anyone have any ideas? I've tried Driver Sweeper and reinstalled the drivers from scratch, but nothing works.
The system operates fine, I can play games, etc... and CGMiner mines fine. The only time there is a problem is when I quit CGMiner, otherwise zero problems at all. I'm completely stumped.
PS - this is mining with a pair of 6990's.
Anyone?
|
|
|
|
|
