From:	"Matthew Waddilove" <matthew AT waddilove DOT u-net DOT com>
Newsgroups:	comp.os.msdos.djgpp
References:	<Pine DOT SUN DOT 3 DOT 91 DOT 980702132102 DOT 17177C-100000 AT is> <359B6C95 DOT E4CDECE2 AT sis DOT co DOT at> <359B6D6E DOT 725FCD2E AT sis DOT co DOT at>
Subject:	Re: bash eats cycles
Message-ID:	<BoVm1.3604$Zh.1790980@newsr2.u-net.net>
Date:	Fri, 03 Jul 1998 00:15:29 GMT
NNTP-Posting-Host:	194.119.133.242
NNTP-Posting-Date:	Fri, 03 Jul 1998 01:15:29 BST
Organization:	(Posted via) U-NET Internet Ltd.
Lines:	30
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

Gerhard W. Gruber wrote in message <359B6D6E DOT 725FCD2E AT sis DOT co DOT at>...
>Gerhard W. Gruber wrote:
>
>> The signifikant load is not in the idle time. It is when the dos box is
>> active. Let's assume that I start the compiler and it runs through. After
>> this is finished I switch to another dos box and start the command. As
long
>> as the dos box is on screen the load is significant. I have to minimize
the
>> box and then everything is back to normal but keeping the window visible
is
>> a pain.
>
>I just noticed also that the window really has to be visible to start
>blocking. It just happend that I had a dos box active but completely hidden
>behind another window and the load was ok. After closing the hiding window
>it sufficed for the dos box to become visible again and it started to slow
>dow. It might be that this is a bug in NT rather in bash, though.
>--


I think that it's NT basically almost any program that I have used that uses
the
NTVDM takes up 100% CPU if it can get it.  one thing that you could try it
to
set the proirity for NTVDM to LOW from NORMAL but that might cause even more
problems :)

- Raw text -