1.2.5 client problem

[DVNT1]

I've noticed after long periods of running the client on machines that are idle, for a couple hours anyway, the machine becomes very unresponsive.

Frequently, when I restart the SOB client, the system runs great again. All these systems previously ran the ECC2 client without these types of problems. Is there a solution?


==other details==
Client Environments include:
*W2K with sp3
*W2k with so4
*XP Pro SP1
*Some that have dual processors others are single processor.
*All are installed as a Service.
*All use default SOB client priority settings.
=============

One particular example:
W2K sp3 Pentium3 667mhz (64megs ram) computer was not responding well.

Using Task Manager, CPU time for SB.exe was 2hours and 5 minutes.
SB.exe Memory usage went from 2,xxxk to 10,940k in about 30sec.
Then the machine became even more unresponsive for about 5~6min.

Note: During this time I ran netstat -a and there were not any SOB client related network connections active.

Then sb.exe CPU % dropped to 0% and memory usage climbed to 15,992k.
After reaching the 15,992k memory use the system became extremely unresponsive again.

After several more minutes, sb.exe memory usage dropped to 11,684k but was still very unresponsive. So slow that Task Manager only updated once every 5sec instead of once per second.

Killing the sb.exe process helps restore responsiveness, but it still isn't "normal" until the computer was restarted.

[Joh14vers6]

Originally posted by DVNT1
I've noticed after long periods of running the client on machines that are idle, for a couple hours anyway, the machine becomes very unresponsive.

Frequently, when I restart the SOB client, the system runs great again. All these systems previously ran the ECC2 client without these types of problems. Is there a solution?


==other details==
Client Environments include:
*W2K with sp3
*W2k with so4
*XP Pro SP1
*Some that have dual processors others are single processor.
*All are installed as a Service.
*All use default SOB client priority settings.
=============

One particular example:
W2K sp3 Pentium3 667mhz (64megs ram) computer was not responding well.

Using Task Manager, CPU time for SB.exe was 2hours and 5 minutes.
SB.exe Memory usage went from 2,xxxk to 10,940k in about 30sec.
Then the machine became even more unresponsive for about 5~6min.

Note: During this time I ran netstat -a and there were not any SOB client related network connections active.

Then sb.exe CPU % dropped to 0% and memory usage climbed to 15,992k.
After reaching the 15,992k memory use the system became extremely unresponsive again.

After several more minutes, sb.exe memory usage dropped to 11,684k but was still very unresponsive. So slow that Task Manager only updated once every 5sec instead of once per second.

Killing the sb.exe process helps restore responsiveness, but it still isn't "normal" until the computer was restarted.

One thing I know, SoB depends on memory. But your symptons are unknown for me. Right now SoB.exe uses 25.332kB at a PIV and I have seen more.

[DVNT1]

In another example...

XP Pro w/sp1
P4 3.4EE
1 gig ram
50+gig free hd space

Same unresponsiveness after letting it run all night... had to reboot it to restore normal speeds.

[eagle1]

Hey DVNT! :p

Check if with older versions you get the same results!
I'm using an older version and I'm not getting the same unresponsiveness or lower performance from my machines.

[DVNT1]

Where can I get the older client to test with?

n/m, found it at http://linux.redbird.com/~alien88/sb120.exe


Can I just replace the executable in machines that already have 1.2.5 installed?

[CrackDaddy]

experiencing the same with my clients 1.8ghz p4's unresponsive after a nights worth of work. also using the 1.2.5 client version. did it improve any?

CD

[MathGuy]

I've not noticed any problem like this, but one possible reason is that my service handlers are set to restart the client every morning at some time like 2:00 a.m. (I forget precisely). This feature was once important because the client had a socket leak and needed to be restarted periodically to avoid problems. When this was fixed (many versions ago) I never bothered to change my settings because, well, that would take some nonzero amount of effort...

Until this gets sorted out, you might try the restart switch on the service handler and see if automatically restarting the client every night helps with your immediate problem.

To do this, do something like:

cd "\program files\sb"
sobsvc -r:200
net stop "Seventeen or Bust service"
net start "Seventeen or Bust service"

Thereafter, all instances of the client on this machine should restart at 2:00 a.m.

[DVNT1]

Been running the 1.2.0 client for a while now and it doesn't have the same "slow response" problems as 1.2.5 does.

Restarting the client periodically isn't an option for me unless the SOB tray icon would really stay hidden.

[CrackDaddy]

I also recently switched over a group of 10 clients and have had no problem with the slow response time.

CD

[MathGuy]

Originally posted by DVNT1
Restarting the client periodically isn't an option for me unless the SOB tray icon would really stay hidden.

