Vista filesystem redirection

[VirtualLarry]

Just came across this: http://dansdata.com/askdan00001.htm

2: No automatic registry and file redirection, which is what 32-bit Vista uses to allow existing software to work with Vista's better user account security, even if the software wants to do admin-rights stuff to the registry and Program Files directory. Many apps still break in 32-bit Vista, but many more break in the 64-bit version.

Is this true?

I had figured that this feature was present in both versions of Vista, but apparently not? Why would MS leave this important feature out of the 64-bit version? After all, it is still intended to run 32-bit apps, some (many?) of which are not Vista- or even XP-aware.

Also the info that Vista Home Basic is limited to 8GB of RAM - I've never seen that mentioned in MS's feature-comparison charts documenting the different versions of Vista. Could it be that they are attempting to sweep that little factoid under the rug?

 

[spyordie007]

Originally posted by: VirtualLarry
Just came across this: http://dansdata.com/askdan00001.htm

2: No automatic registry and file redirection, which is what 32-bit Vista uses to allow existing software to work with Vista's better user account security, even if the software wants to do admin-rights stuff to the registry and Program Files directory. Many apps still break in 32-bit Vista, but many more break in the 64-bit version.

Is this true?

I had figured that this feature was present in both versions of Vista, but apparently not? Why would MS leave this important feature out of the 64-bit version? After all, it is still intended to run 32-bit apps, some (many?) of which are not Vista- or even XP-aware.

Also the info that Vista Home Basic is limited to 8GB of RAM - I've never seen that mentioned in MS's feature-comparison charts documenting the different versions of Vista. Could it be that they are attempting to sweep that little factoid under the rug?

I'll have to wait until I'm at a 64bit box to confirm, but I'm 95% sure that is incorrect. Disabling UAC will loose you the virtual store, but not going 64bit.

As for Vista Home Basic I'd assume that it's just not important for that market segment. I cant imagine there are many out there that are looking to run > 8GB and are seriously considering Home Basic.

 

[spyordie007]

Close enough to be confirmation that file and registry virtualization are included in Vista x64 (note "applies to" section at the end):
http://support.microsoft.com/kb/927387

 

[bsobel]

Originally posted by: VirtualLarry
Just came across this: http://dansdata.com/askdan00001.htm

2: No automatic registry and file redirection, which is what 32-bit Vista uses to allow existing software to work with Vista's better user account security, even if the software wants to do admin-rights stuff to the registry and Program Files directory. Many apps still break in 32-bit Vista, but many more break in the 64-bit version.

Is this true?

I had figured that this feature was present in both versions of Vista, but apparently not? Why would MS leave this important feature out of the 64-bit version? After all, it is still intended to run 32-bit apps, some (many?) of which are not Vista- or even XP-aware.

It's incorrect. What it should be saying is that on Vista 64 32bit apps ARE virtualized (the feature is there, I promise you, I'm on a V64 rig). Howevever 64bit processes are NOT virtualized. The decision was made to expect 64bit code (since it would be new) to properly adhere to the guidelines (e.g. no writing user data to the program files path, etc) while 32bit code was given the bandaid so it would be compaitble. The article you linked is 100% wrong on this point.

Also the info that Vista Home Basic is limited to 8GB of RAM - I've never seen that mentioned in MS's feature-comparison charts documenting the different versions of Vista. Could it be that they are attempting to sweep that little factoid under the rug?

Larry, stop trolling. This little 'factoid' has been listed on every comparision I've seen, it's certainly no secret. OS version memory limits Further we are discussing Home Basic, it's not an OS choice for people with more than 8gig in their rigs. Do you just spend your time looking for non-issues to bring up? I remember a year of this when XP came out (your famous threads about Hibernation being the work of the devil and MS was wrong for putting into XP :roll, are you almost done yet with Vista or do you still need 5 more months?

 

[VirtualLarry]

Originally posted by: bsobel
It's incorrect. What it should be saying is that on Vista 64 32bit apps ARE virtualized (the feature is there, I promise you, I'm on a V64 rig). Howevever 64bit processes are NOT virtualized. The decision was made to expect 64bit code (since it would be new) to properly adhere to the guidelines (e.g. no writing user data to the program files path, etc) while 32bit code was given the bandaid so it would be compaitble. The article you linked is 100% wrong on this point.

