I'm confused...

[Russ]

Not unusual, really. If I'm making the correct assumptions, a buff out file will be smaller if packet size is set at 2^33, than it would be at 2^28? Is it a LOT smaller?

Reason I ask is that I've been playing with settings on a few machines and 500 WU's, when set at 2^28, sucks up about 60K of space, but 500 WU's at 2^33 only takes 2K? Can there be THAT much difference?

If so, than I'm definitely not using 2^28 anymore. Is there any reason NOT to use 2^33?

Russ, NCNE

 

[Russ]

Oh, and what does "randomprefix=" do?

Russ, NCNE

 

[Viztech]

You are learning well, grasshopper one.

No reason at all to NOT use 2^33 packet size, except with the clients slower than say a 486.

As for the random prefix, that is a good question. I wish that we could set it to crack only in the end part of the keyspace so as to increase our chances of not getting dupes.

viz

 

[PeterN]

Russ,

The random prefix determines what random blocks the client is going to crack in case you run out of blocks.

I tried to figure out what the setting should be in order to crack only randoms at the end of the keyspace, but I never discovered it (or didn't try hard enough )

Also I figured there's not much sense in altering this setting, because everytime the client connects to a keyserver, it goes back to the range that corresponds with the blocks just fetched.

Hope this helps.

 

[MadMerc]

Russ,

there is one reason not to use 2*33's but i dont think it applies in your case - when you have unreliable machines, or as in my case, stupid users who turn the machines off without shutting down, you lose less blocks if its cracking a small one rather than a large one - i tend to use 30-31 depending on machine speed

 

[PeterN]

MadMerc,

In that case you can use the checkpoint feature.
It saves a block the client is working on every few minutes or so.
You can compare it with the auto backup in many wordprocessors and such.

Take a look in the 'manual' for the settings.

It's better to set the block size as high as you can, because the client does not have to switch much between blocks. Less switches and less disk access means higher speed (Agreed, it isn't much, but still )
Ofcourse I agree with slower machines (<P133) being set to a lower block size.

Peter

 

[Moose]

2^33 packets are 32 times larger than 2^28. We encourage participants to use 2^33 pcakets whenever possible. It helps with network load. logs file sizes and general overall project health. If you consider the amount of traffic caused by 32 2^28 packets as compared to 1 2^33 packet you can see how things can grow.

This helps out all you pproxy users as well. Putting reduced network load to pproxies and on ppstats users. A pproxy only makes 1 entry for a 2^33 packet where it has to make 32 entires for the same amount of work when using 2^28. well for example, say Team AnandTech does 500000 blocks in a day. If everyone uses 2^33 blocks the pproxy would only have ~15,625 flushes lines in the logs compared to 500,000 lines if everyone was using 2^28. Now I know not everyone uses 2^28, this is just to illistrate the differences.

The packet takes 32 times longer to complete but when you have a machine that is doing a 2^28 block every 2 to 3 minutes that's really not a long time. I know may people want to make sure they get the largest number of blocks done in 1 day, but it will even it self out overtime.

If you are concerned about losing work of a large packet, configure check point files to be used. They save every 10% or 10 minutes whichever comes first. Everyone should configure to use checkpoints reguardless. They will help you save work and keep your rate up.

So you might be asking what I'm trying to say. Well its simple use 2^33 as much as you can. Its good for the project and the team in general.

On a second note. Changing the randomprefix should not be done. You may change it to a keyspace that is not open. We do not currently have all keyspaces open and if you change it to a keyspace that is not open the blocks are discarded and you will not gain credit for the blocks. The client selects certain keyspaces based on the last non random block. Changing to what you beleive to be a large keyspace that you can submit will more than likely result in lost work. We generally do not open keyspaces untill they are needed.

Hope this helps.
moose

 

[MadMerc]

message recieved and understood

i'll set them to 2*33 with checkpoints as soon as I get a chance

 

[PeterN]

thanx Moose,

This is the way I wanted to say it.

Always nice to see gurus of DNet answering questions in our forum.

 

[Batti]

Thanks, Moose! 2^33 it is.

One oddity I've never understood is that when you configure a checkpoint file, the blurb discourages you from doing so unless you are in an unreliable environment. I presume this is because the write to disk could potentially lower your key rate?

 

[BurntKooshie]

The client writing to the disk does slow it down, but so little that its negiligable. Running the 2 ^ 33 blocks on my Cyrix caused a whopping 1% increase, because it wasn't loading blocks as often and such.

 

[Dougal]

Moose,

How does changing the block size on a client affect a PProxy? What I mean is, can the pproxy put together smaller blocks to make up a 33 WU block or does it have to request them from the next keyserver in the chain? If the later is true, what would happen to the smaller blocks already in the pproxy?

 

[imported_Thunder]

Dougal,

I'll give these a shot...

It helps a proxy due to at least a few reasons. First, and foremost, it greatly reduces the size of the log files generated! The proxy adds 1 line to it's logs for every block that's submitted and sent. It doesn't matter whether the block is 1 WU or 32 WU's... the same amount of space becomes occupied in the log. (Naturally then, machines using 2^33 blocks would require 1/32nd of the log space of the same machines using 2^28 blocks). I assure you (from checking out Mika's logs once) that log files can get absolutely HUGE. Secondly, the amount of traffic on the network is reduced by the same proportion. Yes, the actual volume of data is negligible, but you have to keep in mind that a pProxy can only handle 32 simultaneous connections. In particularly large networks (like Mika's proxy), a machine cracking the bigger blocks will take 1/32nd the amount of time to fetch/flush, thereby freeing up the connection for another machine to do the same.

Of course there are lots of benefits along the line in terms of bandwidth used, connection frequency, etc. etc. These benefits are all small when viewed at the local level, but when you take into account all of d.net.... I'm sure the bigger keyblocks help considerably.

That help?

-Brian

 

[Dougal]

Hi Thunder,

I'd grasped the basic idea about network traffic and log sizes but what I was trying to figure out is that if my pproxy is already loaded with smaller blocks, would these just be ignored by a client asking for 2^33 WU blocks or can the proxy do some magic to make sure they all get processed. I was just trying to make sure that I wasn't going to end up with a proxy full of unwanted smaller blocks.

 

[PeterN]

Dougal,

As far as I understand:
The client can request for large blocks, but the proxy determines what the client is receiving. A large block can be split up by the proxy.
If there are only small blocks in the proxy-buffer, then these will be sent out. So don't worry about ending up with 'unwanted smaller blocks'.

IMO, the proxy can not make a large (2^33) block out of smaller (2^28) ones, because the chance they are adjacent to each other is very slim.

 

[Dougal]

PeterN,

Thanks for that. I was kinda hoping that would be the case. Consider the clients changing blocks sizes as we speak.