What does this mean?

[PieDerro]

When I started up my RC5 client just then, it came up with a message saying "Buffer is locked. Waiting (at most) 10 seconds..."

This same message comes up also when I try to update my buffers. What is going on?

Thanks for any help 🙂

 

[dennilfloss]

Right-click on your systray cow and choose 'restore'. (If yours is installed as a service, type dnetc -config in the start-->run window.) This opens the client window. Right-click on window and choose 'configure'. Enter 2 for Buffer and Buffer update options. Check if 5) Disable Buffer updates... says yes or no. If it says yes, enter 5 and change it to no. Press enter. Enter 0. Enter 0.

 

[ViRGE]

Actually, I think it's a bit more complicated than that.🙁 In order to unlock a locked buffer, you need to use the -forceunlock <fn> command. Just open up a run window, get the client pointed to in the run window, and add -forceunlock <fn> to the end of the run line; where <fn> will be the specific buffer name(probably rbuff-in.rc5). That will unlock the buffer, and you can continue on your marry way, for the most part.😱

By the sounds if it, you're having machines share a buffer(two machines accessing the buffer at the same time will usually cuase a buffer lock). If this is the case, adn you get more locks, you may want to look into either using &quot;remote buffers&quot;(if you don't do that allready), or using a pproxy. &quot;remote buffer&quot; has less of a chance of locking, and a pproxy garuntees you wont lock.🙂 Either way, if this continues, you should use one of the above solutions, so that your client doesn't sit idlely.

 

[dennilfloss]

Damn! I never noticed that command in my list. I must be getting old. 😉

distributed.net v2.8010-463 client for Win32
Visit http://www.distributed.net/FAQ/ for in-depth command line help
-------------------------------------------------------------------------
Special Options: (the client will execute the option and then exit)
-config start the configuration menu
-flush flush all output buffers
-fetch fill all input buffers
-update fetch + flush
-benchmark [pn] 16-20 sec speed check [optional: only project pn]
-benchmark2 [pn] half (8-10 sec) and slightly inaccurate -benchmark
-bench [pn] -benchmark all cores [optional: only project pn]
-test [pn] tests for core errors [optional: only project pn]
-restart restart all active clients (equivalent to -hup)
-shutdown gracefully shut down all active clients
-pause pause all active clients
-unpause unpause all active clients
-install install the client as a service
-uninstall uninstall the client previously -installed
-svcstart start a previously -installed client-as-service
equivalent to NT's 'net start ...'
-import <fn> import packets from file <fn> into client buffers
-forceunlock <fn> unlock buffer file <fn>
-help display this text

Project and buffer related options:

-ini <filename> override default name of INI file
-e <address> the email id by which you are known to distributed.net
-nodisk don't use disk buffer files
-n <count> packets to complete. -1 forces exit when buffer is empty.
-runbuffers set -n == -1 (exit when buffers are empty)
-frequent frequently check if buffers need topping-up
-inbase <fname> input buffer basename (ie without 'extension'/suffix)
-outbase <fname> output buffer basename (ie without 'extension'/suffix)
-ckpoint <fname> set the name of the checkpoint file
-blsize <pn> <n> set preferred packet size (2^n keys/packet)
-bin <pn> <n> set fetch buffer threshold to <n> work units
-btime <pn> <n> set fetch time threshold to <n> hours
If not specified, project name <pn> defaults to RC5

Network update related options:

-runoffline disable network access
-runonline enable network access
-nettimeout <secs> set the network timeout. Use -1 to force blocking mode
-a <address> keyserver name or IP address
-p <port> keyserver port number
-nofallback don't fallback to a distributed.net keyserver
-u <method> use this UUE/HTTP encoding method (see -config)
-ha <address> http/socks proxy name or IP address
-hp <port> http/socks proxy port
-lurk automatically detect modem connections
-lurkonly perform buffer updates only when a connection is detected
-interfaces <list> limit the interfaces to monitor for online/offline status

Performance related options:

-c <pn> <n> core number (run -config for a list of valid core numbers)
project name &quot;pn&quot; defaults to RC5
-numcpu <n> run <n> threads/run on <n> cpus. 0 forces single-threading.
-priority <0-9> scheduling priority from 0 (lowest/idle) to 9 (normal/user)

Logging options:

-priority <0-9> scheduling priority from 0 (lowest/idle) to 9 (normal/user)

Logging options:

-l <filename> name of the log file
-smtplen <len> max size (in bytes) of a mail message (0 means no mail)
-smtpsrvr <host> name or IP address of mail (SMTP) server
-smtpport <port> mail (SMTP) server port number
-smtpfrom <id> who the client should say is sending the message
-smtpdest <id> who the client should send mail to

Miscellaneous runtime options:

-h <hours> time limit in hours
-until <HH:MM> quit at HH:MM (eg 07:30)
-noexitfilecheck override .ini exit flagfile setting
-pausefile <fn> name of file that causes the client to pause
-percentoff don't display work completion as a running percentage
-quiet/-hide suppress screen output (== detach for some clients)
-noquiet don't suppress screen output (override in

 

[RaySun2Be]

ViRGE is right on 😀, you will have to force unlock the buffers. Sounds like you are sharing the buffer file or running remote buffers. I had started getting buffer locks a lot, and they are a pain because new work doesn't get done. I resolved the problem by running a dnet personal proxy. 😀

 

[JHutch]

You can also get that error if DNETC cannot get write access to the buffer files. This can happen if the client is logged in as a service that doesn't have access to the directory the buffer files are stored in...

JHutch