• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

DNet(Bovine) is making a request

How does this affect PProxy setup? I know how/where to make the changes in the client ini file, but how do I set the pproxy to "fetch" the size of blocks I need, or do pproxies collect blocks of all sizes?😛

Osmo.
 
Proxies collect all sizes. It would be nice to have the minimum block size raised from 2^28 to maybe 10^28, that may be a bit high, but it sure would cut the traffic down tremendously.

Just my 2 cents, though.

 
Mika has said before that he can easily notice the difference between lots of small blocks and fewer large blocks. DNet must be the same, since their keyservers are just pproxies at heart.

As far as local pproxies, they don't have a block setting. It appears that they will take whatever size the DNet keyserver sends them (2^28 up to 2^33), but they will break large blocks (2^33) down into smaller blocks if a client requests smaller blocks. The bad thing is, they won't get reassembled on the way back to DNet.

Best bet is: Use 2^33 sized blocks, and be sure "checkpoint" files are enabled to minimize block loss in case of crashes.
 
I'm willing to work with them, but perhaps they need to look to their software then as well. I have many of my machines set to accept 2^32 or 2^33 packets and I still see an awful lot of 1 and 2 WU packets get returned back through my pproxy. I know my clients are requesting larger blocks, but the pproxy is not giving them any.

I've also noticed lately that when my pproxy is requesting blocks from Mika's, it will request a block of 64 and instead gets a barrage of puny packets back.
 
The problem is that the pproxy is receiving small blocks from d.net.

Proxies (both d.net and pproxies) have to break up large blocks when small blocks are requested. So if someone requests lots of small blocks, the chances are, the next person (who may request large blocks) will end up getting small blocks.
 
I'm a bit puzzled. Why doesn't DNet make those checkpoints an option that is on by default ? Does it affect performance ?

And why don't they set the clients to get 2^33 blocks as the standard value ? I think that a lot of people don't even know the difference between those block sizes...
 
Don't know the answer to your first question, but the second is that there are still a lot of slower machines out there that would take forever to complete a 2^33 packet (32 WU's or "blocks&quot😉.

Russ, NCNE
 
Ok so I need to set the checkpoint file. Looking at the configuration it asks for a location; so I need a path to the file and the name of the file-what file type is it? I assume I name it something like "ckpoint.*". Thank you.
 
You don't need to set a full path, just a file name. It doesn't have a particular file type, just make sure you use a name that doesn't already exist in that directory, I use DNETCCHK. It doesn't even really need an extension.
 
The main reason you get small packets even when you requested big packets is that the keyspace is VERY fragmented compared to when it started. After all, we've been through the keyspace once already and are now on our way BACK through it, picking up all the keys that were never returned the first time through.

The fragmentation leaves a lot of little 2, 3, 8, etc, size blocks all over the place. Sometimes you get great big 32 blocks, sometimes you get a 1 block. It is a necessary procedure to "fill in the gaps" in the keyspace...

JHutch
 
I've noticed the difference on my proxy too. The log files get to be fairly large when it has to type out 32 lines of text that could be done in one line of text. My proxy is only averaging about 35,000 blocks a day right now and my log files are close to 5 megs in size. Just imagine what Mika's are and even better yet, DNet.

Jay
 
For fragmentation, couldn't they use a new keyspace and only break it up into 2^33 blocks, and use the fragmented keyspace for smaller blocks breaking them into the requested sizes? That would make the most sense to me at least. You would be using a large keyspace only for 2^33 blocks, and the fragmented keyspace for everything else.
 
Actually, towards the end of the project we will be using mostly smaller blocks anyways as the keyspace will be soooo fragmeted. That is unless someone finds the winning key before we hit the 50% mark. 😉

Jay
 
Jator, I hadn't thought that far ahead, but you are right. It will definitely get worse as we continue, but perhaps a strong push to use large blocks could extend the inevitable.

I would appreciate (and use) a DNET keyserver that is dedicated to giving out just large blocks. If I follow their logic, a keyserver that only handed out and received 2^33 size blocks could handle many more client connections in a day than a non-specialized keyserver. Rough estimate would be 200% to 400% more efficient.
 
I would love to use 2^33 blocks. But just this morning I was regulating a machine of mine that was constipated, and I uploaded 166 packets to Mika's containing about 3500 work units. Then I downloaded 166 packets for a total of about 800 work units! That is not enough work units to last even 2 days, so I uped my in buffer to 300 packets and downloaded 100 more packets. I got an extra 250 work units! I have the client set to perfer 2^33 packets, but I guess there weren't many to go around this morning. If I suddenly get all 2^33 packets, my computer will download 9600 workunits. That should last me a while. 😉

Anything D.Net can do to hand out larger packets would be appreciated by me.
 
if you set it to buffer for number of hours rather than number of packets, it should work round that little problem
 
You must log in or register to reply here.
Back
Top