It will stay hidden if you disallow desktop interaction. The "Services" administration tool has a checkbox on the "Log On" tab that can be unchecked to disallow this. If you do that, it will *never* show up on the desktop (or the tray). This only works for the NT codebase (NT/2K/XP), but that's all you mentioned in your original message, so it should work for you...

[DVNT1]

Originally posted by MathGuy
It will stay hidden if you disallow desktop interaction. The "Services" administration tool has a checkbox on the "Log On" tab that can be unchecked to disallow this. If you do that, it will *never* show up on the desktop (or the tray). This only works for the NT codebase (NT/2K/XP), but that's all you mentioned in your original message, so it should work for you... It appearently doesn't always work as intended. The Allow Service to Interact with Desktop is unchecked (by default even) but the client will still show up in the SYSTRAY if SOB service is restarted with a user logged in. I've tested this with Windows 2000 workstations, some with sp3 and others with sp4.

[Matt]

I also have this problem in windows 2000.

[MathGuy]

Originally posted by DVNT1
It appearently doesn't always work as intended. The Allow Service to Interact with Desktop is unchecked (by default even) but the client will still show up in the SYSTRAY if SOB service is restarted with a user logged in. I've tested this with Windows 2000 workstations, some with sp3 and others with sp4.

Let me check on this - one of my systems is a Win2K, so I can presumably reproduce it.

[MathGuy]

Now I'm really puzzled...I tried to reproduce your situation on my Win2K box and it works fine for me - if the box is checked, the icons show up in the tray and if it's unchecked, they don't. I did restarts and even attempted to kill the clients via the Task Manager (which failed). All my attempts produced correct behavior.

Can you give me some more details on what happens when these icons show up and they're not supposed to?

Thanks...

[DVNT1]

I had same results using psservice (from systeminternals.com) and MMC to restart the service.

Windows 2000 English edition. Some Sp3, some SP4

My typical install method...
I use a VBscript to pull computer names from a specified Active Directory OU, it executes the following batch file with the machine name

installone.bat contents

md \\%1\c$\progra~1\SB
copy f:\sb\*.exe \\%1\c$\progra~1\SB
copy f:\sb\*.bat \\%1\c$\progra~1\SB
copy f:\sb\*.reg \\%1\c$\progra~1\SB
g:\psexec \\%1 "c:\program files\sb\installoneB.bat"


installoneB.bat contents:


c:
cd "\program files\sb"
sobsvc -i
sobsvc -o2
sobsvc -s
c:\winnt\regedit.exe /s c:\progra~1\sb\install.reg
c:\windows\regedit.exe /s c:\progra~1\sb\install.reg
psservice start "Seventeen or Bust service"
del c:\progra~1\sb\psservice.exe
del c:\progra~1\sb\install.reg
exit


install.reg contents:


REGEDIT4

[HKEY_LOCAL_MACHINE\SOFTWARE\LhDn\sob]

[HKEY_LOCAL_MACHINE\SOFTWARE\LhDn\sob\config]
"Username"="DVNT1"
"team"=""
"dir"="c:\\program files\\SB"
"logfile"="sb.log"
"max_log_size"=dword:00000000
"serv_addr"="proxy2"
"serv_port"=dword:000006B5
"max_retries"=dword:00000000
"max_rep_retries"=dword:00000000
"retry_wait"=dword:00000078
"transmit"=dword:00000001
"priority"=dword:00000005
"special_handling"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Seventeen or Bust service]
"Type"=dword:00000010

[MathGuy]

Can you check the current contents of the "Type" key of HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Seventeen or Bust service ? Is is still a 0x10?

This is really getting weird...it sure looks like your script is doing the right thing. I suppose it's possible that under some circumstances processes spawned by non-interactive services are attached to the default window station, but I can't make it happen here.

If your Type value is still 0x10, then I'll keep researching this and see if I can find out what's going on here.

[DVNT1]

yes, 0x10

[MathGuy]

DVNT1 - just wanted to let you know that I haven't forgotten about you...this thing is proving to be devilishly hard to track down. As best I can determine, MS in W2K SP3 "fixed" the behavior of child processes of services with regard to interaction with the desktop in an effort to make it the same as XP...well, it's NOT. The service handler works fine for W2K before SP3 and for XP, but not (apparently) for W2K SP3 (and SP4). Unfortunately, I don't have access to any W2K SP3 boxes for testing purposes so I'm working somewhat blind.

I *will* get it figured out, though, and put out a new service handler that behaves correctly on all OSes...just when that will be, I can't promise...

[DVNT1]

Thanks for the update MathGuy.

