Path: utzoo!attcan!uunet!know!zaphod.mps.ohio-state.edu!wuarchive!udel!rochester!pt.cs.cmu.edu!b.gp.cs.cmu.edu!Ralf.Brown@B.GP.CS.CMU.EDU From: Ralf.Brown@B.GP.CS.CMU.EDU Newsgroups: comp.os.msdos.programmer Subject: Re: Increasing #task switches per second (> 18.2), help Message-ID: <27677a6f@ralf> Date: 13 Dec 90 11:56:15 GMT Sender: ralf@b.gp.cs.cmu.edu Organization: Carnegie Mellon University School of Computer Science Lines: 31 In-Reply-To: In article , levericw@cheetah.ece.clarkson.edu (Walden Leverich) wrote: }In article <76399@iuvax.cs.indiana.edu> bomgard@iuvax.cs.indiana.edu (Tim Bomgardner) writes: }Tim> filetp@dnlunx.pttrnl.nl (Peter Filet) writes: }Tim> > (wants a faster system clock) } }Tim> This is actually very easy to do. The idea is to hook the clock }Tim> tick interrupt,keeping the original vector and substituting your own }Tim> handler. Then, if you }Tim> want, say, a 4X clock rate (72.8/sec), you call the original handler every }Tim> fourth tick. The rest of the OS has no idea anything has changed..... } }Very interesting. But wrong. Considering that your interrupt timer }will be called once every 1/18.2 seconds. Now if your pass that tick }onto the OS every fouth time, then the OS gets 1/4 of the clock *NOT* }4X the clock. The idea is that you speed up the timer chip to generate the clock tick 72.8 times per sec, THEN pass only every fourth tick to the previous handler. }Academic types in the CompEng field will explain why it is impossible. Better not tell my NLQ-print program, which speeds up the clock tick by a factor of 128 (needed to spool the resulting graphics to the printer in the background as fast as the printer can handle) without affecting the system clock.... -- UUCP: {ucbvax,harvard}!cs.cmu.edu!ralf -=- 412-268-3053 (school) -=- FAX: ask ARPA: ralf@cs.cmu.edu BIT: ralf%cs.cmu.edu@CMUCCVMA FIDO: 1:129/3.1 Disclaimer? | I was gratified to be able to answer promptly, and I did. What's that? | I said I didn't know. --Mark Twain