On 13-10-2011 23:48, Darren New wrote:
> On 10/13/2011 12:55, andrel wrote:
>> So that moves the question to: why is the ctrl-alt-del handler paged out?
>
> How much of it do you want to keep in core?

To address most issues in one: you have normal operation in a system and 
emergency situations. You should not design normal operations in such a 
way that you can not handle emergencies.
What i'd do* is have the CAD handler (and a primitive task handler) in a 
small space. Preferably in one self consistent page. Immediately suspend 
all running user level programs and switch to vga to prevent the GUI 
manager from page swapping.

*) at least without thinking all problems completely through.

> I've had very little trouble
> getting the CAD handler to come up in things like Vista, but the next
> step of picking something off the menu can cause a new program to get
> launched. However, it launches task manager or some such in XP, I forget.
>
>> And the UI: why has that to be on the GUI, with all the page faults
>> that may
>> result from swapping pixels to disk? Remember we are sending a low level
>> high importance interrupt and the user knows that.
>
> Well, yes. That gets handled right away, most likely. Then it has to
> *do* something in response. I'm not sure what your point is. Your
> keystroke is of course taken into the kernel pretty much immediately.
> It's the thing that comes after I'm talking about.
>
>> I know. I am just asking if there is still a reason to handle the kernel
>> like any other user process.
>
> The problem is not in the kernel's response. It's the fact that the
> complaint is the task manager takes a long time to come up, preventing
> you from killing the task.

Because the task manager is implemented at the same priority level as 
Blender?

> In UNIX terms, it's like complaining that /bin/kill takes a long time to
> load when the system is thrashing, and you asking why the kill() kernel
> trap would be paged out in the first place.

Can that happen?

>> But, is there any reason to stop the entire kernel because of a disk
>> seek?
>
> No. Nor does that happen. Otherwise, disk seeks wouldn't continue to get
> in the way?

What apparently happens is that a program causes a page fault, possibly 
holding up the kernel because it also needs a page. After the page is 
loaded it then gets an opportunity to create another page fault before 
the scheduler hands control back to the kernel.
My reaction as a user is: 'hello, I just pressed CAD, stop all other 
programs and process that interrupt before doing anything else!' 
Something is terribly wrong with the priorities of my machine.



-- 
Apparently you can afford your own dictator for less than 10 cents per 
citizen per day.

Post a reply to this message

On 10/14/2011 9:29, andrel wrote:
> What i'd do* is have the CAD handler (and a primitive task handler) in a
> small space.

I think this is more like what post-XP OSes do.

> Immediately suspend all running user level programs

Always mount a scratch monkey.

You really don't want the guy at the keyboard hitting CAD and suspending 
your corporate web server.

> and switch to vga to prevent the GUI manager
> from page swapping.

I don't think it goes that far, but certainly the newer CAD handlers could 
do something like that, visually speaking.

>> The problem is not in the kernel's response. It's the fact that the
>> complaint is the task manager takes a long time to come up, preventing
>> you from killing the task.
>
> Because the task manager is implemented at the same priority level as Blender?

No it isn't. The problem isn't with the CPU. The problem is with the disk. 
Now, the problem is that when the task manager pages in a page, now it's 
going to run long enough for Blender to ask for a page. Now you've started a 
disk seek, which you can't satisfy or abort before the task manager needs 
its next page.

One simple solution might be to page in the entire task-manager task rather 
than doing it on demand, but that's exactly the sort of "disk scheduling 
sucks in modern desktop OSes" that I'm talking about.

>> In UNIX terms, it's like complaining that /bin/kill takes a long time to
>> load when the system is thrashing, and you asking why the kill() kernel
>> trap would be paged out in the first place.
>
> Can that happen?

No. That's my point. You're complaining CAD is unresponsive, when the 
problem is that the user-level program you're trying to launch via CAD is 
unresponsive.

> What apparently happens is that a program causes a page fault, possibly
> holding up the kernel because it also needs a page.

The kernel doesn't need a page. That's why it's the kernel. The task manager 
needs the page. The task manager is a user-level program.