[MathGuy]

DVNT1 - New service handler at http://home.comcast.net/%7Ekerry.n.jones/sobsvc17a.zip will hopefully fix your "hidden client" problem - let me know if it doesn't.

[Joh14vers6]

Originally posted by MathGuy
DVNT1 - New service handler at http://home.comcast.net/%7Ekerry.n.jones/sobsvc17a.zip will hopefully fix your "hidden client" problem - let me know if it doesn't.

We still have some problems with the service handler. I notice that closing Windows cost about 2 minutes when the client is hidden and ½ minute when it is hidden (Win XP pro SP2). Also one of our members report closing times of more than 3 minutes and errorreports of crashed explorer.exe when the client is hidden (Win XP SP1).

I also found a bug with the above service handler. When I toggle the setting sobsvc -k or sobsvc -s I got after restarting the service 32 times starting up client 1. sobsvc -p:1 or sobsvc -o or changing HKEY_LOCAL_MACHINE\SOFTWARE\LhDn\sob\svcparms\NumClients to 1 in the registry give still 32 clients. Only replacing this service handler by service handler v1.6 gives back normal operating.

[edgan]

I have seen the very slow logout problem with service handler 1.6. It was at least helped by setting the true "idle" option, aka sobsvc -x. I haven't seen a problem with hiding, but I did have sob 2.0 sse2 crash on logout.

[Stricker]

i have had this problem for quite a while and it never really seemed to get any faster even w/ service handler updates i'm currently on xp pro sp2 i just have an icon on my desktop that send the 'net stop "seventeen or bust" ' command just before i shutdown the system

[Joh14vers6]

Originally posted by Stricker
i have had this problem for quite a while and it never really seemed to get any faster even w/ service handler updates i'm currently on xp pro sp2 i just have an icon on my desktop that send the 'net stop "seventeen or bust" ' command just before i shutdown the system That is not useable if the computer is (also) used by other people (co-workers) at the office.

[edgan]

If telling the service to stop and then logging out fixes the problem then I would say the service handler is definitely the problem and it should be fixed.

[MathGuy]

You're right, it should be fixed - unfortunately, it doesn't happen on *every* system. In particular, it doesn't happen on *any* system to which I have access. What appears to be the case is that, on the affected systems, by the time services are being stopped, something else is using all the cycles that the SB client needs in order to shut down cleanly. If you remember back to the "good old days" before this shutdown delay popped up, there was another problem - namely, sometimes when you restarted after a shutdown, the client would find itself with a corrupted cache and have to restart work on the block. This doesn't happen anymore and, IMHO, it's better to have some slow shutdown issues than it is to have blocks restarting occasionally (although admittedly maybe I would feel differently about it if the slow shutdown happened to me).

The solution to this is to somehow shut down the service *before* the usual service shutdown sequence. I have been experimenting with responding to the WM_ENDSESSION message, but it's not clear that this will help with the case where the clients are "hidden" - i.e. it's not clear that the WM_ENDSESSION message goes to apps that are running on a separate virtual desktop any earlier than the usual service shutdown point.

Anyway, as soon as I have a viable solution to this, I'll post it so you can try it out...I really haven't forgotten about this, but RL does really interfere with my DC programming...

[engracio]

I also have a problem running SOB as a service. When shutting down the ws, it take as long as ten minutes to shutdown both on w2k or xp. Took it out and ws shut down normally. Granted the SOB icon stays on the sys tray.


e



http://www.clanhosts.com/dev/sobsig/sig.php?engracio

[edgan]

With times from 2-3 minutes all the way to 10 minutes it sounds like the client is finishing the current block before closing. It would be better if it would either discard the current block to be redone on restart, or be able to save in the middle of a block.

[MathGuy]

The client is *not* finishing the current block (or intermediate block) on shutdown - it's merely saving its current place and quitting, which doesn't take much time at all normally. In fact, the "net stop" command that Stricker is sending before shutdown does *exactly* the same thing as a shutdown, except that the service stops at a time when CPU cycles are available. On my systems, I experience *no* delay at shutdown at all.

The problem really is that, on affected systems, there are simply no CPU cycles available for "saving its current place" at the time it needs to do this.

What CPU's are people seeing this on? My early research indicated that it happened only (or at least mostly) on single-processor AMD systems, but I haven't asked for a while, so that may no longer be valid.

[Joh14vers6]

The member I mentioned is using a P4 3.0GHz HT (HT switched off). Sophos virusscan is always running in the background.

I use a P4 2.4GHz@3.0GHz but I have only problems when the client is visible (or tray).

[royanee]

