Conference jamin::pw95ift

> Now when his thread waits for the data to arrived, this tread eats most of 
> the CPU time!.

	This is another instance of the DECnet stack using all the 
	free time on the system while waiting for a blocking operation.
	It repeatedly calls the OS to release the current time slice
	but when the OS has nothing else that wants to use the CPU
	it turns control back over to one of the wait loop in DECnet.

	The system should still be responsive since the only time being
	spent in the wait loop is time that would otherwise be idle
	but it does peg the processor statistics at "100% Utilization".

	I think this MIGHT cause a problem if the looping process
	has a higher priority than some other process that is ready
	to run since the looping process MIGHT therefor prevent the
	lower priority process from running.  I have not seen any
	reports that indicate such a problem.

If priority is an issue, I have a small program that starts up and 
then changes any other program to an idle priority.

Let me know

Alan

>> Now when his thread waits for the data to arrived, this tread eats most of 
>> the CPU time!.
>
>        This is another instance of the DECnet stack using all the 
>        free time on the system while waiting for a blocking operation.
>        It repeatedly calls the OS to release the current time slice
>        but when the OS has nothing else that wants to use the CPU
>        it turns control back over to one of the wait loop in DECnet.
>
>        The system should still be responsive since the only time being
>        spent in the wait loop is time that would otherwise be idle
>        but it does peg the processor statistics at "100% Utilization".
>
>        I think this MIGHT cause a problem if the looping process
>        has a higher priority than some other process that is ready
>        to run since the looping process MIGHT therefor prevent the
>        lower priority process from running.  I have not seen any
>        reports that indicate such a problem.
> 

Thanks for the fast reply. I'll forward this to my customer and hope it will
satisfy him.

Thanks again,
Yoram.

    There is a bug in the socket library which prevents it from processing
    other windows messages while it is waiting for the completion of an
    i/o.  I recommend entering a problem report so that you can get a patch
    for this.
    
    Diane
    

>        This is another instance of the DECnet stack using all the 
>        free time on the system while waiting for a blocking operation.
>        It repeatedly calls the OS to release the current time slice
>        but when the OS has nothing else that wants to use the CPU
>        it turns control back over to one of the wait loop in DECnet.
>
>        The system should still be responsive since the only time being
>        spent in the wait loop is time that would otherwise be idle
>        but it does peg the processor statistics at "100% Utilization".

	The above is true of the Windows 95 implementation but there
	is a problem in the Windows NT implementation.  The "release 
	the remainder of my time slice" function works fine on Windows 
	95 but the Windows NT version just returns.  The Windows NT 
	version thus never explicitly releases the time slice and the 
	entirety of each time slice spinning in one or more wait loops.

	Fortunately, Microsoft chose to implement the NetBIOS interface 
	for Windows NT through the TDI interface rather than leaving it 
	to each stack.  This means that synchronous NetBIOS operations 
	don't chew CPU on Windows NT, only IOCB (socket) operations.

Does Pathworks 32bit which is schedual for this spring (I think) address this problem ?.
If so I think my customer might be willing to wait this long. Now I'm waiting to his reply
about whether I should open a CLD and get a fix now.

Thanks,
Yoram.

    re .4
    
    I have a netbios app which, under win95, makes the system run really
    slow. Now it only happens if DECnet is loaded and it only happens on 2
    customer sites. I cannot reproduce it at home.
    
    The slowdown starts when the app does an 'add name' and loops waiting
    for the netbios response to come back. After that, the whole system
    runs really slowly.
    
    Is it possible that the .4 bug might cause this ?
    
    Alan
    

> Does PATHWORKS 32, which is scheduled for this spring (I think), address 
> this problem?.

	No.

> I have a netbios app which, under win95, makes the system run really
> slow. Now it only happens if DECnet is loaded and it only happens on 2
> customer sites. I cannot reproduce it at home.
>   
> The slowdown starts when the app does an 'add name' and loops waiting
> for the netbios response to come back. After that, the whole system
> runs really slowly.
>    
> Is it possible that the .4 bug might cause this ?

	The bug in .4 is in the Socket Library, not in the NetBIOS
	interface (NetBIOS is implemented in the DECnet stack and
	is not layered on the socket library).

	The Windows 95 problem is only the appearance of 100% CPU
	utilization.  The system remains responsive.  It is also
	only for SYNCHRONOUS calls. "the app does an 'add name' and 
	loops waiting for the netbios response to come back" sounds
	like an ASYNCHRONOUS call.  In that case it would be the
	program's responsibility to release time slices to keep the
	system responsive.

	What does your application do while it is waiting?

	One mistake I had made in a NetBIOS program was expecting a
	callback on completion and not looking for an immediate
	completion...  Are you using callbacks?

My app just loops giving control back to windows while it waits for the NCB 
return code to change. I don't use callbacks.

regards

Alan

> My app just loops giving control back to windows while it waits for the NCB 
> return code to change. I don't use callbacks.

	How do you give controll back to Windows?  Is this a
	PeekMessages, GetMessage, DispatchMessage kind of thing?

You got it:

    repeat
        while PeekMessage(TempMsg,0,0,0,PM_remove) do begin
            TranslateMessage(TempMsg);
            DispatchMessage(TempMsg);
        end;
    until (TheNCB.CmdComplete <> $FF);
 
Alan

> repeat
>	while PeekMessage(TempMsg,0,0,0,PM_remove) do 
>	begin
>		TranslateMessage(TempMsg);
>		DispatchMessage(TempMsg);
>	end;
> until (TheNCB.CmdComplete <> $FF);

	If you don't need to do anything until the NCB completes
	you can try using the "Completion Event" feature added
	by Microsoft.  You create an Event object and put the
	handle of the object into the "ncb_event" field of the 
	NCB.  That Event will be signaled whent he NCB completes.
	Just use "WaitForSingleObject()" to wait for completion.

	If you need to do periodic background operations while 
	waiting (I have an animated icon that I need to update)
	you can either put a timeout on the "WaitForSingleObject()"
	or use a wait loop with a Sleep() call in it.  I added a 
	0.1 second (100 millisecond) Sleep() to a wait loop and 
	the system became much more responsive.

Sounds nice - is this 32 bit only ? My app is 16 bit

Alan

>> you can try using the "Completion Event" feature added
>> by Microsoft. 

> Sounds nice - is this 32 bit only?  My app is 16 bit

	I think it is 32-bit only (neither CreateEvent() nor Sleep() 
	is in the Win16 API.

	It is unfortunate that this is not reproducable here... It
	would be fairly easy to use a debugger like SoftICE for
	Windows 95 to determine where the CPU time was going.

	Good luck!