[RC5] Problem with buffer limmits.

Bryan Talbot btalbot at ucsd.edu
Tue Oct 26 13:45:22 EDT 1999


I assume you're referring to the client and not the pproxy, right?  One 
possible work around for occasional situations like this is to run two (or 
more if needed) versions of the client.  Each one will work about 1/N as 
fast as usual making the in-buffer files last N times as long.  Give each 
client its own buffer files and then flush them when you return.  Certainly 
not ideal, but easily doable for a small number of clients.

The other possibility is to allow the client to dial out and update the 
buffers automatically when needed.  That is assuming that you don't have a 
problem with the client disconnecting when it's done so you're not 
connected for the rest of the weekend ...

-Bryan


At 06:29 AM 10/23/99 , William Scott Lockwood III wrote:
>Are we going to do something about these buffer limits anytime soon?
>
>I'm leaving for the weekend - My new Athlon 500 will run out of blocks in
>about 24 hours, and will crunch lots of random blocks after that - some of
>which I may not get credit for if lots of other people have generated the same
>random blocks.  This has happened to me before.  I once got an e-mail from
>D.Net about it.  They seemed to think I was spamming the keyserver - NOT!
>
>Haven't we proved yet that with faster and faster CPU's, the block limits just
>plain don't make sense?  We should AT LEAST double them for people with
>PII/III and Athlon CPU's!

=====================================================================
CAUTION: The mass of this message contains the energy equivalent
of 85 million tons of TNT per net ounce of weight
=====================================================================
          "I think not!" said Descartes, who promptly disappeared.

--
To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest



More information about the rc5 mailing list