that looks to be about what i'd get for 5830 & 5870, I use phoenix w/ aggression 9 (and set process to real-time priority)    but as i recall, something like 325 memory would be optimum for 900 and 256 worksize.   i've switched to 195 memory and 128 worksize, keeps cards cooler and only lose a few mhash

executed a Gangnam Style compile using the latest github pull and https://github.com/sipa/bitcoin/commit/c1d79812f428860e6f624835851d6f3ecd86bbb3

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 22
model name      : Intel(R) Celeron(R) CPU          220  @ 1.20GHz
stepping        : 1
microcode       : 0x36
cpu MHz         : 1199.859
cache size      : 512 KB

fast, like ninja


09/12/12 16:33:17 Bitcoin version v0.7.0rc2-29-gd078739-dirty-beta (2012-09-12 10:20:46 -0400)
09/12/12 16:33:17 Using OpenSSL version OpenSSL 1.0.0e 6 Sep 2011
09/12/12 16:33:17 Default data directory /home/zevus/.bitcoin
09/12/12 16:33:17 Used data directory /home/zevus/.bitcoin
09/12/12 16:33:17 Error: Couldn't open socket for incoming connections (socket returned error 97)                            (<------- jaja)
09/12/12 16:33:17 Bound to 0.0.0.0:8333
09/12/12 16:33:17 Loading block index...
09/12/12 16:33:17 dbenv.open LogDir=/home/zevus/.bitcoin/database ErrorFile=/home/zevus/.bitcoin/db.log
09/12/12 16:33:36 LoadBlockIndex(): hashBestChain=0000000000000581f901  height=198463  date=09/12/12 15:56:02
09/12/12 16:33:36 Verifying last 2500 blocks at level 1
09/12/12 16:34:05  block index           47752ms
09/12/12 16:34:05 Loading wallet...
09/12/12 16:34:05 nFileVersion = 70002
09/12/12 16:34:05  wallet                   66ms
09/12/12 16:34:05 Loading addresses...
09/12/12 16:34:05 Loaded 12605 addresses from peers.dat  132ms
09/12/12 16:34:05 mapBlockIndex.size() = 198468
09/12/12 16:34:05 nBestHeight = 198463
09/12/12 16:34:05 setKeyPool.size() = 1
09/12/12 16:34:05 mapWallet.size() = 0
09/12/12 16:34:05 mapAddressBook.size() = 1
09/12/12 16:34:05 Done loading
09/12/12 16:34:05 ThreadRPCServer started
09/12/12 16:34:05 send version message: version 60002, blocks=198463, us=0.0.0.0:0, them=0.0.0.0:0, peer=127.0.0.1:0
09/12/12 16:34:05 AddLocal(ww.xx.yy.zz:8333,1)
09/12/12 16:34:05 IPv4 eth0: ww.xx.yy.zz
09/12/12 16:34:05 ThreadMessageHandler started
09/12/12 16:34:05 ThreadOpenConnections started
09/12/12 16:34:05 ThreadOpenAddedConnections started
09/12/12 16:34:05 trying connection 1.3.3.7:8333 lastseen=346518.8hrs
09/12/12 16:34:05 ThreadSocketHandler started
09/12/12 16:34:05 accepted connection z.y.x.w:55240
09/12/12 16:34:05 ThreadIRCSeed exited
09/12/12 16:34:05 ThreadDNSAddressSeed started
09/12/12 16:34:05 Loading addresses from DNS seeds (could take a while)
09/12/12 16:34:05 connected 1.3.3.7:8333
09/12/12 16:34:05 send version message: version 60002, blocks=198463, us=ww.xx.yy.zz:8333, them=1.3.3.7:8333, peer=1.3.3.7:8333
09/12/12 16:34:05 GetMyExternalIP() received [ww.xx.yy.zz] ww.xx.yy.zz:0
09/12/12 16:34:05 GetMyExternalIP() returned ww.xx.yy.zz
09/12/12 16:34:05 AddLocal(ww.xx.yy.zz:8333,5)
09/12/12 16:34:05 send version message: version 60002, blocks=198463, us=ww.xx.yy.zz:8333, them=z.y.x.w:55240, peer=z.y.x.w:55240
09/12/12 16:34:05 Added time data, samples 2, offset -30 (+0 minutes)
09/12/12 16:34:05 Flushed 12605 addresses to peers.dat  140ms
09/12/12 16:34:05 receive version message: version 50300, blocks=197392, us=ww.xx.yy.zz:8333, them=z.y.x.w:8333, peer=z.y.x.w:55240
09/12/12 16:34:05 accepted alert 1016, AppliesToMe()=0



worked!   though it looked a bit odd

i'll test it, it'll be a bit though since this kimsufi is godawful slow

Anyone?

I'll trade my totally busted 5870 for a 5970 heatsink.  All it's missing is the back plate, shroud, and various shiny parts.  I can even leave the fan on it!

I want some Negro.  

