Re: No more XP lag with Tamedos

["Robert Holmgren" holmgren@xxxxxxxx]

** Reply to message from Si Wright  on Wed, 22 Dec 2004
00:53:01 -0800 (PST)


> And just out of curiosity, does someone understand how
> [Tame] works?

David Thomas? He knows how it works. In essence,
what David does is monitor mainly the keyboard
(which, after all, is the main input tool of all old DOS
apps) to see whether there is buffer activity. If
nothing (or very little) is happening, he lowers the priority
of the process, i.e. gives it fewer and fewer CPU cycles.
The problem he's addressing here is that old DOS apps thought
they were the exclusive owners of the machine -- and indeed,
they were. It didn't matter whether they monopolized the CPU,
because there was no multitasking, and only one process could
be running at any moment. But nowadays, apps need to cooperate
and share the attention of the Central Processing Unit, i.e.
the chip of chips, the Pentium 3 or 4 or whatever. They're all
continuously demanding that the CPU give them some of its time,
its "cycles". And that's the purpose of Tame -- to reduce the
"CPU-hog" proclivites of old DOS apps, and allow other processes
their fair share too -- otherwise everything else on your machine
*except* the DOS app slows to a crawl -- to the point that they
can (and do) malfunction, which is no joke. Windows is very very
bad at memory management.

You might think, that with modern high speed superpower processors,
it wouldn't matter much. But in fact, the old DOS apps gobble up
*everything* that's available -- everything! -- whether they need it
or not (obviously, they don't). But they say to the CPU, gimme --
period. And the CPU does what it is told.

Under Tame, when a DOS app asks for everything, it still gets
everything. But only momentarily. If it isn't actually making use
of the CPU, Tame cuts its priority way back. Just an example:
WordPerfect DOS v5.1 is a memory hog non pariel (if you think
XyWrite is bad... whew, try WP). Tame cuts it down from 100% of
CPU to an average of under 3% -- which is still plenty for WP.
Tame is also capable of drawing a hard line under any app, saying
in effect, "everything" in your case amounts to 20%, and if you
want more -- GFY.

Now, none of this bears directly on the cursor issues you're
talking about. But it happens that the internal processes that
David is watching (like Idle Sensitivity -- are we active or
are we idle?) are closely related to cursor "twitchiness",
which results from an uneven distribution of CPU cycles to the
video portion of Desktop window VDMs (screen refreshing is
spasmodic -- that's the core problem). I doubt very much that
he can directly intervene in cursor handling (I could be wrong),
but I think what he does instead is *deprive* other parts of
the VDM (Virtual DOS Machine) of CPU cycles, so that video
gets more. In essence, he slows it down in order to smooth out
the behavior. If you take a look at all the little switches
he uses (which you could set if you knew what they did), he's
intervening and fine-tuning all over the map -- you get the
drift when you look at this:
/Auto_SETtings_Detect
/BoostDos 2
/BoostIrq 2
/BoostKey 2
/BoostVideo 2
/CpuIdlePercent 20
/KeyIdle 2
/NoAutoSettings
/NoAuto_SETtings_Detect
/NonWorkIdle
/NoYieldWindows
/Parallel /SpoolPrintout
/PollIdle 3
/Serial
/SetDef
/SetDefault
/SwitchRepeatInterval 1
/SwitchRepeatMax 5
/SwitchRepeatTicks -1
/SwitchSingleTicks 3
/WatchAppQueueWork on /AppQueueWork 250 /AppQueueBoost 1000
/YieldWindows off /SwitchSingleTicks -1

-----------------------------
Robert Holmgren
holmgren@xxxxxxxx
-----------------------------