I wonder if un-crippling the box would increase capacity in proportion?
Perhaps HP could comment?

Neil


-----Original Message-----
From: John Korb [mailto:[log in to unmask]] 
Sent: 25 June 2002 12:51 AM
To: [log in to unmask]
Subject: Samba version 2.0.10 feedback


Some feedback on Samba 2.0.10 and a request for feedback from others
running Samba 2.0.10.


I've been running the 2.0.10 version of Samba (Thanks Lars!) since late
February, and the "reduced logging" version (Thanks Lars!) since mid
May.

I've been quite happy with it, particularly the May update (much smaller
Samba log files!).

I've only had one strange thing show up.  Every once in a while (it has
happened five times in four months) a Samba process apparently decides
to loop and eats as much of the CPU as it can.  One rather idle day (our
production hours are from mid afternoon to oh dark thirty) I decided to
let it run for a few hours to see if it would eventually terminate or
return to good behavior.  No such luck.

I don't know what causes the looping, and it is infrequent, so I can
easily live with it.  I'm wondering if anyone else using Samba 2.0.10
has experienced this.

Also, can someone remind me of the easy way to convert a PIN to a PID as
next time I'd like to see who the user is and while SHOWPROC shows the
PIN, SMBSTATUS displays the PID.

For anyone who might be interested...  While our A500-100-140 (with
three 100BT NICs) easily survives 175 simultaneous share connect
attempts, there seems to be a knee in the curve at about 190-195, and
things go downhill from there.  At 220 the CPU goes 100% busy for about
two-to-three minutes and the console is spitting out Samba messages as
fast as it can.  At 250 you have trouble logging in NS-VT, and at 300
there is a good chance that any NS-VT, Telnet, or FTP sessions will be
dropped.  I use "simultaneous connection attempts" as a metric because
while the 3000 is on a UPS, the collection PCs are not, and when the
reboot after a power failure, they all try to connect at once (the
inbound buffer pool numbers are not a pretty sight).

Thanks,

John

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *