[rc5] [koenig@tat.physik.uni-tuebingen.de: rc3v2 client suggestions]

Harald Koenig koenig at tat.physik.uni-tuebingen.de
Tue Jul 8 23:43:02 EDT 1997


On Jul 8, Jeff Lawson wrote:

> Source is not currently available, but we expect a limited release sometime
> in the future.  No ETA is currently available.

*please* RSN!  I've real trouble with your locking code.

some of the trouble seems due to timeout problem when rc5v2 client
doesn't get enough CPU time (it's running *way* below "nice 19" for us,
and thus it's not getting *any* CPU time if other procceses are in the 
run queue.  being able to change the priority before/after locking
would be nice...)

> >- what should be the difference between binaries for intel P5 and P6 ?
> >  benchmarks didn't show *any* differencs  (using PPro200)
> 
> You should see slight differences.

tried 2.002 P5 and P6 binaries, again, no obvious performace differences
on dual-PPro200.

> The buffer files are intended to be shared by multiple instances of the
> client, so there is nothing wrong with it being in the same directory as
> those used by other clients.  Yes, file locking is dealt with properly.

doesn't work correctly for me (using SGI IRIX 5.3 NFS server),
I've reverted to one directory per client...

locking seems to cause NFS problems for Linux-2.0.30 :-(

> >	Buffer is locked 2 - waiting 1 second.
> >	Buffer is locked 2 - waiting 1 second.
> >
> >  messages.  killing and restarting fixed it  (but if I wouldn't have seen 
> 
> This has been fixed in v2.002 of the client

I still get all sorts of these messages using 2.002 with
common buff-* files:

	Buffer is locked 1 - waiting 1 second.
	Buffer is locked 1 - waiting 1 second.

	Buffer is locked 2 - waiting 1 second.
	Buffer is locked 2 - waiting 1 second.

	Buffer is locked 3 - waiting 1 second.
	Buffer is locked 3 - waiting 1 second.


some of them cured them self after a while (some seconds .... 10+ minutes),
some needed to be killed...

> You can improve performance and reduce clutter in your log file by running
> a looping script that calls "rc5v2 -update" and sleeps repeatedly.  Then
> the network access will be done in that copy of the client and it will keep
> the buffers filled and ready for the other instance of the client.

done.  thanks


Harald
--
All SCSI disks will from now on                     ___       _____
be required to send an email notice                0--,|    /OOOOOOO\
24 hours prior to complete hardware failure!      <_/  /  /OOOOOOOOOOO\
                                                    \  \/OOOOOOOOOOOOOOO\
                                                      \ OOOOOOOOOOOOOOOOO|//
Harald Koenig,                                         \/\/\/\/\/\/\/\/\/
Inst.f.Theoret.Astrophysik                              //  /     \\  \
koenig at tat.physik.uni-tuebingen.de                     ^^^^^       ^^^^^
----
To unsubscribe, send email to majordomo at llamas.net with 'unsubscribe rc5' in the body.



More information about the rc5 mailing list