RC5 - DNet is reissuing keys

[Joe O]

See Bovine's plan, posted Sunday.

Does anyone else find the first graph confusing?

What about subspace 225(?) on the second graph?

 

[awal]

The first graph seems backwards, shouldn't the horizontal axis by reversed (lowest --> highest).

It seems like we are missing an entire key subspace, either a dnet proxy lost work or dnet never handed it out.

 

[JonB]

The subject line is true (Dnet is reissuing keys), but may be easily misinterpreted. It appears that the keys being reissued are the missing ones they don't expect to be returned, ever. Their graph shows that from 4 days out to 40 plus days, only 75% of the issued keys have come back.

They know which ones come back, therefore, they feel they can safely re-issue that 25% group of keys without concern of duplicating work. This is why we are getting so many tiny, tiny blocks of work. It is very rare to get a 32 work-unit block anymore. Most are of the 2, 4, but less than 8 unit size. Very inefficient, but it will fill in the holes.

So, if you are running a pproxy, keep your input buffer small. If you buffer more than 10 or 20 days worth, it is almost certain that DNet may reissue some of the older work units. If the new recipient turns them around faster than you, you have wasted precious CPU time.

 

[ViRGE]

I actually find it interesting how they're doing this. It's still recycling the unreturned blocks, but the prediction impresses me a bit, and means that we will fill in the missing blocks faster than before under the 45 day policy. Unfortunately, JonB is also right in that this highlights what's going to happen as we work our way though the remaining space - keeping block for a long time will become more and more impracticle as the recycle times shorten. If you are running RC5, make sure not to be hogging the blocks in any 1 client(pproxies, far which are fewer in number, are ok), and make sure your clients make regular net contact, otherwise someone may be beating you to the punch.

 

[burnedout]

All my clients vary. Some hooked to broadband are 4 hours. I think the max is three days on others.

Glad this was posted.

 

[gogeeta13]

very good post.

 

[Poof]

Agree with gogeeta. This seems to suggest that the days of holding back to do big flushes, is pretty much at an end. :Q

 

[EagleKeeper]

Many systems that were fielded, may have been cut off without a chance of being dumped.

When the McCowen flap hit, I had 8 systems that were going to be Sneakyed. Those systems got pulled and wiped while I was out. Close to 1MB of output files were accumulated.

Have lost another 2-3 MB of output do to E-Mail transmissions from remote sites being garbled.

 

[Wellcky]

Are we starting over!! :Q

 

[JonB]

No, nothing is starting over. DNet is just making it a plain as they know how that a lot of keys never got returned, so they need to reissue them. Lots of reasons as to why keys don't get returned.

Crashed PCs, crashed hard drives, corrupt floppies, power outages, boredom, etc...

At least their database has enough resolution to know what has been returned to such minute detail.

14% left to check; <200 days until 100% completion, therefore the odds are now approximately 50/50 that it will be found in the next 100 days.

 

[ZapZilla]

[Pessimist mode] Ah, yes. Though, I wonder what the odds are that the elusive key is actually in the "unchecked keyspace"... [/Pessimist mode]

 

[BGod]

I think we just found where the missing keys went -> TA Week Stats by E-mail

 

[networkman]

765589!? That's a whole lotta blocks in 1 day! :Q

 

[Polo]

What a dump !!!

Very very impressive !!!

I hope there isn't much duplicates...

 

[ProviaFan]

I'm running a pproxy right now on my server (500mhz celeron), because I have a dialup connection on a shared phone line, so it can't be up all the time. Thus, I have been running the proxy in "lurkonly" mode, so it will automatically flush when I'm online. This keeps my other computer (a 900mhz duron) from constantly triggering a connection to the internet to send a unit. The proxy queues 2000 work units, and my "farm" (the 500mhz plus the 900mhz) puts out around 4mkey/sec. Since this is probably going to affect me, is there any way that I can set up the client on the network to queue enough blocks for one day, and then send those and get new ones only when it has totally exhausted its queue? Thanks.

 

[BGod]

Setting frequent-threshold-checks=3 to something like 1 should do the trick.

I'm one of the hold outs from the old days when the proxies would dry up/lock up and have every machine set to buffer at least 4 days worth of blocks. My pProxy holds another weeks worth of work by it's self. As long as FIFO works I don't have any fears about buffering that much work.

 

[ViRGE]

Originally posted by: networkman
765589!? That's a whole lotta blocks in 1 day! :Q

We'll have to see how the stats turn out. Numbers like that make me nervous, although if they are dupes, the pproxy should catch them to a certain extent.

 

[Orange Kid]

766879 netted

jayBee666's stats

--------------------------------------------------------------------------------
Hear the Scream of the Butterfly
--------------------------------------------------------------------------------

Rank Blocks
Overall: 2401(52) 3,601,539
Yesterday: 43(7512) 68,371


a 700,000 loss due to dupes?

 

[ViRGE]

Well, something's fishy, 68K blocks vs. 770K. I'm starting an investigation tonight.

 

[JonB]

looks like 10% got counted. A few weeks ago, one of my fastest machines ran Randoms for 36 hours. When it dumped, I only got 10% credit because of dupes.

That may be the new penalty for machines that can't stay connected.