[time-nuts] LH CPU usage

John Miles jmiles at pop.net
Mon Jan 4 02:58:31 UTC 2010


It actually should be sleeping for more like 100 milliseconds per rendered
frame, rather than doing a Sleep(0) as it does now.  That would help a great
deal with the power-consumption issue.  The command-line option Mark added
should be useful in that regard.

What I'm not sure about, though, is the potential effect on the temperature-
and oscillator-control loops, for those who are using those features.
Either way, you can expect the 'real' 3.00 release to be a little smarter in
terms of how much CPU it uses.

-- john, KE5FX

> -----Original Message-----
> From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com]On
> Behalf Of Jim King
> Sent: Sunday, January 03, 2010 6:44 PM
> To: Discussion of precise time and frequency measurement
> Subject: Re: [time-nuts] LH CPU usage
>
>
> I disagree.  On modern desktops this behavior will prevent Vista and
> Win7 from throttling back the CPU.  Not being able to throttle back the
> CPU will make it run hotter and draw more power, which is likely to
> produce more noise (because the cooling fans need to be sped up) and
> heat.  Yeah, it's probably not a huge amount of noise and heat, but I
> like my PC to be cool and quiet.
>
> Not to mention that it makes certain types of troubleshooting a bit more
> challenging.  If I see my system maxed out on CPU I assume that some
> application has gone nuts and needs to be killed off (happened last
> night with a misbehaving webcam app).
>
> And IMHO it's not necessary to design Windows serial communications this
> way.  I've written Win32 serial comms software and it's not that
> difficult to design the serial I/O to use the CPU efficiently.  If
> you're worried about portability then move up the abstraction layer -
> instead of abstracting "get a character from the serial port" abstract
> the entire serial I/O module.  Yes, that takes more porting effort, but
> it also means that the serial I/O module will be implemented properly
> for the host OS.
>
> Jim
>
> On 1:59 PM, John Miles wrote:
> > It's not an issue, except possibly vis-a-vis battery life in a laptop.
> >
> > -- john, KE5FX
> >
> >
> >> -----Original Message-----
> >> From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com]On
> >> Behalf Of Steve Rooke
> >> Sent: Sunday, January 03, 2010 5:23 PM
> >> To: Discussion of precise time and frequency measurement
> >> Subject: Re: [time-nuts] time-nuts Digest, Vol 66, Issue 6
> >>
> >>
> >> 2010/1/4 Mark Sims<holrum at hotmail.com>:
> >>
> >>> As far as the time slicing goes,  the code is continually doing
> >>>
> >> Sleep(0) calls.  These give the time slice back to Windows.
> >> You can't get much more multitask friendly than that.
> >>
> >>> If Windows has nothing better to do,  it gives the time back to
> >>>
> >> Heather (which if there is nothing else going on,  does another
> >> Sleep(0) (or Sleep(#) if /tw=# is given on the command line).
> >> The idle time would otherwise be spent in the Windows idle
> >> loop...   either way,  the idle time gets wasted somewhere.
> >>
> >> But doesn't that in itself generate a rapid loop of system calls when
> >> LH is not doing any processing. There is a difference between leaving
> >> the OS idle than just wasting time in a rapid busy loop with the CPU
> >> polling LH to see if it has any work to do without any sleep time in
> >> between.
> >>
> >> For a DOS application this really makes no odds, as you say, but then
> >> we are really not talking about a multiuser multitasking system.
> >>
> >> Steve Rooke
> >> --
> >> Steve Rooke - ZL3TUV&  G8KVD
> >> A man with one clock knows what time it is;
> >> A man with two clocks is never quite sure.
> >>
> >> _______________________________________________
> >> time-nuts mailing list -- time-nuts at febo.com
> >> To unsubscribe, go to
> >> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> >> and follow the instructions there.
> >>
> >>
> >
> >
> >
>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.




More information about the time-nuts mailing list