Maximum size of Buff-in.rc5

[Dougal]

Hi Guys,

I'm having a small problem getting blocks to one of my non network machines and I hope you can help me out. The machine is a T-Bird 900 so it's rather hungry for blocks. I simply pause and copy the buffers to a networked machine each morning to fluch. The problem I'm getting is that I can't seem to pull enough blocks to keep it busy over the weekend or if I'm out of the office for a couple of days. I've set the work-time threshold to 480 hours and although when it starts to fetch it shows it will pull 15429 work units, it stops at 2724. These are todays figures but they are always about the same. The file size goes up to about 60K then stops.

Is this a limit that I'm hitting or do you think I'm missing something else somewhere?

Below is my ini file from the fetch/flush machine:

[misc]
project-priority=RC5,CSC=0,DES=0,OGR=0

[networking]
keyserver=10.2.1.157
nofallback=false
disabled=no
autofindkeyserver=no

[rc5]
fetch-workunit-threshold=0
fetch-time-threshold=480
preferred-blocksize=33

[des]
fetch-workunit-threshold=1

[ogr]
fetch-workunit-threshold=0

[csc]
fetch-workunit-threshold=1

[buffers]
alternate-buffer-directory=
frequent-threshold-checks=1

Any pointers would be great.

 

[Ken g6]

have you tried Polo's Sneaky solution?

 

[Dougal]

Hi Ken,

To be honest I'd forgotten about sneaky. Downloading and testing it now.

Thanks

 

[ZapZilla]

Try setting the

fetch-workunit-threshold = 500 (I believe that 500 is the max setting).

fetch-workunit-threshold = 0 allows for the default number of blocks (24).

With 500 setting you might not need a fetch-time-threshold at all.

500 2^33 RC5 blocks should feed your comp for quite a while.

 

[Scraper]

There's a max to the bloks indeed as zapzilla said: 500
And your bloksize is 33, that means that in theorie the client can get 16000 wu. (500 x 32) The only problem is that the proxy's don't always have blocks of 32 wu's. Result: less WU's in the 500 bloks.

 

[LeBlatt]

AFAIK, 500 is the max number of packets ; fetch-workunit-threshold represents a number of blocks. So I'd say fetch-workunit-threshold=16000 and the client should fetch 500 packets, trying to get as close as possible to 16000 blocks. Or am I misled ?

 

[nickdakick]

<< the client can get 16000 wu. (500 x 32) >>



Even if the wu's are not all 32*2^28 it should be enough to keep a Tbird 900 busy over the weekend.

Then again it depends how long your weekends are.

 

[PeterN]

In fact there are two limits to the in-buffer, the 500 packet as mentioned, but also a 61k limit to the file size.
That is where your problem lies, Dougal.

If you use the import function on the non-networked client, you can add as much in-buffers as you want.
I once made a buffer of almost 100k, since I was going on holiday.
This is also easier, since you can do it simultaniously. You don't have to pause the client.
The out-buffer can just be relocated, while the client is running.
You won't loose any valuable clock-cycle.

The syntax is:

[path/]dnetc.exe -import [path/]buff-in.rc5

You can give this command through the run-option in the start menu in Windows.

I think the problem in the low block number is not in your fetching client. The settings above look correct to me.
I think, the proxy your fetching from is having a highly defragmentated keyspace in it. That's why your not getting the maximum amount of blocks.

Hope this helps.

 

[Dougal]

Hi all,

Thanks for the input. PeterN, That's basically how I'm handling things at the moment using the import option for long periods of non-connectivity. It's all come to light because I was away from work last week for three days with flu and on top of the weekend it left the machine dry. I'm hitting the 61K buffer limit with the fetch which is where the problem starts. It's just a pain to have to use import all the time. I think it's time to get this machine networked like all the rest.

Thanks again for the help guys

 

[LeBlatt]

You can avoid the -import hassle with Polo's Sneaky.

[edit]Hmmm... guess you'll be better off with the english version.

 

[Kilowatt]

You can add:

[rc5]
fetch-workunit-threshold=(What ever you want, up to a point)
preferred-blocksize=33
expertmode=1

And buffer alot more than 500.

I'll clean out my pproxy by loading up my GUI based clients with about 2000 - 3000 WUs sometimes.
Since the pproxy won't issue first in/frist out, that keeps the pproxy from holding old uncracked WUs for too long.
I'll do this about once a month to get a freash load of WUs.

The GUI clients won't flush untill all those WUs are done, but you can manualy flush the client every now and then.

BTW, I'm still running the 8010 versions, I don't know the limits of the 8012 clients, or if they even changed.