ed: oh,aha!  I see he responded about it here... ok, nice =p

hmm.. that looks like some fancy candy, what, with that label and all

ahh, reminds me of Adam's Apples subtitles, 'for the sake of fuck', one of my favorites

ok, carry on

about $20 a day after electricity, usually around 5000g/hash, but i can get up to 6,500.  i guess that qualifies as 'medium'. 

but there needs to be another category.   when i sold everquest items, i had a few people that bought a couple grand worth, a whole bunch of ppl that bought a few hundred, one person that bought around $10,000 worth of goods, and another that spent about $30,000 (and the lingo for that is "super-whale" and "whale").     i would say someone that's around 15ghash or so would be a "big" miner, but it needs a "huge" or "i use more electricity than a small village" category

09/08/12 22:30:44 accepted connection 37.143.73.55:53935
09/08/12 22:31:17 disconnecting node 37.143.73.55:53935
09/09/12 16:00:16 accepted connection 37.143.73.55:56767
09/09/12 16:00:57 disconnecting node 37.143.73.55:56767
09/10/12 01:32:03 accepted connection 37.143.73.55:57247
09/10/12 01:32:03 disconnecting node 37.143.73.55:57247
09/10/12 07:00:34 accepted connection 37.143.73.55:65351
09/10/12 07:02:14 disconnecting node 37.143.73.55:65351
09/11/12 06:18:21 accepted connection 37.143.73.55:50701
09/11/12 06:18:21 partner 37.143.73.55:50701 using obsolete version 0; disconnecting
09/11/12 06:18:21 disconnecting node 37.143.73.55:50701
09/11/12 18:08:52 accepted connection 37.143.73.55:52619
09/11/12 18:08:53 send version message: version 60002, blocks=198335, us=5.9.24.81:8333, them=37.143.73.55:52619, peer=37.143.73.55:52619
09/11/12 18:08:53 receive version message: version 31900, blocks=1751330577, us=192.168.1.4:8333, them=5.9.24.81:8333, peer=37.143.73.55:52619
09/11/12 18:10:10 disconnecting node 37.143.73.55:52619

any significance to that?   just noticed it in log, older logs have version msgs pruned, i manually killed latest login.   shouldn't the client have done it automatically, w/ version message below 32000?  

hmm, well, given that it says obsolete version 0 up above, i guess he's trying different things

ed: oh, just noticed the 192.168.1.4 thing going on// akakak

i'll trade you a broken 5870 missing back plate and fan for a reference 5970 heat sink

the 5870, uh, gets warm when i turn on the computer.

gangnam style

what about this one:


09/10/12 02:54:36 received block 0000000000000305d54f
09/10/12 02:54:37 SetBestChain: new best=0000000000000305d54f  height=198085  work=471019712921273781188  date=09/10/12 02:54:16


09/10/12 02:55:41 received block 0000000000000600c45a (from p2pool 'peer' share)
09/10/12 02:55:41 ERROR: ProcessBlock() : already have block 198085 0000000000000600c45a

yet blockchain.info shows

https://blockchain.info/block-index/286598/0000000000000600c45a2c0eab5e72939a45160c941d5658937a75f048dcef15