Analogously, kill(1) doesn't need a page. But /bin/kill does, because it's a 
user-level program, and it's the quickest way to actually invoke kill(1).

> After the page is loaded
> it then gets an opportunity to create another page fault before the
> scheduler hands control back to the kernel.

A page fault *is* handing control back to the kernel.

> My reaction as a user is: 'hello, I just pressed CAD, stop all other
> programs and process that interrupt before doing anything else!' Something
> is terribly wrong with the priorities of my machine.

Well, first, CAD is used for lots of stuff besides "I have too many page 
faults". Second, you don't want anyone sitting at the keyboard to shut down 
any process running on your machine. These *are* multi-user machines, you know.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

On 14-10-2011 19:09, Darren New wrote:
> On 10/14/2011 9:29, andrel wrote:
>> What i'd do* is have the CAD handler (and a primitive task handler) in a
>> small space.
>
> I think this is more like what post-XP OSes do.
>
>> Immediately suspend all running user level programs
>
> Always mount a scratch monkey.
>
> You really don't want the guy at the keyboard hitting CAD and suspending
> your corporate web server.

Nor do you want him to effectively freeze it for 10 minutes by doing 
something stupid. See also below.

>> and switch to vga to prevent the GUI manager
>> from page swapping.
>
> I don't think it goes that far, but certainly the newer CAD handlers
> could do something like that, visually speaking.
>
>>> The problem is not in the kernel's response. It's the fact that the
>>> complaint is the task manager takes a long time to come up, preventing
>>> you from killing the task.
>>
>> Because the task manager is implemented at the same priority level as
>> Blender?
>
> No it isn't. The problem isn't with the CPU. The problem is with the
> disk.

IIRC you have said that before. Actually several times and I have never 
contradicted you.

> Now, the problem is that when the task manager pages in a page,
> now it's going to run long enough for Blender to ask for a page. Now
> you've started a disk seek, which you can't satisfy or abort before the
> task manager needs its next page.
>
> One simple solution might be to page in the entire task-manager task
> rather than doing it on demand, but that's exactly the sort of "disk
> scheduling sucks in modern desktop OSes" that I'm talking about.
>
>>> In UNIX terms, it's like complaining that /bin/kill takes a long time to
>>> load when the system is thrashing, and you asking why the kill() kernel
>>> trap would be paged out in the first place.
>>
>> Can that happen?
>
> No. That's my point. You're complaining CAD is unresponsive, when the
> problem is that the user-level program you're trying to launch via CAD
> is unresponsive.

Actually my point is that it *should not* be a user program.

>> What apparently happens is that a program causes a page fault, possibly
>> holding up the kernel because it also needs a page.
>
> The kernel doesn't need a page. That's why it's the kernel. The task
> manager needs the page. The task manager is a user-level program.
>
> Analogously, kill(1) doesn't need a page. But /bin/kill does, because
> it's a user-level program, and it's the quickest way to actually invoke
> kill(1).
>
>> After the page is loaded
>> it then gets an opportunity to create another page fault before the
>> scheduler hands control back to the kernel.
>
> A page fault *is* handing control back to the kernel.

I know that (long, long time ago I studied OS's a bit). I obviously 
meant the part of the kernel (and user level program in badly designed 
systems) that handles the CAD.

>> My reaction as a user is: 'hello, I just pressed CAD, stop all other
>> programs and process that interrupt before doing anything else!'
>> Something
>> is terribly wrong with the priorities of my machine.
>
> Well, first, CAD is used for lots of stuff besides "I have too many page
> faults". Second, you don't want anyone sitting at the keyboard to shut
> down any process running on your machine. These *are* multi-user
> machines, you know.

I disagree, there is no other user on my machine than me*. And that is 
also why your corporate webserver is a wrong example. webservers and 
user machines are something different. You should not mix those. Or at 
least the OS should behave different. Specifically in the area that we 
are discussing. CAD on a webserver should leave everything running 
(probably should even be disabled), but when I press CAD on my keyboard 
because I want control, i *want control* and I know what other processes 
I am also stopping.

*) that is at least my view of the machine. Technically it is not true.