Thanks, makes perfect sense now. I thought that the article sounded a bit funny.

Originally posted by: bsobel

Also the info that Vista Home Basic is limited to 8GB of RAM - I've never seen that mentioned in MS's feature-comparison charts documenting the different versions of Vista. Could it be that they are attempting to sweep that little factoid under the rug?

Larry, stop trolling. This little 'factoid' has been listed on every comparision I've seen, it's certainly no secret. OS version memory limits Further we are discussing Home Basic, it's not an OS choice for people with more than 8gig in their rigs. Do you just spend your time looking for non-issues to bring up? I remember a year of this when XP came out (your famous threads about Hibernation being the work of the devil and MS was wrong for putting into XP :roll, are you almost done yet with Vista or do you still need 5 more months?

How in the world am I trolling? That "factoid" is NOT present on any consumer-level Vista comparison charts that I've ever seen. I'm glad that you were able to find some documentation on that, but that's a very technical doc, most consumers do NOT search MSDN. Look at MS's official comparison chart: http://www.microsoft.com/windo...a/editions/choose.mspx
Do you see any mention of the memory limitations? I certainly don't. It's not on the actual OS boxes either.


And my threads detailing how using hibernate incorrectly could cause serious filesystem corruption, were very important. MS doesn't document how to use hibernation, and using it incorrectly could have serious consequences for your data. Wouldn't you want to know, if there were a risk? I know I would. I was appalled when I found out about the issue. It certainly wasn't a troll.

 

[Nothinman]

Do you see any mention of the memory limitations? I certainly don't. It's not on the actual OS boxes either.

And? The limit is 4x what most people running Vista will have and most likely anyone wanting even 4G of memory, let alone >8G, will at least get Home Premium.

MS doesn't document how to use hibernation, and using it incorrectly could have serious consequences for your data.

There are tons of ways to lose data by doing things incorrectly. There's only so much you can do to protect people from themselves.

It certainly wasn't a troll.

That's debatable. I don't even remember the specific thread bsobel's talking about but from the tone of all of your threads that I have seen I'm willing to side with him.

 

[VirtualLarry]

It's difficult to infer "tone", I think that you are just falling for the suggestiveness of Bsobel and Smilin. I mean, was this thread a "troll"? Thank you.

PS. I'm only a "troll", because I dare post negative things about MS. See the "big thread" for another user's comment about bsobel's "tunnel vision" regarding negative threads about MS.

Edit: "Big thread" being this one: http://forums.anandtech.com/me...=2061129&enterthread=y

 

[bsobel]

PS. I'm only a "troll", because I dare post negative things about MS. See the "big thread" for another user's comment about bsobel's "tunnel vision" regarding negative threads about MS.

Larry there any many people, including myself, you post negative things about Microsoft. The issue many people have with you is you post an opinion as fact or try to find a minor issue and make it into the second comming (the hibernation non-issue, for example) and when shown to be wrong trying to subtlely change the argument into something else. There are numerous threads where you've been called out on this behaviour by myself, Smilin, and plenty of others.

 

[Nothinman]

It's difficult to infer "tone", I think that you are just falling for the suggestiveness of Bsobel and Smilin.

Sure it's possible to get the wrong impression from plain text but pretty much all of your threads have a very negative wording to them and are usually factually incorrect. bsobel and Smilin aren't suggestive at all, they usually know what they're talking about and while no one is completely unbiased they're usually pretty objective.

I mean, was this thread a "troll"? Thank you.

Seems like it. You're welcome.

 

[VirtualLarry]

Originally posted by: bsobel

PS. I'm only a "troll", because I dare post negative things about MS. See the "big thread" for another user's comment about bsobel's "tunnel vision" regarding negative threads about MS.

Larry there any many people, including myself, you post negative things about Microsoft. The issue many people have with you is you post an opinion as fact or try to find a minor issue and make it into the second comming (the hibernation non-issue, for example) and when shown to be wrong trying to subtlely change the argument into something else. There are numerous threads where you've been called out on this behaviour by myself, Smilin, and plenty of others.

You mean like when you claimed that Hyperthreading was "unsupported" in W2K, and I proved to you explicitlyotherwise, and you attempted to change the question to one of performance, which was no-where in the original argument, just to attempt to prove that you were right?

