Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Date: Tue, 26 Nov 2002 23:38:49 +0100 From: thomas Reply-To: cygwin AT cygwin DOT com X-Priority: 3 (Normal) Message-ID: <11224707359.20021126233849@huno.net> To: cygwin AT cygwin DOT com Subject: Re: nice really nice? In-Reply-To: <1038343099.25127.448.camel@lifelesswks> References: <5 DOT 1 DOT 0 DOT 14 DOT 2 DOT 20021125185701 DOT 02a73ea8 AT pop3 DOT cris DOT com> <1038276393 DOT 23528 DOT 366 DOT camel AT lifelesswks> <1022481421 DOT 20021126111535 AT huno DOT net> <1038307508 DOT 23528 DOT 397 DOT camel AT lifelesswks> <1631951078 DOT 20021126142555 AT huno DOT net> <1038343099 DOT 25127 DOT 448 DOT camel AT lifelesswks> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Robert Collins wrote: > On Wed, 2002-11-27 at 00:25, thomas wrote: >> SetPriorityClass(GetCurrentProcess(), REALTIME_PRIORITY_CLASS) >> SetThreadPriority(GetCurrentThread(), THREAD_PRIORITY_TIME_CRITICAL) > If you do that, expect to get a hung system real fast. cdrecord does exactly the above during writing; cdrdao sets itself to HIGHEST (also using realtime class). And windows task manager also reports it is running at realtime. > What happens with nice -20 ? There is no difference from 0 - 20, and none between -1 and -20. >> $ time cat test.iso | nice --1 dd of=/dev/null >> real 1m51.428s >> user 0m0.107s >> sys 0m0.015s > Ah, I see it now, you expect a higher priority, and get less > performance. Less performance means by the factor of about 15 here. > What happens if you do this: > time nice --1 cat test.iso | nice --1 dd of=/dev/null ? Well first of all it steals all my ressources :) Winamp stops to play on my XP2000+. $ time nice --1 cat test.iso | nice --1 dd of=/dev/null real 0m6.784s and while i was at it i did: $ time nice --1 cat test.iso | dd of=/dev/null real 0m7.470s > sched.cc It was introduced around 1.1 IIRC. I don't know if you read one of my other two threads on this issue, but to save you some reading a very quick summary: I have cdrecord binaries compiled with cygwin 1.1.18 (running with cygwin1.dll 1.1.8 of course) and they work perfectly. When i compile the very same cdrecord sources with 1.3.x (+ dll) i get the phenomen you saw in the tests. Also this behaviour only shows when pipes are involved, when i read the iso in directly it works great. I'm just trying to find out what happened on the way. So if you have any idea what might be causing this behaviour i'd greatly appreciate it, you'd save me some of the hours i will spend digging in CVS :) thomas -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/