-- 
Apparently you can afford your own dictator for less than 10 cents per 
citizen per day.

Post a reply to this message

On 10/14/2011 12:36, andrel wrote:
>> You really don't want the guy at the keyboard hitting CAD and suspending
>> your corporate web server.
>
> Nor do you want him to effectively freeze it for 10 minutes by doing
> something stupid. See also below.

Agreed.

>>> Because the task manager is implemented at the same priority level as
>>> Blender?
>>
>> No it isn't. The problem isn't with the CPU. The problem is with the
>> disk.
>
> IIRC you have said that before. Actually several times and I have never
> contradicted you.

Well, sure. But the problem is that nobody implements effective disk 
priorities any more (which is what I'm saying), so just saying "priority" 
implies CPU priority.

> Actually my point is that it *should not* be a user program.

That's likely true.  However, the frequency with which this happens probably 
doesn't warrant a kernel mechanism for a UI for picking a task and killing 
it, either. Especially since many times it happens, it's nothing to do with 
a task that's still running that you could actually do anything about.

Indeed, it would seem what you'd really want is a way to indicate that if a 
job got to the point where it was paging too often, that would be enough to 
kill it or deprioritize its disk I/O, to the point of suspending it for a 
second or more each time some other process went after the disk, sort of 
like how Linux (seems to) does "low priority" disk I/O.

> I know that (long, long time ago I studied OS's a bit). I obviously meant
> the part of the kernel (and user level program in badly designed systems)
> that handles the CAD.

Oh, well, you want an entire process management system built into the 
kernel, invocable by a simple keystroke. Probably not realistic in modern OSes.

> I disagree, there is no other user on my machine than me*. And that is also
> why your corporate webserver is a wrong example. webservers and user
> machines are something different. You should not mix those.

If your corporate web server is thrashing, how are you going to stop it?

> OS should behave different. Specifically in the area that we are discussing.
> CAD on a webserver should leave everything running (probably should even be
> disabled), but when I press CAD on my keyboard because I want control, i
> *want control* and I know what other processes I am also stopping.

Well, as the Linux enthusiasts would say, "we eagerly await your patch." :-)

CAD should certainly not be disabled on a web server, as it does far more 
than just bring up the task manager. That's the other half of the problem.

In pretty much every situation other than disk thrashing, CAD works pretty 
much instantly. In many cases of disk thrashing, there's nothing you can do 
about it, like my example of sync'ing gigabytes of changes to the disk. And 
modern OSes are set up to treat file reading and page faulting as 
essentially similar in many ways (and then there's memmap, which adds 
another confusion on top), so it's not really even obvious when there's 
thrashing which process is causing it or what to do about it, because it's 
entirely possible there wouldn't be thrashing if there weren't 3 or 4 
programs all doing something at once.

> *) that is at least my view of the machine. Technically it is not true.

Well, that's kind of the point I'm making. :)

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

On 15-10-2011 1:02, Darren New wrote:
> On 10/14/2011 12:36, andrel wrote:

>> Actually my point is that it *should not* be a user program.
>
> That's likely true. However, the frequency with which this happens
> probably doesn't warrant a kernel mechanism for a UI for picking a task
> and killing it, either. Especially since many times it happens, it's
> nothing to do with a task that's still running that you could actually
> do anything about.
>
> Indeed, it would seem what you'd really want is a way to indicate that
> if a job got to the point where it was paging too often, that would be
> enough to kill it or deprioritize its disk I/O, to the point of
> suspending it for a second or more each time some other process went
> after the disk, sort of like how Linux (seems to) does "low priority"
> disk I/O.
>
>> I know that (long, long time ago I studied OS's a bit). I obviously meant
>> the part of the kernel (and user level program in badly designed systems)
>> that handles the CAD.
>
> Oh, well, you want an entire process management system built into the
> kernel, invocable by a simple keystroke. Probably not realistic in
> modern OSes.

Taking both points together. Breaking out to a program that just lets 
you modify priorities would be enough. If that process runs at the 
highest level itself it would solve most of the problems.
That said, windows does have a priority mechanism, and the taskmanager 
is running at a high level, two levels higher than Blender and Matlab, 
so why does it not work?

>
>> I disagree, there is no other user on my machine than me*. And that is
>> also
>> why your corporate webserver is a wrong example. webservers and user
>> machines are something different. You should not mix those.
>
> If your corporate web server is thrashing, how are you going to stop it?

If it is because someone is using it for other things, like POVray, 
Blender or a game fire that person. If it is because of tasks that 
should run there fire the IT manager or the financial director, 
depending on who was responsible for buying the wrong infrastructure.

>> OS should behave different. Specifically in the area that we are
>> discussing.
>> CAD on a webserver should leave everything running (probably should
>> even be
>> disabled), but when I press CAD on my keyboard because I want control, i
>> *want control* and I know what other processes I am also stopping.
>
> Well, as the Linux enthusiasts would say, "we eagerly await your patch."
> :-)

Windows is open source now? I missed that.

> CAD should certainly not be disabled on a web server, as it does far
> more than just bring up the task manager. That's the other half of the
> problem.
>
> In pretty much every situation other than disk thrashing, CAD works
> pretty much instantly. In many cases of disk thrashing, there's nothing
> you can do about it, like my example of sync'ing gigabytes of changes to
> the disk. And modern OSes are set up to treat file reading and page
> faulting as essentially similar in many ways (and then there's memmap,
> which adds another confusion on top), so it's not really even obvious
> when there's thrashing which process is causing it or what to do about
> it, because it's entirely possible there wouldn't be thrashing if there
> weren't 3 or 4 programs all doing something at once.
>
>> *) that is at least my view of the machine. Technically it is not true.
>
> Well, that's kind of the point I'm making. :)


-- 
Apparently you can afford your own dictator for less than 10 cents per 
citizen per day.

Post a reply to this message

On 10/15/2011 2:08, andrel wrote:
 > That said, windows does have a priority mechanism, and the taskmanager is
 > running at a high level, two levels higher than Blender and Matlab, so why
 > does it not work?

Because you're confusing disk priorities with CPU priorities, and you can't 
easily interrupt a disk seek. That's kind of what I've been saying. In the 
length of time it takes the Task Manager to get to the next page-in, Blender 
has already run far enough to trigger a page fault on its own.

 > If it is because someone is using it for other things, like POVray, Blender
 > or a game fire that person. If it is because of tasks that should run there
 > fire the IT manager or the financial director, depending on who was
 > responsible for buying the wrong infrastructure.

But you might not know. And you might not be able to easily tell. And you 
might be running multiple tasks on the same machine, or even multiple 
operating systems nowadays.

 > Windows is open source now? I missed that.

No. Fix it in Linux. :-)  Linux does exactly the same thing.

Post a reply to this message

On Mon, 10 Oct 2011 11:11:45 +0100, Invisible wrote:

>>> So, just because it does strong authentication, you think that means
>>> the actual data is encrypted?
>>
>> It's actually a certificate verification message, not a 'strong
>> authentication' message.  It's asking about an SSL certificate that's
>> used to encrypt the entire communications channel.
>>
>> You know, like actual security.
> 
> Fact: It doesn't matter how strong the authentication process is. This
> does not automatically mean that the data that follows is encrypted in
> any way at all.

No, it doesn't - the fact that it actually *is* encrypted is what means 
that it is, you know, encrypted.

>> Don't believe me?  Fine, I'll do a wireshark trace on it.
>>
>> Nope, 1200 packets, nothing in the clear.
> 
> And how do you tell whether random binary data is encrypted or not?

There's nothing "in the clear".  I connected to the system, opened a CMD 
window, and listed directory contents.

That, plus the fact that it, you know, actually is *documented* to be 
encrypted.

The fact that you don't *believe* the documentation doesn't, you know, 
actually mean it's not encrypted.

How do you know your VPN is encrypted?  Because it *says* so?  What are 
you, nuts? ;)