So in addition to not being man enough to simply admit that you were wrong, and in addition to mounting a public smear campaign against me (calling me a liar, without justification - I've never lied on these forums), now you're being a hypocrite as well? Touche.

PS. Potential data-corruption is NEVER a "non-issue".

 

[spyordie007]

I mean, was this thread a "troll"? Thank you.

In all fairness I'd say that the OP was not a troll; however your comment regarding the RAM requirements were certainly pessimistic-at-best.

In general Bill is absolutely spot-on. I've seen numerous threads where you put up your opinion as fact. Your 2K HT comment above is a good example of this; just because it works fine a lot of the time (and in all of your limited experience) you claim it's supported. The simple truth is that Hyperthreading has never been supported in Windows 2000.

Maybe I'm missing something on the data-corruption comment, is that referring to a different thread? I tend to ignore most threads after they've hit a dozen or so posts because there isn't much to add to the conversation (what's the count on this thread at now ).

 

[bsobel]

Your 2K HT comment above is a good example of this; just because it works fine a lot of the time (and in all of your limited experience) you claim it's supported. The simple truth is that Hyperthreading has never been supported in Windows 2000.

You pretty much summed up that thread. He said it was supported because, well, he was running a HT proc. We tried to explain to him the scheduler wasn't HT aware, but it's like talking to a child.

HT on 2k
MS on HT

"Although Windows recognizes all eight logical processors in this example, in most cases performance would be better using eight physical processors."
"Windows 2000 Server does not distinguish between physical and logical processors on systems enabled with Hyper-Threading Technology; Windows 2000 simply fills out the license limit using the first processors counted by the BIOS."

You brought it back up, and your still wrong.

Maybe I'm missing something on the data-corruption comment, is that referring to a different thread? I tend to ignore most threads after they've hit a dozen or so posts because there isn't much to add to the conversation (what's the count on this thread at now ).

Larry claims hibernation is one of the worst features ever put into Windows because it causes constant data loss. His as always incorrect basis is that end users are going around upgrading their machines not knowing the difference between 'Off' and 'Hibernate' which leads them to open the machines while hibernating and the wake up process fails (thus data loss). It's just another of his BS contortions.

And to Larry, you know if it was just me, maybe you ccould argue we just don't get along. But hmm, myself, smilin, nothinman, spyordie007.... Starting to see a pattern? You know what, maybe it is the fact that your our resident OS troll.

 

[bsobel]

