Date : Sun, 15 Aug 2010 02:12:34 +0200
From : rick@... (Rick Murray)
Subject: Windows-friendlier 65Link server
On 15/08/2010 00:38, Tom Seddon wrote:
> I think that sleeping is the correct solution.
Hey, I'll drink to that! Zzzzzzz....
Oh, wait, we were talking multitasking. <yawn> Okay, Bagpuss mode off.
> I put "fair" in quotes delibately, because if something is doing
> work, surely it deserves the CPU more than anything else?
I would say so. The best you get on Windows is:
Windows-key + Break
"Advanced" tab
Performance "Settings" button
"Advanced" tab
Processor scheduling, adjust to favour:
Programs
Background services
Given the hoops to jump through to get there, I'd imagine few people
ever see this. ;-)
> So... sleep.
Okay. Zzzzzzzz... Oh, wait, sorry. ;-)
> Windows's approach is obviously suboptimal, because it sometimes
> doesn't work so well.
There's no such thing as optimal. I would *like* when I am watching a
movie on my computer for the movie to play, even if 1024x720 to the
possible detriment of anything else currently running. But that's me. If
you have an automated downloader, mail client, and usenet indexer
running in the background, you might want them to carry on. Indeed,
looking through the Minix3 ebook at scheduling methodologies, they all
have their strengths and weaknesses.
> I suppose Windows could do with some kind of UI for tweaking the
> scheduling behaviour for particular processes,
You can, Ctrl-Alt-Del, choose the "Processes" tab, right-click a
process, and you can set the priority Low/Below normal/Normal/Above
normal/High/Realtime.
You can also set the "affinity" to a particular processor (laugh hard
when you see the list run to CPU 31 - what sort of heatsink arrangement
do you think a 32-core piece of Intel silicon would require?) so you
could, in theory, affinate (yes, I made that word up) most of the
processes with one processor, while affinating your preferred process
with the other processor. But be careful, Azumi has two processors which
isn't *quite* true for an Aton N270...
That isn't exactly changing the scheduling *behaviour*, but doing so
could risk breaking more than it fixes.
To give you an example - Windows XP (etc) moved away from a
semi-monolithic kernel to a server/client based kernel. What this means
is that if Windows 98 pops up an error box, it also goes "ding!". But on
XP the noise is handled by a "server" that exists for making "ding!"
noises. Maybe some other stuff too. The change? Very small but painfully
evident. If the system has only recently started up with no noises
required, or is running under load with no noises in a while, there can
be a fairly noticable gap between a message box appearing, and its
associated "ding!".
> I suspect the mind-reading PC will arrive first.
I would run screaming from that. The terrible lag between thinking and
typing acts as a great sanity filter, and sometimes prevents me from
saying what I would say if I was a seven-foot pro-wrestler rather
than... <cough> this... a body like a podgy girl. ;-)
Besides, I write enough crap as it is. The world can do without a direct
connection to my mind.
This does, of course, lead on to something that has bugged me for
*years*. Ghost In The Shell, the original movie. The secretaries sprout,
like, a dozen fingers on each hand and type away frenetically. Come on,
they are mostly machines, wouldn't it be a heck of a lot quicker to
simply jack them in instead of going through a clunky mechanical
interface? Or was that done purely for the visuals?
> Interesting... though if you're just watching the dialog, that might
> explain it. If a high priority process will get 99% of an idle CPU, an
> idle priority process might get... 97%? 98%?
Let's put it like this. On Win98SE if I told the process to run itself
in supermegaohmygodzippedydoodahfast mode, it would do so to the extent
that clicking on the Explorer icon would show the system struggling to
load and run Explorer. You'd actually be able to sit and watch how
Windows 'builds' a dialogue because 95% of the time would be devoted to
the encoder, everything else would sit in the remaining 5%, of which
about 4.99% would be claimed by system tasks.
Under XP? The speed settings don't seem to change anything. I've had a
high-bitrate encoder running which interferes with the fluidity of a
highish bitrate XviD streamed over the LAN, so I tell the encoder to
kick back and take it easy... and it ignores me.
Probably a political alteration within the NT class kernel (all
processes were created equal [except the ones that Microsoft wrote]) and
that's how it shall remain and how dare the user attempt to upset the
status quo.
God, that sounds like an Appleism.
Best wishes,
Rick.
PS: Relevance to the Beeb? 6502, 2MHz, ~25Kb RAM, 256 byte stack.
Multitasking methodologies? RTOS? Think about it...
PPS: I outlined years ago a four-process fully-multitasking 6502
system with a largely re-entrant kernel. It required most of
page zero and did some horribly abusive things with the stack.
PPPS: I also coughed up an idea for an OS where the lower 2K of
memory resided in a 32K SRAM and you could bash a memory-mapped
logic gate to switch addressing, thus suggesting up to 15
entirely-independent multitasking applications (block zero was
for the OS) could maintain their own stack, page zero, etc.
The task switch logic and tables were kept in a higher area of
memory and, on paper, it would have worked pretty well. Bolt in
some memory fiddling higher up, like 16 blocks of 16K, a la
sideways RAM, and you'd have the potential of a small 8 bit micro
running up to 15 fully independent applications in time-slice
fashion. Of course, there's the eternal question of "why?" and
things did get somewhat messier when we hit scenarios like resource
sharing. If task A wants to load,process,write 120K from/to floppy,
how do we handle task B wanting floppy access? We could defer task
A briefly, run the two in sync (death-to-floppy-drive-mode) or
block. What if B wants the file A hasn't finished writing? Blocking
is the simplest solution, but in the case of MT it isn't the most
pleasing. But, as we saw from Windows, there's no method really that
is capable of pleasing everybody.
--
Rick Murray, eeePC901 & ADSL WiFI'd into it, all ETLAs!
BBC B: DNFS, 2 x 5.25" floppies, EPROM prog, Acorn TTX
E01S FileStore, A3000/A5000/RiscPC/various PCs/blahblah...