>> "128-bit encryption, using the RC4 encryption algorithm, as of Version
>> 6.
> 
> RC4? Man, how ancient is that? You realise it was a weakness in RC4 that
> allowed WEP to be broken, right?

Yes, I do.  However, *weak* encryption is still, you know, *encryption*.

>> Nope, I guess you're right.  Adding 128-bit encryption isn't security.
> 
> Fact: The number of bits in the encryption key is not directly related
> to how secure the encryption is. Triple DES has a 168-bit key, and it's
> widely considered far too insecure to use.

But it's still encryption.  You asserted that it's not encrypted.  I 
proved that it was.  Now, if you want to talk about encryption 
*strength*, that's different than, you know, whether it's encrypted or 
not.

>> "Support for Transport Layer Security (TLS) 1.0 on both server and
>> client ends (set as default)."
> 
> Now that's more like it.
> 
> (Sadly, on further investigation, it appears that TLS 1 still uses RC4
> or Triple-DES. So much for HTTPS being secure...)

But it's still *encrypted*, which you categorically claimed it wasn't.

>> Clearly I don't have a clue what I'm talking about.
> 
> I'm still left wondering how many of these features are actually turned
> on by default. Every Windows protocol I know of sends everything
> unencrypted by default, and most of them offer no possibility of adding
> encryption. I'd be rather surprised if RDP is different.

Well, it's just documented as being enabled by default.  Like your VPN.  
How do you know your VPN is actually encrypted?

>> Oh, and I pointed you at an SSH server for Windows.  It comes with
>> Cygwin.
> 
> Right. I didn't know about that when I set this up.

You knew about it before you made this post.  So now you know it's 
available so you can use it.  That is if you believe that SSH is actually 
encrypted.  After all, you just have the documentation to tell you that - 
because it's a stream of random binary data.  It may well not be 
encrypted.  You don't know.  Just like RDP.

Jim

Post a reply to this message

On Tue, 11 Oct 2011 09:00:11 +0100, Invisible wrote:

>>> Also, it contains far less information than a STOP message does.
>>> Basically
>>> an error code (plus textual translation) and a memory address. Good
>>> luck working out, say, what was *at* that address or anything...
>>
>> That's why the power light flashes 3 times before the message comes up.
>> That's you're cue to hit DEL on the serial terminal plugged in to the
>> back to launch the kernel debugger.
> 
> Uh, what's a serial terminal? Also, what's a kernel debugger?

*facepalm*

Jim

Post a reply to this message

On Thu, 13 Oct 2011 09:20:00 +0100, Invisible wrote:

> On 12/10/2011 05:17 PM, Darren New wrote:
>> On 10/12/2011 1:13, Invisible wrote:
>>> Now given that the Amiga is a home computer, how many homes have a
>>> VT100 just laying around?
>>
>> The VT100 is not the only serial terminal. Anything that talks RS232
>> serial is sufficient. You know, like, another Amiga, say?
> 
> Oh, OK.
> 
> So what can you actually do with a "kernel debugger", anyway? Just look
> around the machine's memory or something?

Yes, that's exactly what a kernel debugger is for.  Debugging the kernel, 
hence the name. ;)

Jim

Post a reply to this message

On Mon, 10 Oct 2011 11:00:02 +0100, Invisible wrote:

> On 09/10/2011 10:00 PM, Jim Henderson wrote:
> 
>> The point was that Andy said that binary blob data could be stored in
>> the registry and not a Linux configuration file.  Point is, it could be
>> stored in a Linux data file, but since it's common to change
>> configuration items with an editor in Linux, it's not common to use a
>> binary format (though the timezone file is an exception to that IIRC).
> 
> The point being, if you want to store some binary data in the middle of
> a textual configuration file, you have to base64 encode it or something
> (which is less efficient). If you want to stick some binary data in the
> registry, you can just store it as binary.

No, you don't have to encode it as base64.  It's perfectly legal to 
create a file with text components and binary components.  Because it's 
just a file.

Jim

Post a reply to this message