CPU R&D is *really* expensive. That's probably why Intel doesn't seem to do much CPU R&D and sticks mainly to manufacturing [...]
Intel spends approximately 15% of their revenue on R&D (it is not clear how much is used specifically for CPU R&D). What makes you say that "Intel doesn't seem to do much CPU R&D"? On a side note, would you count compiler research as CPU R&D?
note: Itanic arch came mainly from HP [...]
The Itanic joke is getting old, Itanium 2 is now competitive, especially in floating point applications. Do you have any evidence that HP was more involved in the design of IA-64 than Intel?
And Ogg Theora is still vaporware, with a public release not until this summer. It's based on VP3 and Vorbis, neither of which are as efficient as today's MPEG-4 [...]
What codec(s) does MPEG-4 use for audio?
[...] let alone the next generation codecs like AVC and the AAC-SBR audio codec, both of which should be in products this year.
Errr... You belittle Ogg Theora because no code is available while claiming that other codecs (which are not available yet) will be better. That seems a bit schizophrenic, wouldn't you agree?:)
All VCR's come with a record button, this doesn't even seem odd to anyone who owns one, as a matter of fact a VCR without one would be shunned from the market. Why then does it seem a DVD is so much different than a VHS?
If you buy a VHS tape, odds are good it will be protected with Macrovision, in an attempt to discourage copy. In my mind, Macrovision and CSS serve a similar purpose (like you, I don't like either).
As far as the SSID is concerned:
"Some access-point vendors, including Cisco, offer the option to disable SSID broadcasts in the beacon messages. The SSID can still be determined by sniffing the probe response frames from an access point".
For a description of a real-world attack on WEP, I would recommend "Using the Fluhrer, Mantin, and Shamir Attack to Break WEP" by Stubblefield, Ioannidis, and Rubin. They showed it was possible to recover a 104-bit key in a few hours...
It takes about 15 minutes to crack 64-bit WEP. A day to crack 128-bit WEP. I think that 256-bit WEP IIRC would in theory take about a month of non-stop monitoring.
It is somewhat misleading to call a WEP key "64-bit" or "128-bit" since it consists of a 24-bit IV prepended to a 40-bit or 104-bit secret key. The secret part is, in fact, 24 bits shorter than marketers would have us believe.
As for your figures, they are incorrect. Fluhrer, Mantin and Shamir have shown it is possible to "recover an arbitrarily long key in a negligible amount of time which grows only linearly with its size, both for 24 and 128 bit IV modifiers".
Thus, doubling the size of the key will only double the time needed to recover the secret key! Stubblefield, Ioannidis and Rubin have shown that it takes as little as 1,000,000 packets to recover a "128-bit" WEP key. That's less than a day on a lightly loaded WLAN to recover a hypothetical "256-bit" key...
If memory serves me right, latency for satellite net access is something like 100 ms per kilometer. At 13 miles (roughly 20 kilometers), you'd be looking at 2000 ms minimum just to reach the device, and at least 2000 ms from the device to the server.
For starters, the speed of light in a vacuum is approximately 299,792,458 m/s i.e. 3.3 us/km (that's microseconds per km). You're off by 4 orders of magnitude.
Next, a geostationary satellite orbits at an altitude of approximately 35,790 km. Thus, it "only" takes 240 ms for a round trip between Earth and the satellite (propagation delay).
Re:As long as it doesn't cut into my bandwidth
on
Wi-Fi From The Sky
·
· Score: 1
In that case, 4 or 5 competing Wifi-from-the-sky balloons could well make it impossible to setup a personal wireless LAN on the ground.
802.11 defines 3 non-overlapping channels in the 2.4 GHz range and 8 non-overlapping channels in the 5 GHz range to help cope with noisy neighbors. Moreover, it is likely that the balloons will be equipped with "smart" antennas. In any event, DSSS will help.
What I haven't yet seen used anywhere outside my own software and some programming languages internals (e.g. calling Perl code from C), is using data stack for temporary memory allocations. It has the most important advantage of garbage collectors: allocate memory without worrying about freeing it. It also has a few gotchas, but I'd say its advantages are well worth it.
Towards the end of the article, the author states:
[...] a number of the concepts earlier championed by Digital researchers, such as multi-threading, are embodied in the latest Pentium 4 and AMD's upcoming Opteron processor.
I have read many things about Opteron and the K8 in general. I never saw any mention of multi-threading. In fact, Fred Weber (a CTO at AMD) even said AMD would push for SMP rather than SMT.
By the way, looking at these test results, you might want to know why Intel didn't introduce this hyperthreading capability earlier. Unfortunately, there were legal reasons for the delay, where Intel was in a court battle with former workstation maker and current high-tech company Intergraph, where both companies claimed to have invented the technique. Intergraph prevailed in court, Intel settled, and now is allowed to use this innovation.
Actually, SMT Xeons have been available for a while. SMT is more useful in a server environment where throughput is more important than single-thread latency.
Intergraph and Intel are fighting over EPIC which is the foundation for IA-64 aka IPF (Itanium Processor Family).
Stop using these base ten exponents while talking about computers, you're making my brain hurt!
I am always happy to oblige.
Consider a large corporation with 2^20 devices and each device with 128 GB or 2^37 bytes available. 2^57 is close to the 64-bit limit, don't you think?:)
The "bitness" of a micro-architecture
on
AMD's 64-bit Plot
·
· Score: 2, Informative
I have to share this insightful comment I read on Usenet 3 years ago:
The "bit width" of a CPU is not strictly defined by a single architectural attribute. Several candidates for a "normative" bit width exist:
- word width of the general purpose registers
- width of internal data paths
- width of external data paths
- width of the ALU
- width of the architected address range
There are probably more...
Back in the days of the 8 bit processors, ALUs were 8 bit wide, but address range was already 16 bit.
In the age of 16 bit processors, registers and ALUs were 16 bits wide, but often there were more than 16 address bits. Segmented addressing was needed to make use of more than 64 KB for a single process.
When the first 32 bit CPUs appeared, they had 32 bit wide general purpose registers and 32 bits of architected address space. But for example the 68000 had only a 16 bit ALU and its data bus was only 16 bits wide. Of the address bits, only 24 were externally visible on pins.
Nowadays, with "64 bit CPUs" a reality for high-end computers, the address width is the important criterion. Only a true 64 bit machine can linearly address more than 4 GB for each running process. And when you handle pointer variables that are 64 bits wide, it makes a lot of sense to have 64 bit wide registers, a 64 bit ALU and 64 bit wide internal data paths. All current 64 bit CPUs that I know of meet this definition of "64 bit".
Internal bus widths tend to be wider (think of the 256 bit wide backside L2 bus of Coppermine or the G5), and registers have been wider than the "bitness" ever since FPUs have moved on-chip (you don't even need to consider AltiVec or SSE). External buses are sometimes narrower (to save some pins and a lot of bucks on packaging) and sometimes wider (to better feed the new and fast CPU cores from the same old memory chips).
So, by all intents and purposes, the x86 architecture was 16 bit until and including the 286, and is 32 bit from the 386 onwards. AMD's K8 will probably extend it to 64 bits. The P6 core is 32 bits, but it has some extensions to enable it to address 64 GB of physical RAM. But every single process can only address 4 GB directly, since pointers are still 32 bits wide. AFAIK K7 and P7 also have these extensions, but are still 32 bit cores.
BTW, the G5 is also rumored to be able to address 64 GB of physical RAM. There are four unused bits in each of the "segment registers" which could be used by the OS to select one of sixteen banks of 4 GB each. But processes would still be limited to 4 GB of directly addressable memory.
Holger Bettag
Re:Just to remind people why more bits is good..
on
AMD's 64-bit Plot
·
· Score: 1
Each program's virtual address space is still 4GB, and pointers are still a flat 32 bits. PAE simply changes the hardware page table structure so the 4GB "window" of your virtual address space can look out onto more than 4GBs of physical memory. Even though no one process can access more memory than before, you can run multiple, 4GB processes on a single machine.
As far as I understand, it is possible to run multiple 4 GB processes on a 32-bit machine with virtual memory (although swap would need to be very large). PAE would only allow one to have more than 4 GB of RAM?
Some people are claiming that 64 bits is all we will ever need. 64 bits will "only" encode approximately 2*10^19 values.
Imagine I want to give each byte of storage available in a cluster his own unique address. I could then simply write MOV RAX, [RBX] and have the OS figure out I want 8 bytes located on a completely different computer's disk or memory (Single Address Space Operating Systems explore this possibility and they actually bank on a sparse address space).
Consider a large corporation with 10^6 devices and each device with 100 GB or 10^11 bytes available. 10^17 is close to the 64-bit limit, don't you think?
Re:Just to remind people why more bits is good..
on
AMD's 64-bit Plot
·
· Score: 1
If you could turn every atom of the earth into a bit of storage, 64-bit addressing would still be enough to give every byte a unique address.
I spoke to someone at Sun about 2 years ago who said that they'd like to [open source] Solaris but some of it is still based on code that they licensed years ago from companies which are no longer around.
Do you mean these comapnies went bankrupt? When a company goes bankrupt, does the software it owns go into the public domain? What happens to the software?
Slashdot Mirror
According to Robert Foster, the Uruk-hai were bred by Sauron in Mordor, not by Saruman (as was shown in Peter Jackson's movie).
The 3.06 GHz Hyper-Threaded Pentium 4 performs even better than the Xeon I listed.
Dell Precision WorkStation 350 (Pentium 4)
3067 GHz
SPECint2000 = 1130
SPECint_base2000 = 1085
SPECfp2000 = 1103
SPECfp_base2000 = 1092
CINT2000
CFP2000
CINT2000 and CFP2000 results from the Standard Performance Evaluation Corporation website.
AlphaServer ES45
1250 MHz
SPECint2000 = 928
SPECint_base2000 = 845
SPECfp2000 = 1365
SPECfp_base2000 = 1019
CINT2000
CFP2000
HP server rx5670 (Itanium 2)
1000 MHz
SPECint2000 = N/A
SPECint_base2000 = 807
SPECfp2000 = 1431
SPECfp_base2000 = 1431
CINT2000
CFP2000
Dell Precision WorkStation 530 (Xeon)
2800 MHz
SPECint2000 = 957
SPECint_base2000 = 921
SPECfp2000 = 887
SPECfp_base2000 = 878
CINT2000
CFP2000
This is the proposed schedule:
As far as the SSID is concerned: "Some access-point vendors, including Cisco, offer the option to disable SSID broadcasts in the beacon messages. The SSID can still be determined by sniffing the probe response frames from an access point".
For a description of a real-world attack on WEP, I would recommend "Using the Fluhrer, Mantin, and Shamir Attack to Break WEP" by Stubblefield, Ioannidis, and Rubin. They showed it was possible to recover a 104-bit key in a few hours...
As for your figures, they are incorrect. Fluhrer, Mantin and Shamir have shown it is possible to "recover an arbitrarily long key in a negligible amount of time which grows only linearly with its size, both for 24 and 128 bit IV modifiers".
Thus, doubling the size of the key will only double the time needed to recover the secret key! Stubblefield, Ioannidis and Rubin have shown that it takes as little as 1,000,000 packets to recover a "128-bit" WEP key. That's less than a day on a lightly loaded WLAN to recover a hypothetical "256-bit" key...
Next, a geostationary satellite orbits at an altitude of approximately 35,790 km. Thus, it "only" takes 240 ms for a round trip between Earth and the satellite (propagation delay).
Intergraph and Intel are fighting over EPIC which is the foundation for IA-64 aka IPF (Itanium Processor Family).
You could start here or here.
Consider a large corporation with 2^20 devices and each device with 128 GB or 2^37 bytes available. 2^57 is close to the 64-bit limit, don't you think? :)
I have to share this insightful comment I read on Usenet 3 years ago:
The "bit width" of a CPU is not strictly defined by a single architectural
attribute. Several candidates for a "normative" bit width exist:
- word width of the general purpose registers
- width of internal data paths
- width of external data paths
- width of the ALU
- width of the architected address range
There are probably more...
Back in the days of the 8 bit processors, ALUs were 8 bit wide, but address
range was already 16 bit.
In the age of 16 bit processors, registers and ALUs were 16 bits wide, but
often there were more than 16 address bits. Segmented addressing was needed
to make use of more than 64 KB for a single process.
When the first 32 bit CPUs appeared, they had 32 bit wide general purpose
registers and 32 bits of architected address space. But for example the 68000
had only a 16 bit ALU and its data bus was only 16 bits wide. Of the address
bits, only 24 were externally visible on pins.
Nowadays, with "64 bit CPUs" a reality for high-end computers, the address
width is the important criterion. Only a true 64 bit machine can linearly
address more than 4 GB for each running process. And when you handle pointer
variables that are 64 bits wide, it makes a lot of sense to have 64 bit wide
registers, a 64 bit ALU and 64 bit wide internal data paths. All current
64 bit CPUs that I know of meet this definition of "64 bit".
Internal bus widths tend to be wider (think of the 256 bit wide backside L2
bus of Coppermine or the G5), and registers have been wider than the "bitness"
ever since FPUs have moved on-chip (you don't even need to consider AltiVec or
SSE). External buses are sometimes narrower (to save some pins and a lot of
bucks on packaging) and sometimes wider (to better feed the new and fast CPU
cores from the same old memory chips).
So, by all intents and purposes, the x86 architecture was 16 bit until and
including the 286, and is 32 bit from the 386 onwards. AMD's K8 will probably
extend it to 64 bits. The P6 core is 32 bits, but it has some extensions to
enable it to address 64 GB of physical RAM. But every single process can only
address 4 GB directly, since pointers are still 32 bits wide. AFAIK K7 and P7
also have these extensions, but are still 32 bit cores.
BTW, the G5 is also rumored to be able to address 64 GB of physical RAM.
There are four unused bits in each of the "segment registers" which could be
used by the OS to select one of sixteen banks of 4 GB each. But processes
would still be limited to 4 GB of directly addressable memory.
Holger Bettag
Imagine I want to give each byte of storage available in a cluster his own unique address. I could then simply write MOV RAX, [RBX] and have the OS figure out I want 8 bytes located on a completely different computer's disk or memory (Single Address Space Operating Systems explore this possibility and they actually bank on a sparse address space).
Consider a large corporation with 10^6 devices and each device with 100 GB or 10^11 bytes available. 10^17 is close to the 64-bit limit, don't you think?
64 bits encode approximately 2*10^19 values.
On the other hand, there are between 10^48 and 10^51 atoms in the earth.
You, my friend, are off by a few orders of magnitude.