So in addition to not being man enough to simply admit that you were wrong, and in addition to mounting a public smear campaign against me (calling me a liar, without justification - I've never lied on these forums), now you're being a hypocrite as well? Touche.

I wasn't wrong, you were, and still are. I have called you a liar, I did so in posts when you lied. I have not called you a liar in a recent thread, because I have not caught you recently liying. I have called you a troll, because I have caught you trolling.

 

[VirtualLarry]

Originally posted by: spyordie007

I mean, was this thread a "troll"? Thank you.

In all fairness I'd say that the OP was not a troll; however your comment regarding the RAM requirements were certainly pessimistic-at-best.

In general Bill is absolutely spot-on. I've seen numerous threads where you put up your opinion as fact. Your 2K HT comment above is a good example of this; just because it works fine a lot of the time (and in all of your limited experience) you claim it's supported. The simple truth is that Hyperthreading has never been supported in Windows 2000.

Absolutely wrong.

http://h18000.www1.hp.com/prod...reading-ossupport.html

Windows 2000 supports Hyper-Threading technology, but counts logical processors towards licensing.

The scheduler was specifically re-engineered in SP4 to support HyperThreading technology. Performance of HT is application-dependent.

Read that again - it is supported, but there are no performance guarantees associated with it. XP is optimized for HyperThreading, W2K is not. But it is "supported".

Bill claimed that it wasn't. He was (and is) wrong.

 

[VirtualLarry]

Originally posted by: bsobel

Your 2K HT comment above is a good example of this; just because it works fine a lot of the time (and in all of your limited experience) you claim it's supported. The simple truth is that Hyperthreading has never been supported in Windows 2000.

You pretty much summed up that thread. He said it was supported because, well, he was running a HT proc. We tried to explain to him the scheduler wasn't HT aware, but it's like talking to a child.

No bill, I didn't say that because I was running a HT proc. In fact, I've never owned a processor with HyperThreading. My discussion about the matter was based on official technical documentation.
When you say "HT aware", what do you mean by that? Because the scheduler in W2K SP4 was specifically modified to support Intel's HyperThreading technology. They use HLT to stop idle threads, and YIELD in spinlocks to reduce contention. As per Intel's guidance regarding programming for HyperThreading.

If you are talking about the per-CPU licensing issues, I have never disgreed with the fact that W2K's CPU licensing is different than XP's, with respect to processors with HyperThreading technology. That's clearly spelled out in the Microsoft documentation.

Originally posted by: bsobel
HT on 2k
MS on HT
"Although Windows recognizes all eight logical processors in this example, in most cases performance would be better using eight physical processors."
"Windows 2000 Server does not distinguish between physical and logical processors on systems enabled with Hyper-Threading Technology; Windows 2000 simply fills out the license limit using the first processors counted by the BIOS."

And? That's a pretty weak comeback. Of course 8 physical processors are going to offer more performance than 8 logical (HT) processors - the physical processors have a full dedicated execution core, whereas the logical (HT) processors have to share the resources of one execution core. This is standard knowledge about HyperThreading technology in general, and in no way relates to wether or not W2K's scheduler supports processors with HyperThreading. You have a tendency to post only tangentally-relevant links, to "prove" your point. The second point has to do with licensing issues, which I already stated that I don't disagree with.

The technical fact is that W2K's scheduler was specifically modified to support HyperThreading technology in SP4, I've proved it with MS's own whitepaper on the subject in the thread that we had the argument in, and you have yet to refute that specific and very correct key fact.

Originally posted by: bsobel
You brought it back up, and your still wrong.

Maybe I'm missing something on the data-corruption comment, is that referring to a different thread? I tend to ignore most threads after they've hit a dozen or so posts because there isn't much to add to the conversation (what's the count on this thread at now ).

Larry claims hibernation is one of the worst features ever put into Windows because it causes constant data loss. His as always incorrect basis is that end users are going around upgrading their machines not knowing the difference between 'Off' and 'Hibernate' which leads them to open the machines while hibernating and the wake up process fails (thus data loss). It's just another of his BS contortions.

No bill, I did NOT claim that hibernation leads to "constant data loss". Nor did I claim the data-corruption was due to the wakeup process failing. What I pointed out was that the hibernation image caches filesystem data, and that if you hibernate, and then dual-boot or use a bootdisk or otherwise access and modify the filesystem, then when you resume from hybernation, the (now stale) filesystem data will overwrite the modified filesystem data and you will end up with a mess.

I claimed that hybernation was risky and that MS should have put in a warning, about how to properly use hybernation so that it doesn't result in data-loss. There is probably more than one enthusiast out there that has tried hybernating and dual-booting, and I wonder how many of them know about the data-loss problem? That's why I posted about it, as enthusiasts are more likely to do things that are "outside the box" than your ordinary Joe User. I also personally tested the issue, and confirmed the data-loss.

Originally posted by: bsobel
And to Larry, you know if it was just me, maybe you ccould argue we just don't get along. But hmm, myself, smilin, nothinman, spyordie007.... Starting to see a pattern? You know what, maybe it is the fact that your our resident OS troll.

And? Your public smear campaign is working, sad to say. I'm still curious as to what you thought I was lying about, because I'd like a chance to defend myself about that. Was it the Vista DS3D emulation thing? Because I posted my response in that thread, and BD2003 tested DS3D apps with RightMark, and it appears that there IS an emulation layer.

 

[bsobel]

When you say "HT aware", what do you mean by that? Because the scheduler in W2K SP4 was specifically modified to support Intel's HyperThreading technology. They use HLT to stop idle threads, and YIELD in spinlocks to reduce contention. As per Intel's guidance regarding programming for HyperThreading.