it received at 2:53:28 (afaik, the 'received' times reported on there are accurate'

https://blockchain.info/block-index/286596/0000000000000305d54fd22241482f7d8dae6a7ac947483a9e37249176e37632

the eclipseMC one was received at 2:54:34, i got it at 2:54:36, and passed it out to about 30 people


what other explanation is there, then someone that should be using addnode, or open up more connections?  there are a decent amt of nodes that actually received this block, even though i got it a full minute late

more stuff:

http://nogleg.com:9332/static/share.html#0000000000000600c45a2c0eab5e72939a45160c941d5658937a75f048dcef15

the parent share was seen like 2 1/2 minutes earlier

upstream bandwidth limitation?  that's all i can think of

another edit.. yeah, ok, so opening up more connections wouldn't help.  addnode might.

but  blockmaxsize=10000  in bitcoin.conf would be even better!

i wouldn't buy an entirely new system for them

but if you have extra PCI-e slots to fill, why not?

i mean, the 5830 I bought new 1 1/2 yrs ago is worth like $10 more than what I paid for it.  

i guess the trick is to know when the right time is to sell em all

and i would say at least not for 6-8 weeks.... if you wait too long, you'd also want to hold off selling for a month or so, lest ebay and other places be overloaded

edit: have to cancel this offer, agreed to a deal with someone else

haha

well, it had a partially stripped screw, that i fully stripped

and i wasnt in a great mood, and i dont have a power drill (the rubber band method didnt work).  i guess i could have waited until morning and borrowed one from a neighbor, but...

so, yeah, I just peeled up that backplate and started twisting

and a whole bunch of stuff got scraped off.    the backplate actually broke and  left a small piece with the screw

well, the documentation seems to suggest that you must enable ipv6 by including USE_IPV6=1, but the build file has USE_IPV6:=1 as default.   i tried changing that to USE_IPV6=- and USE_IPV6=0, still results in same error

that being:

09/09/12 23:28:43 ThreadMessageHandler started
09/09/12 23:28:43 ThreadOpenConnections started
09/09/12 23:28:43 trying connection xxxx lastseen=0.0hrs
09/09/12 23:28:43 ThreadOpenAddedConnections started
09/09/12 23:28:43 ThreadOpenAddedConnections exited
09/09/12 23:28:43 ThreadSocketHandler started
09/09/12 23:28:43 ThreadIRCSeed exited
09/09/12 23:28:43 Error: An error occurred while setting up the RPC port 8332 for listening: Address family not supported by protocol
09/09/12 23:28:43 ThreadRPCServer exited
09/09/12 23:28:43 Flush(false)
09/09/12 23:28:43 blkindex.dat refcount=0
09/09/12 23:28:43 blkindex.dat checkpoint
09/09/12 23:28:43 connected xxxx
09/09/12 23:28:43 send version message: version 60002, blocks=183152, us=0.0.0.0:0, them=xxxx:8333, peer=xxxx:8333
09/09/12 23:28:43 ThreadSocketHandler exited
09/09/12 23:28:43 ThreadMessageHandler exited

to make it work, one must comment out or remove the following in bitcoinrpc.cpp:

        acceptor->open(endpoint.protocol());
        acceptor->set_option(boost::asio::ip::tcp::acceptor::reuse_address(true));

        // Try making the socket dual IPv6/IPv4 (if listening on the "any" address)
        boost::system::error_code v6_only_error;
        acceptor->set_option(boost::asio::ip::v6_only(loopback), v6_only_error);

        acceptor->bind(endpoint);
        acceptor->listen(socket_base::max_connections);

        RPCListen(acceptor, context, fUseSSL);
        // Cancel outstanding listen-requests for this acceptor when shutting down
        StopRequests.connect(signals2::slot<void ()>(
                    static_cast<void (ip::tcp::acceptor::*)()>(&ip::tcp::acceptor::close), acceptor.get())
                .track(acceptor));

        // If dual IPv6/IPv4 failed (or we're opening loopback interfaces only), open IPv4 separately
        if (loopback || v6_only_error)
     

then it does:

09/10/12 00:00:22 ThreadMessageHandler started
09/10/12 00:00:22 ThreadOpenConnections started
09/10/12 00:00:22 trying connection xxxx lastseen=0.0hrs
09/10/12 00:00:22 ThreadOpenAddedConnections started
09/10/12 00:00:22 ThreadOpenAddedConnections exited
09/10/12 00:00:22 ThreadSocketHandler started
09/10/12 00:00:22 ThreadIRCSeed exited
09/10/12 00:00:22 connected xxxx
09/10/12 00:00:22 send version message: version 60002, blocks=183152, us=0.0.0.0:0, them=xxxx:8333, peer=xxxx:8333
09/10/12 00:00:22 Added time data, samples 2, offset -1 (+0 minutes)
09/10/12 00:00:22 Flushed 0 addresses to peers.dat  57ms
09/10/12 00:00:22 receive version message: version 60002, blocks=198073, us=xxxx:44586, them=xxxx:8333, peer=xxxx:8333
09/10/12 00:00:23 received block 0000000000000045a7f8 from xxxx:8333
09/10/12 00:00:23 SetBestChain: new best=0000000000000045a7f8  height=183153  work=345239274296880467532  date=06/05/12 18:48:15
09/10/12 00:00:23 ProcessBlock: ACCEPTED

and so on

sure, if you're moving up to 150ghash or so

ed:

oh , haha, nm, i see.  moving up to mid-teens ghash. 

i got lucky and got two in a row on maxbtc, difficulty was like 1.6m then, though

I specifically disabled ipv6 on that machine.... it's not worth the resources on one of the kimsufi atom's (esp. when you get unlucky and get a 1.4 atom)

though, it seems a bit odd that some ipv6 functions cause it to not work, when you disable it

Why are orphans that are valid not credited, anyway?  

My current block value is 50.65, everyone else is around 50.35 (because they are using default bitcoind settings, probably).   But, because of including more transactions, my shares are more likely to be orphaned, esp. by people on slow connections.  

I get the feeling that it would be better to include 0 transactions on P2P network, to guarantee your shares vs the ppl with low bandwidth/high latency connections?

if I were to solve a block, I'm not worried about it being orphaned on main network at all

ed:  hmmm, actually, I suppose it wouldn't grab the whole thing, so each would have an equal chance of being orphaned, eh?    so, nm

i have the informations that you seek

uh, i'll trade a broken 5870 for it?     i'll probably scavenge the fan off of it, but I'd leave the heat sink there.

though i've been told that it's beyond repairable. 

i think the GPU itself is undamaged, but the se quadrant of the card essentially got sandpapered