I'm describing the problem here from my personal perspective, bitcoind running on my desktop, which has a slow atom cpu and is frequently under various other load conditions), poclbm running on dedicated miner with a 5970.
Problem is this: after running bitoind for a while, I see "Problems communicating with bitcoin RPC, data: None" messages on the miner. The freuqency of these increases over time (presumably with size of bitcoind's transaction cache). Getwork interval is at 5s.
It has been suggested to used git-version with -limitfreerelay=1. I tried that and it might have taken some pressure, but the problem still occurs.
After a couple of hours my miner doesn't do any work any more, because getwork continuously fails.
I'm quoting from #bitcoin-dev to elaborate the problem and possible workarounds and/or solutions:
ArtForz, am running into slight getwork troubles at 66 tx cache size already? does that make sense?
nope
molecular: what's the trouble? getwork taking long time to return?
do you have a really slow disk or high I/O load?
yes
getwork takes several seconds
at some point it takes longer the my getwork interval (currently 5s)
I have slowish cpu (atom)
yeah, that might do it
which is also under load from other shit since it's my desktop
this made sense to me, ArtForz kept analysing:
can you check if it's actually pegging the CPU?
because here it seemed to be more I/O than CPU bound
I can't see it using cpu in htop. trying to verify that
there's some iotop app? what's it called?
iotop ?
I'm emerging iotop on my desktop, while the chatter continues:
what stalls getwork is CreateNewBlock
and I suspect *that* is more I/O than cpu bound
I don't really know why though, it doesnt *look* like it does lots of I/O
CreateNewBlock is in O(n) with n == ?
yes
ArtForz, why do you think IO might be the problem?
it's all in RAM
yes, it does a fopen/fseek/fread/fclose for blk0001.dat
so that's probably what slows it down
(if the input is from a tx thats already in a block)
and it does a lookup in blkindex DB for every call, too
"if (!txPrev.ReadFromDisk(txdb, txin.prevout, txindex))" <- you mean this, tcatm?
molecular: yep
yeah, that sounds like it might cause slowdowns, especially if you dont have enough free memory to keep blk0001 cached
how does that code find the transaction in blk0001.dat? is there an index for txhash -> blkhash?
yes
blkindex.dat for txhash->offset
urrr... why the F are we not caching that stuff?
slush, workaround will relieve the pain, but in the end we should fix stuff in bitcoin
it's not like tx can magically appear in blocks while no new block comes along
I think ArtForz might've just identified the root of the problem?
could be...
can't think of a elegant way to work around it though
thats... really weird
well, we do 2 things really with that prev tx
1. check if it's in a block (can be cached between block updates)
2. if it is, get the value of the output referred to (same thing)
I'm stopping here and backposting link to #bitcoin-dev...