Given two schedulable threads of execution and 4 cores (two hyperthreaded cores on two physical cpu's) the scheduler should schedule one thread on proc 1 and the second thread on proc 2. W2K doesnt' know the difference between physcial and logical procs and will happily schedule both threads on one physical core (since it see them as two physical cpu's).

But who are we to argue. I've explained this to you. A *MICROSOFT* employee has pointed it out to you. But alas, as always, you think you know better.

And? That's a pretty weak comeback. Of course 8 physical processors are going to offer more performance than 8 logical (HT) processors - the physical processors have a full dedicated execution core, whereas the logical (HT) processors have to share the resources of one execution core.

See above. The scheduler doesnt know the difference, the difference is critical when scheduling.

No bill, I did NOT claim that hibernation leads to "constant data loss". Nor did I claim the data-corruption was due to the wakeup process failing. What I pointed out was that the hibernation image caches filesystem data, and that if you hibernate, and then dual-boot or use a bootdisk or otherwise access and modify the filesystem, then when you resume from hybernation, the (now stale) filesystem data will overwrite the modified filesystem data and you will end up with a mess.

:roll: I'll let other comment and the rediculousness of your theory. In short, your still wrong. You claimed this was hurting end users constantly and MS should *never* have made hibernation an option.

And? Your public smear campaign is working, sad to say. I'm still curious as to what you thought I was lying about, because I'd like a chance to defend myself about that. Was it the Vista DS3D emulation thing? Because I posted my response in that thread, and BD2003 tested DS3D apps with RightMark, and it appears that there IS an emulation layer.

Yes Larry, I've spent my time turning everyone against you. As for lying. You brought it up, link the thread in which I mentioned it, as that will be the thread in which you lied.

 

[Nothinman]

What I pointed out was that the hibernation image caches filesystem data, and that if you hibernate, and then dual-boot or use a bootdisk or otherwise access and modify the filesystem, then when you resume from hybernation, the (now stale) filesystem data will overwrite the modified filesystem data and you will end up with a mess.

Actually one of the biggest annoyances of Win2K's hibernation was that it didn't save the filesystem cache, so once the system resume'd you still had to wait while it paged back in all of he stuff that was cached before hand. But but sure, if you mount and modify a filesystem that's mounted by the the hibernated OS then you're asking for trouble.

I claimed that hybernation was risky and that MS should have put in a warning, about how to properly use hybernation so that it doesn't result in data-loss. There is probably more than one enthusiast out there that has tried hybernating and dual-booting, and I wonder how many of them know about the data-loss problem? That's why I posted about it, as enthusiasts are more likely to do things that are "outside the box" than your ordinary Joe User. I also personally tested the issue, and confirmed the data-loss.

Hibernation is spelled with an "i"...

And? Your public smear campaign is working, sad to say. I'm still curious as to what you thought I was lying about, because I'd like a chance to defend myself about that. Was it the Vista DS3D emulation thing? Because I posted my response in that thread, and BD2003 tested DS3D apps with RightMark, and it appears that there IS an emulation layer.

The only campaign going on is the one you've been putting on with your own threads...

 

[VirtualLarry]

Originally posted by: bsobel

When you say "HT aware", what do you mean by that? Because the scheduler in W2K SP4 was specifically modified to support Intel's HyperThreading technology. They use HLT to stop idle threads, and YIELD in spinlocks to reduce contention. As per Intel's guidance regarding programming for HyperThreading.

Given two schedulable threads of execution and 4 cores (two hyperthreaded cores on two physical cpu's) the scheduler should schedule one thread on proc 1 and the second thread on proc 2. W2K doesnt' know the difference between physcial and logical procs and will happily schedule both threads on one physical core (since it see them as two physical cpu's).

No it won't, Bill. You obviously didn't read the whitepaper then. It goes into a fairly extensive discussion about this issue, and references issues about BIOS ordering of CPU listings in the MADT BIOS tables, and why your scenario does not happen on a properly configured system.
Here's a link to the whitepaper again: http://www.2cpu.com/Hardware/h...sis/hyperthreading.doc
Read sections 3.1 and 4.1, and pay attention to the diagrams, specifically figure 4.

Originally posted by: bsobel
But who are we to argue. I've explained this to you. A *MICROSOFT* employee has pointed it out to you. But alas, as always, you think you know better.

No Bill, it is YOU that thinks he knows better. I've been quoting direct sources (Microsoft, Compaq) for my information. But yet you refuse to listen or understand. Where are your sources? Your opinion? Some Microsofties' opinion? I haven't been posting my opinion, I've been posting FACT, Bill. Something that apparently escapes you, but shouldn't escape the astute reader reading this.


Again, the OFFICIAL Microsoft stance on HyperThreading and Windows 2000:

The Windows operating systems that are supported for logo qualification on HT-enabled systems include:
? All versions of Windows 2000
? All 32-bit versions of Windows XP and Windows .NET Server

This white paper describes the level of support for HT that is provided in these Windows operating systems. No other currently available Windows operating systems are supported.

http://www.2cpu.com/Hardware/h...sis/hyperthreading.doc

The OFFICIAL Compaq Computer stance on HyperThreading and Windows 2000:

Windows 2000 supports Hyper-Threading technology, but counts logical processors towards licensing.

http://h18000.www1.hp.com/prod...reading-ossupport.html

You can continue to be as stubborn as you want, Bill - after all, it's a free country. But I've quoted the FACTS, ones that you cannot deny. Those FACTS state that Windows 2000 supports HyperThreading.

Hopefully that will put an end to this futile argument of yours.

Originally posted by: bsobel
Yes Larry, I've spent my time turning everyone against you. As for lying. You brought it up, link the thread in which I mentioned it, as that will be the thread in which you lied.

You claimed that I "blatantly lied". I can't find the thread, but I assure you that I did NOT lie in that thread. You made no specific reference to what I was lying about. Therefore, you were simply defaming me, without reason. Hence the reason why I accused you of a smear campaign. How could it be anything else?

 

[bsobel]

Larry, I posted a MS document describing the issue. I've sat in meetings with MS and Intel on this. The links speak for themselves, your wrong. There is no 'properly configured system', the scheduler doesnt know the difference between physical and logical procs and won't load balance physical before logical. Bios ordering only helps in the licensing case (in which physical procs will be used before logical). But give the dual core HT issue where W2K sees 4 procs, it won't correctly schedule on the physical procs BEFORE using the logical ones. It treats all procs as equal for scheduling decisions which is the wrong approach on a HT system.

In order to properly support HT the scheduler must schedule threads on physical procs first, then on logical procs. That is why you keep seeing all the statements about how 2K treats all proces as physical ones.

MS agrees, Intel agrees, it's only you who seems to think they know better.

 

[bsobel]

Read sections 3.1 and 4.1, and pay attention to the diagrams, specifically figure 4.

Section 4.1, the one titled "4.1 Operating Systems That Are Not Hyper-Threading Aware (Windows 2000)". Sheesh....

 

[Nothinman]

Read sections 3.1 and 4.1, and pay attention to the diagrams, specifically figure 4.

I think it's you who should read them again. The very second sentence of section 4.1 says "However, neither Windows 2000 nor any of its service packs support the identification of HT processors." and the first sentence in the second paragraph says "As a result, Windows 2000 treats each logical processor as if it were an individual physical processor." which means that while it will use all of the logical processors it isn't smart enough to schedule them intelligently because it thinks that they're all separate physical processors. Why is that so difficult to understand?

 

[bsobel]

Originally posted by: Nothinman

Read sections 3.1 and 4.1, and pay attention to the diagrams, specifically figure 4.

I think it's you who should read them again. The very second sentence of section 4.1 says "However, neither Windows 2000 nor any of its service packs support the identification of HT processors." and the first sentence in the second paragraph says "As a result, Windows 2000 treats each logical processor as if it were an individual physical processor." which means that while it will use all of the logical processors it isn't smart enough to schedule them intelligently because it thinks that they're all separate physical processors. Why is that so difficult to understand?

Larry, maybe an example will help. Lets take a dual proc HT system. In this system we have 2 physical procs each with 2 logical ones. W2K sees four cores. You launch 4 threads, the system will ideally schedule one thread per virtual core (e.g. each seen proc will now have 1 thread running on it). If you now stop 2 of those threads and both of those threads where running on physical proc A you wind up with 2 threads running on physial proc B. However, procB HT performance is only 120% of mean. Meaning the scheduler, ideally, should move ONE of the threads from proc B and put it back on proc A so that procA is running at 100% and proc b is running at 100% instead of only proc B running at 120%. In this scenario, your overall thruput is lower because the scheduler isn't HT aware. W2K's scheduler is not HT aware.

That, if you can follow it, is why logical core detection is critical for supporting HT and why MS (even in the docs YOU POSTED) says that W2K does not support HT.

 

[Smilin]

Originally posted by: bsobel

Originally posted by: Nothinman

Read sections 3.1 and 4.1, and pay attention to the diagrams, specifically figure 4.

I think it's you who should read them again. The very second sentence of section 4.1 says "However, neither Windows 2000 nor any of its service packs support the identification of HT processors." and the first sentence in the second paragraph says "As a result, Windows 2000 treats each logical processor as if it were an individual physical processor." which means that while it will use all of the logical processors it isn't smart enough to schedule them intelligently because it thinks that they're all separate physical processors. Why is that so difficult to understand?

Larry, maybe an example will help. Lets take a dual proc HT system. In this system we have 2 physical procs each with 2 logical ones. W2K sees four cores. You launch 4 threads, the system will ideally schedule one thread per virtual core (e.g. each seen proc will now have 1 thread running on it). If you now stop 2 of those threads and both of those threads where running on physical proc A you wind up with 2 threads running on physial proc B. However, procB HT performance is only 120% of mean. Meaning the scheduler, ideally, should move ONE of the threads from proc B and put it back on proc A so that procA is running at 100% and proc b is running at 100% instead of only proc B running at 120%. In this scenario, your overall thruput is lower because the scheduler isn't HT aware. W2K's scheduler is not HT aware.

That, if you can follow it, is why logical core detection is critical for supporting HT and why MS (even in the docs YOU POSTED) says that W2K does not support HT.

You confuse desire for troll as desire for explanation grasshoppa. If you end the conversation with logic then purpose is not served.

 

[VirtualLarry]

Originally posted by: bsobel

Originally posted by: Nothinman

Read sections 3.1 and 4.1, and pay attention to the diagrams, specifically figure 4.

I think it's you who should read them again. The very second sentence of section 4.1 says "However, neither Windows 2000 nor any of its service packs support the identification of HT processors." and the first sentence in the second paragraph says "As a result, Windows 2000 treats each logical processor as if it were an individual physical processor." which means that while it will use all of the logical processors it isn't smart enough to schedule them intelligently because it thinks that they're all separate physical processors. Why is that so difficult to understand?

Larry, maybe an example will help. Lets take a dual proc HT system. In this system we have 2 physical procs each with 2 logical ones. W2K sees four cores. You launch 4 threads, the system will ideally schedule one thread per virtual core (e.g. each seen proc will now have 1 thread running on it). If you now stop 2 of those threads and both of those threads where running on physical proc A you wind up with 2 threads running on physial proc B. However, procB HT performance is only 120% of mean. Meaning the scheduler, ideally, should move ONE of the threads from proc B and put it back on proc A so that procA is running at 100% and proc b is running at 100% instead of only proc B running at 120%. In this scenario, your overall thruput is lower because the scheduler isn't HT aware. W2K's scheduler is not HT aware.

I understood your argument perfectly already, no need to re-iterate. The diagrams in section 4.1, and the emphasis placed on the BIOS MADT tables, seem to indicate that the scenario you describe cannot happen, that if you have two threads in the runqueue, and 4 logical processors (two physical followed by two logical), that the two threads will get scheduled on the first two (physical) processors. That was the whole point of Intel's design, SMT was supposed to be a drop-in replacement for SMP-designed OSes, as long as the other programming guidelines (using HLT and YIELD appropriately) were followed. There doesn't need to be any special "intellegence" in the scheduler, to detect and support HT - all that has to happen is that the OS schedules threads in order of the BIOS MADT CPU tables. That way the physical processors get utilized before the logical ones. It just works.

Originally posted by: bsobel
That, if you can follow it, is why logical core detection is critical for supporting HT and why MS (even in the docs YOU POSTED) says that W2K does not support HT.

If you make that claim, then you have a clear reading-comprehension problem. MS clearly shows that HT IS supported on W2K. As I quoted from that doc.

 

[Smilin]

Easy there with the reading comprehension accusations there kettle.

He didn't say 2 threads started. (should work fine on 2physical, 2logical cores)

He said 4 threads started then two stopped. (may have hyperthreading problems on 2physical, 2logical cores))



Windows 2000 doesn't treat physical and logical processors differently. Win2k is compatible with hyper threading but it was not designed to take advantage of it. Period.

If you want proof of this fire up a quad core box with hyperthreading (8 logical cores) on a Windows 2000 Server box with the 4CPU limitation.