Of course this is happening. That is the whole point of 'embrace-and-extend'. Microsoft isn't stupid. This was carefully calculated and is obviously working.
Actually, when I said "segmentation is gone", I over simplified. Segments for cs/ds/es/ss are essentially hardwired to start at zero, with a 64bit "limit". fs/gs however are still alive and simply have a floating base and limit count. ie: you can still use them for thread-local-storage. All the protection mechanisms are gone though.
Seperation and protection of code and data etc is done at the page level.
Regarding 'long' and 'legacy' modes. You either have a 64 bit OS (long mode), or you have a legacy OS (looks just like x86).
long mode has a 64 bit OS and supervisor model. However, long mode allows *applications* to run in either flat 64 bit mode, or an emulated 32/16 bit protected mode. It isn't true traditional protected mode, but it is enough for applications. In this application mode, you still do have segments, protection is enforced etc, but you are really running on 64 bit page tables etc where you simply cannot generate 64 bit memory references and cannot use any of the 64 bit instructions or registers. If your application traps or makes a syscall, the OS handles it in 64 bit mode. Since the supervisor part of this model is gone, things like vm86 and switching to real mode are not possible.
ia64 does something very similar for x86 emulation, except that the simulated internal segmentation protection mechanisms are even weaker. For example, on ia64, you can edit your GDT and change your %cs etc as you please. It just simply doesn't do anything interesting because you are mapped onto a 64 bit address space. There are no "priviliges" granted by the segmentation system in this mode.
Hammer's 'OS legacy mode' makes it look and feel just like an x86.
In theory your could switch between 'OS legacy mode' and '64 bit OS mode' but you really wouldn't want to. It is expensive, and the supervisor interface is radically different. It would be tremendously expensive to do so regularly. It just isn't worth it. To hell with vm86 and real mode code!
x86-64 isn't a pure extension to x86. AMD chopped out a *lot* of stuff. In 64 bit mode, segmentation is completely gone, for example. When the OS is in 'long mode' (ie: the OS is 64 bit) then vm86 is gone. real mode is gone. etc. All that is left when running under a 64 bit OS is 64 bit protected mode and 32 bit protected mode. While the 32 bit apps see what looks like "segments", the supervisor side of it is mostly gone.
From reading the AMD manuals, it looks like somebody wrote up a list of what sucks about x86 from an OS perspective and the design engineers did a damn good job at getting rid of just about everything on the list. There is still some nastiness, but it is a damn sight better than plain x86.
The x86-64 application view is dramatically cleaned up too.
One thing I can comfortably say after spending quite some time porting OS code to IA64 is "everything you know is wrong". Much of our accumulated knowledge about OShardware interaction has gone out the window with this beastie. The same for compilers. RISC made a mess of our accumulated compiler knowledge, and IA64 (VLIW^H^H^H^HEPIC) takes us back to square one again too.
Itanium is going to take years to reach critical mass. x86-64 is going to be eating its lunch for quite a good while. Especially if Intel dont hurry up and make a version suitable for desktop/workstation use.
One thing that they seem to have lost track of reality on, is that nothing *guarantees* them the *right* to keep on making money the way they always used to.
They (the networks) choose to make a gamble in paying content providers (or paying to produce it themselves) and that they can recover their costs and make a profit in the process. You do not get the payoff without taking the risk. They have no more "right" to expect the models to work forever than I have the "right" to expect a guaranteed job forever from my employer.
If times change and they can no longer do this, then they had better find a another way to make money.. Here's one.. Find out what the consumers *actually want* and be the best to serve their needs rather than choosing something cheap and nasty and attempting to ram it down their throats and force them to like it.
Viewers are not the property of the networks. If times change and the old media models no longer work, then they had better start thinking of new ones. Actually listening to people instead of trying to "capture" them would be a good start.
One possible outcome of this is a fork in the wireless data protocols if the "real" protocols are too expensive (patents etc) or too difficult to implement. I do not find it hard to imagine a scenario where somebody says "screw it" and writes a lightweight packet radio implementation using just enough of the hardware to get by and inventing a protocol with real security (none of this WEP or 802.11x crap). Add an instant D.I.Y. gateway (mini PC with OS of your choice) and voila.
Of course, that assumes that getting enough info to talk to the DSP etc is possible. I guess the far more likely outcome would just be more pain and hurt for non-M$ folks (but that's what M$'s objective is anyway!). Sigh.
Windows XP already downloads new runtime firmware to my wavelan card... I discovered this because it broke my old base station that didn't support link layer fragmentation with WEP enabled. I had to update the firmware on the base station to get it to work again after installing XP.
They already mostly have this capability. Tivo periodically record half-hour bundles of special material from early-morning slots on the discovery channel and break it up into seperate chunks attached to the showcases etc area.
They experimented with this recently for BMW, NFL/DirecTV etc, Lexus (I think), and so on.
The next logical step is to be able to collect ads and do ad scheduling based on search/viewing profiles etc. ("show me some washing machine ads" as a previous poster put it). Also, ads-on-pause (annoying etc) is possible with this, but this might be usable to subsidize the cost of operating the tivo-like services etc.
But how to pay for the content? I would happily pay for what I watched if it meant the death of inline commercials. A PVR is a perfect vehicle for doing this if you can figure out a secure delivery mechanism (not hard).
Just think: digital delivery to PVR's of content and ad material, pay per show you watch (few cents, so that it works out at something like 30 to 50 cents a day for an average person, that's about $10-$15 per site per month). And, have optional targeted ads that offset your account so that actually watching ads subsidises your TV.
The catch would be that you would need a PVR-like decoder box just to watch TV and have content broadcast as data rather than raw unprotected video.
The double catch is.. can you imagine the TV industry agreeing on a stable universal standard for doing this? HAH!
"It will never happen".
Skipping commercials is not what it is about. The point of a PVR is *always* having something interesting available to watch. No more channel surfing at 2:15am for the 45 minutes waiting for something interesting to start.
I will *never* be able to go back to "normal" TV again, Tivo has ruined me for life.
And yes, I do go back and watch interesting or relevant commercials too.
It is the same on the internet. People pushing popup ads etc do not seem to realize that applying classic "in your face" TV models simply are no longer as effective when people have some choice or control.
If you appeal to people's interest, they will look if it is relevant. If you *annoy* them, then they will actively avoid you, regardless of how relevant or interesting your product is.
This is a common misconception. IA-64 does support out-of-order execution. Although you have to mark inter-dependent instructions with stop bits, that is a help mechanism for the cpu speculative execution system. The P3 and P4 etc have to figure this out at runtime with no clues from the compiler.
The real reason why the cpu is relatively slow is because the current silicon is basically a cleaned up version of the development / proof-of-concept early stuff. I have a system that has been upgraded all the way from the original A-step cpu / motherboard. Current production is at C0 or C1 stepping last I checked. I have two B3 cpus in my system right now.
The other reason behind the observed performance is that the compiler tech isn't really up to scratch yet. Many of the compilers (gcc in particular, for example) do not yet support feedback profiling (where you run the program, collect the profile data and recompile so that the compiler can use that information to do better code layout to minimize pipeline stalls, mispredicted branches etc).
Intel have been focusing their efforts on the McKinley release early next year. *That* will be the one to watch and will be a much fairer indication of whether IA64 will sink or swim.
AT&T Broadband is a much more than attbi.com. Comcast's bid is for the entire cable TV, digitial phone, *and* attbi networks, including the actual cable on the poles and in the ground. That is a much much larger deal. Cable TV is far more profitable than a group of cable modem users anyway. That's why it is worth that much money as a whole. I dont know if AT&T Worldnet is part of AT&T Broadband or not, or where the MediaOne group fits into this.
This is consistent with what we see at work. 95% of the problems happen on the inner cylinders. This also would explain why windows users dont see it so much, since they would have to fill the disk 95% full before they went near the troublesome area. I would expect that windows users would tend to suffer from the reported mechanical failures more than the data corruption problems. On unix systems, the data corruption is an absolute curse.
At work, this is with a sample size of several thousand disks, The DTLA's are a nightmare - the entire DTLA product range has inner-cylinder corruption problems. Scrubbing would "fix" them (for a while). We didn't see much of "disk died" type failures on the DTLA 30G drives, but saw many more "dead drive" failures with the larger 75G drives in addition to the corruption problems.
Also, in one test, adding some electrical noise to the mains power (plug an electric drill into the power strip, it made a mess of it) caused the power supply rail voltages to drop a small amount and caused instant errors. The DTLA was the only drive in the machine that this problem. The older DPTA and other brand drives that were also under test didn't care at all.
We have been considering changing our disk partioning layout to trim a few GB from the end of the disk and never use it. We expect that will "avoid" the corruption problems.
I've used perforce for years now, as far back as when it was called 'p3'. I find it absolutely invaluable and could not live without it for doing my FreeBSD development work on. Right at this instant, my development p4 repository has about 40 active branches on it. One has been alive for 2 years now and part of it has just recently been committed to the main FreeBSD tree. I must have done at least 80 to 100 merges to pull in the freebsd base changes into my branch. I am constantly suprised at how easy/painless this is compared to CVS. Yes, you can do it in cvs as well, but you have to mess around with tags etc. With perforce it is a no-brainer. In other cases I have a branch of a branch of a branch. Perforce was designed for this so that branching is so cheap and easy that it is quite practical to do *every* non-trivial feature development in a seperate branch.
The only weaknesses that I regularly complain about with perforce is the relatively weak command line interface (compared to cvs, for example) and the lack of detached operation capabilities. For a corporate development environment the latter is generally harmless, but when you take a laptop on a plane or to a conference it can be a pain.
p4 does require that you think a bit differently compared to traditional SCM's but the payoff once you've learned it is fantastic. But people who are doing the occasional patch here or there are not going to see these benefits. For them they may as well keep on using cvs.
> While this is obviously bad news, I'm not worried.
Actually, depending on how you look at it, it could almost be considered good news.
I'm one of the people who semi-regularly works on it and I can pretty comfortably say that the November 2001 target was unrealistic for a polished system. We were planning on having something that we wouldn't be embarressed about in about another 4 to 6 months.
Do not be suprised if 5.0 happens about then, and not in November 2002. If so, it will be something we will be pleased to have released rather than something that we spend the next few months fighting fires over.
As long as the non-SMPng / non-KSE stuff keeps going into the 4.x branch, we should be in good shape. That will make the 5.0 release basically like "4.x plus SMPng + KSE (threads done right)"
Slashdot Mirror
Of course this is happening. That is the whole point of 'embrace-and-extend'. Microsoft isn't stupid. This was carefully calculated and is obviously working.
Actually, when I said "segmentation is gone", I over simplified. Segments for cs/ds/es/ss are essentially hardwired to start at zero, with a 64bit "limit". fs/gs however are still alive and simply have a floating base and limit count. ie: you can still use them for thread-local-storage. All the protection mechanisms are gone though.
Seperation and protection of code and data etc is done at the page level.
Regarding 'long' and 'legacy' modes. You either have a 64 bit OS (long mode), or you have a legacy OS (looks just like x86).
long mode has a 64 bit OS and supervisor model. However, long mode allows *applications* to run in either flat 64 bit mode, or an emulated 32/16 bit protected mode. It isn't true traditional protected mode, but it is enough for applications. In this application mode, you still do have segments, protection is enforced etc, but you are really running on 64 bit page tables etc where you simply cannot generate 64 bit memory references and cannot use any of the 64 bit instructions or registers. If your application traps or makes a syscall, the OS handles it in 64 bit mode. Since the supervisor part of this model is gone, things like vm86 and switching to real mode are not possible.
ia64 does something very similar for x86 emulation, except that the simulated internal segmentation protection mechanisms are even weaker. For example, on ia64, you can edit your GDT and change your %cs etc as you please. It just simply doesn't do anything interesting because you are mapped onto a 64 bit address space. There are no "priviliges" granted by the segmentation system in this mode.
Hammer's 'OS legacy mode' makes it look and feel just like an x86.
In theory your could switch between 'OS legacy mode' and '64 bit OS mode' but you really wouldn't want to. It is expensive, and the supervisor interface is radically different. It would be tremendously expensive to do so regularly. It just isn't worth it. To hell with vm86 and real mode code!
x86-64 isn't a pure extension to x86. AMD chopped out a *lot* of stuff. In 64 bit mode, segmentation is completely gone, for example. When the OS is in 'long mode' (ie: the OS is 64 bit) then vm86 is gone. real mode is gone. etc. All that is left when running under a 64 bit OS is 64 bit protected mode and 32 bit protected mode. While the 32 bit apps see what looks like "segments", the supervisor side of it is mostly gone.
From reading the AMD manuals, it looks like somebody wrote up a list of what sucks about x86 from an OS perspective and the design engineers did a damn good job at getting rid of just about everything on the list. There is still some nastiness, but it is a damn sight better than plain x86.
The x86-64 application view is dramatically cleaned up too.
And about damn time!
One thing I can comfortably say after spending quite some time porting OS code to IA64 is "everything you know is wrong". Much of our accumulated knowledge about OShardware interaction has gone out the window with this beastie. The same for compilers. RISC made a mess of our accumulated compiler knowledge, and IA64 (VLIW^H^H^H^HEPIC) takes us back to square one again too.
Itanium is going to take years to reach critical mass. x86-64 is going to be eating its lunch for quite a good while. Especially if Intel dont hurry up and make a version suitable for desktop/workstation use.
One thing that they seem to have lost track of reality on, is that nothing *guarantees* them the *right* to keep on making money the way they always used to.
They (the networks) choose to make a gamble in paying content providers (or paying to produce it themselves) and that they can recover their costs and make a profit in the process. You do not get the payoff without taking the risk. They have no more "right" to expect the models to work forever than I have the "right" to expect a guaranteed job forever from my employer.
If times change and they can no longer do this, then they had better find a another way to make money.. Here's one.. Find out what the consumers *actually want* and be the best to serve their needs rather than choosing something cheap and nasty and attempting to ram it down their throats and force them to like it.
Viewers are not the property of the networks. If times change and the old media models no longer work, then they had better start thinking of new ones. Actually listening to people instead of trying to "capture" them would be a good start.
One possible outcome of this is a fork in the wireless data protocols if the "real" protocols are too expensive (patents etc) or too difficult to implement. I do not find it hard to imagine a scenario where somebody says "screw it" and writes a lightweight packet radio implementation using just enough of the hardware to get by and inventing a protocol with real security (none of this WEP or 802.11x crap). Add an instant D.I.Y. gateway (mini PC with OS of your choice) and voila.
Of course, that assumes that getting enough info to talk to the DSP etc is possible. I guess the far more likely outcome would just be more pain and hurt for non-M$ folks (but that's what M$'s objective is anyway!). Sigh.
Windows XP already downloads new runtime firmware to my wavelan card... I discovered this because it broke my old base station that didn't support link layer fragmentation with WEP enabled. I had to update the firmware on the base station to get it to work again after installing XP.
They already mostly have this capability. Tivo periodically record half-hour bundles of special material from early-morning slots on the discovery channel and break it up into seperate chunks attached to the showcases etc area.
They experimented with this recently for BMW, NFL/DirecTV etc, Lexus (I think), and so on.
The next logical step is to be able to collect ads and do ad scheduling based on search/viewing profiles etc. ("show me some washing machine ads" as a previous poster put it). Also, ads-on-pause (annoying etc) is possible with this, but this might be usable to subsidize the cost of operating the tivo-like services etc.
But how to pay for the content? I would happily pay for what I watched if it meant the death of inline commercials. A PVR is a perfect vehicle for doing this if you can figure out a secure delivery mechanism (not hard).
Just think: digital delivery to PVR's of content and ad material, pay per show you watch (few cents, so that it works out at something like 30 to 50 cents a day for an average person, that's about $10-$15 per site per month). And, have optional targeted ads that offset your account so that actually watching ads subsidises your TV.
The catch would be that you would need a PVR-like decoder box just to watch TV and have content broadcast as data rather than raw unprotected video.
The double catch is.. can you imagine the TV industry agreeing on a stable universal standard for doing this? HAH!
"It will never happen".
Amen to that!
Skipping commercials is not what it is about. The point of a PVR is *always* having something interesting available to watch. No more channel surfing at 2:15am for the 45 minutes waiting for something interesting to start.
I will *never* be able to go back to "normal" TV again, Tivo has ruined me for life.
And yes, I do go back and watch interesting or relevant commercials too.
It is the same on the internet. People pushing popup ads etc do not seem to realize that applying classic "in your face" TV models simply are no longer as effective when people have some choice or control.
If you appeal to people's interest, they will look if it is relevant. If you *annoy* them, then they will actively avoid you, regardless of how relevant or interesting your product is.
I will *never* buy an X10 device!
This is a common misconception. IA-64 does support out-of-order execution. Although you have to mark inter-dependent instructions with stop bits, that is a help mechanism for the cpu speculative execution system. The P3 and P4 etc have to figure this out at runtime with no clues from the compiler.
The real reason why the cpu is relatively slow is because the current silicon is basically a cleaned up version of the development / proof-of-concept early stuff. I have a system that has been upgraded all the way from the original A-step cpu / motherboard. Current production is at C0 or C1 stepping last I checked. I have two B3 cpus in my system right now.
The other reason behind the observed performance is that the compiler tech isn't really up to scratch yet. Many of the compilers (gcc in particular, for example) do not yet support feedback profiling (where you run the program, collect the profile data and recompile so that the compiler can use that information to do better code layout to minimize pipeline stalls, mispredicted branches etc).
Intel have been focusing their efforts on the McKinley release early next year. *That* will be the one to watch and will be a much fairer indication of whether IA64 will sink or swim.
AT&T Broadband is a much more than attbi.com. Comcast's bid is for the entire cable TV, digitial phone, *and* attbi networks, including the actual cable on the poles and in the ground. That is a much much larger deal. Cable TV is far more profitable than a group of cable modem users anyway. That's why it is worth that much money as a whole. I dont know if AT&T Worldnet is part of AT&T Broadband or not, or where the MediaOne group fits into this.
This is consistent with what we see at work. 95% of the problems happen on the inner cylinders. This also would explain why windows users dont see it so much, since they would have to fill the disk 95% full before they went near the troublesome area. I would expect that windows users would tend to suffer from the reported mechanical failures more than the data corruption problems. On unix systems, the data corruption is an absolute curse.
At work, this is with a sample size of several thousand disks, The DTLA's are a nightmare - the entire DTLA product range has inner-cylinder corruption problems. Scrubbing would "fix" them (for a while). We didn't see much of "disk died" type failures on the DTLA 30G drives, but saw many more "dead drive" failures with the larger 75G drives in addition to the corruption problems.
Also, in one test, adding some electrical noise to the mains power (plug an electric drill into the power strip, it made a mess of it) caused the power supply rail voltages to drop a small amount and caused instant errors. The DTLA was the only drive in the machine that this problem. The older DPTA and other brand drives that were also under test didn't care at all.
We have been considering changing our disk partioning layout to trim a few GB from the end of the disk and never use it. We expect that will "avoid" the corruption problems.
I've used perforce for years now, as far back as when it was called 'p3'. I find it absolutely invaluable and could not live without it for doing my FreeBSD development work on. Right at this instant, my development p4 repository has about 40 active branches on it. One has been alive for 2 years now and part of it has just recently been committed to the main FreeBSD tree. I must have done at least 80 to 100 merges to pull in the freebsd base changes into my branch. I am constantly suprised at how easy/painless this is compared to CVS. Yes, you can do it in cvs as well, but you have to mess around with tags etc. With perforce it is a no-brainer. In other cases I have a branch of a branch of a branch. Perforce was designed for this so that branching is so cheap and easy that it is quite practical to do *every* non-trivial feature development in a seperate branch.
The only weaknesses that I regularly complain about with perforce is the relatively weak command line interface (compared to cvs, for example) and the lack of detached operation capabilities. For a corporate development environment the latter is generally harmless, but when you take a laptop on a plane or to a conference it can be a pain.
p4 does require that you think a bit differently compared to traditional SCM's but the payoff once you've learned it is fantastic. But people who are doing the occasional patch here or there are not going to see these benefits. For them they may as well keep on using cvs.
> While this is obviously bad news, I'm not worried.
Actually, depending on how you look at it, it could almost be considered good news.
I'm one of the people who semi-regularly works on it and I can pretty comfortably say that the November 2001 target was unrealistic for a polished system. We were planning on having something that we wouldn't be embarressed about in about another 4 to 6 months.
Do not be suprised if 5.0 happens about then, and not in November 2002. If so, it will be something we will be pleased to have released rather than something that we spend the next few months fighting fires over.
As long as the non-SMPng / non-KSE stuff keeps going into the 4.x branch, we should be in good shape. That will make the 5.0 release basically like "4.x plus SMPng + KSE (threads done right)"