One solution, if possible, may be to have the service handler switch to a higher priority when it is told to shut down, this would allow it to steal as much of the processor cycles as it needs and exit quickly, before the other processes try to take them. Ideas?

[MathGuy]

Sadly, it already does this, to an extent (client is raised in priority substantially, service handler is raised, but less so to avoid a priority inversion since the handler waits on the client). This is, in fact, probably the reason that affected systems see hung explorers and connection trays during shutdown - whatever is getting more cycles than the SB clients is keeping the SB clients from running and they are, in turn, keeping other apps from shutting down cleanly...

I'm really not trying to be a "wet blanket" here - I think it's a good idea and that's why I already tried it. Unfortunately, it doesn't seem to solve the problem...

[engracio]

A big bump for this thread. I again tried to install SOB as a service on a box which will be out of state. With the new client 2.4 and sob installed as a service, the same slowness on shutting down/reboot occurs. The explorer, systray, and AV hangs and it takes more than a couple minutes before shutting down.

I guess the same service installer is being used on the new client. Does anybody have any possible solution to this problem? Since my brother is in town before getting ready to play on the big sandlot, I just added a shortcut to the startup and asked him not to shutdown the box. Not being run as a service, sob will not run if others log in to the box.

Can somebody shine a light on this problem. Thanks.


e:)


http://www.clanhosts.com/dev/sobsig/sig.php?engracio

[IronBits]

Increasing XP shutdown speed:
1. Increasing shutdown speed by reducing wait times part 1

Windows XP stores a couple of values in its registry which are responsible for determining how long to wait before shutting down (killing) open applications and services once the shutdown command has been given.

By editing these two settings and changing them to lower values, you can considerably decrease the amount of time that Windows XP needs to successfully shut itself down. The first part of this tweak deals with setting the amount of time Windows will take to kill open applications on shutdown.

Open REGEDIT and navigate to 'HKEY_CURRENT_USER\Control Panel\ Desktop\'
Highlight the 'WaitToKillAppTimeout' value.
Set it to '1000' (the default should be 20000).
Now highlight the 'HungAppTimeout' value
Set it to '1000' also.

2. Increasing shutdown speed by reducing wait times part 2

The second part of this tip changes the same settings, this time for all users on the system.

Open REGEDIT and navigate to 'HKEY_USERS\.DEFAULT\Control Panel\Desktop'
Highlight the 'WaitToKillAppTimeout' value.
Set it to '1000' (the default should be 20000).
Now highlight the 'HungAppTimeout' value.
Set it to '1000' also.

3. Increasing shutdown speed by reducing wait times part 3

In the third part of this tip, we will alter a second registry setting to decrease the amount of time Windows XP will wait before shutting down active services after receiving a shut down command.

Open REGEDIT and navigate to 'HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\'

Highlight the value 'WaitToKillServiceTimeout'

Change this value to '1000.'

This should help to considerably speed up the time windows XP takes to shut itself down.

4. Disable the Nvidia driver helper service

This service, included with recent NVIDIA Detonator driver packages, is of indeterminate function. Nothing is found on the NVIDIA site about it, and the only thing that people in the hardware community can seem to agree on is that it can considerably slow down boot up time and especially shutdown time.

Hence, if you do have an Nvidia video card, consider searching for and disabling this service. Chances are it will improve your shutdown times.

To disable the Nvidia Driver Helper service:

Right click on 'my computer' and select 'manage.'

Expand 'services and applications' and select 'services' to open the services window.

Locate and highlight the 'Nvidia Driver Helper' service. Right click it and select 'properties.'

Set the 'startup type' dropdown box to 'disabled.' Click 'ok.'

5. Auto kill tasks on shutdown

By default, Windows XP will prompt the user for input if there are one or more applications which have crashed or are not responding and it receives a shut down command. This halts the shutdown process entirely until the user approves the stopping of the non-responsive app.

By altering the registry slightly, Windows XP can be set to close crashed applications automatically. While this does not technically speed up the shut down process, it does streamline it, and ensure that the user will not give the shutdown command then get up and leave, only to find the PC still powered on because Windows never received input on what to do with a hung application.

To allow Windows XP to close non-responsive applications automatically upon shutdown:

Open REGEDIT and navigate to 'HKEY_CURRENT_USER\Control Panel\Desktop'

Highlight the value 'AutoEndTasks.'

Change the value to '1'

XP will now be able to close hung applications without user input during the shutdown process.
http://www.pcstats.com/articleview.cfm?articleid=1590&page=32

[engracio]

Thanks Ironbits, will give it a try on a w2k when I get home and XP as soon as I can rebuild a box to XP. Hope it works.:)


e:)