just write it to a file. No quality degradation at all.
But far too much data to cope with so you have to recompress it.
Except if you re-encoded it into something else, like MPEG
Which is lossy, and difficult to do well. So you lose some quality compared with the original disk.
then you don't encrypt it again, right?
It would be OK to insist that DVD players only play encrypted discs. You can't stop PC's playing unencrypted discs, of course, but it limits the market for the pirate disks.
You have a secret chip, only available from a few foundries, which decrypts and decompresses. The disadvantage is that you have to handle the uncompressed data stream after that, which is very wasteful. The advantage is that if someone wants to rip it off they have to rip off the decompressed version. They can't burn a new DVD with that so they have to compress first. That is difficult and lossy, and so there's a limit to how often it happens (like analogue tapes), and there is a bonus for paying for a genuine copy, you get better quality.
Of course hardware will be cracked eventually, but it's much much harder. Markus Kuhn did some fun stuff on that at Cambridge, and people working on smart cards have headaches about it. But it looks a lot more tenable than a software solution which is just going to get cracked again in no time.
Best socket those chips, since it's going to get cracked sooner or later anyway.
The FSB (Front Side Bus) is the bus the processor runs on. Since the RAM (incl. DDR-SDRAM) doesn't run on the the processor bus, it doesn't have an FSB.
DDR-SDRAM will have a 133MHz bus, at double data rate, hence 266Mhz.
RAMBUS 's capable FSB speed = 400mhz ? (there is a less powerfull version that will not allow 133mhz fsb speeds, which I don't understand)
Again, this is no FSB. Also it is a DDR interface, so it's 800MHz really. But it is only 16 bits wide. The other busses in this discussion have been 64 bits wide.
You can have multiple RAM busses making the RAM bus effectively wider. You can have only one GTL+ (P6/P-II/P-III) bus in a system whereas for EV6 (Athlon/Alpha 21264) you have one per processor. Rambus chips are at 300/600Mhz, 356/712Mhz or 400/800Mhz. Most benchmarks are for the 400/800Mhz version whereas most produced Rambus chips are for the lower speed grades. Rambus chipsets only support certain multipliers between the FSB and the Rambus bus, though I have forgotten the details.
Intel's current mobo FSB = 133mhz Yes. This is normal 133MHz (no DDR), though as far as I can see there are no SMP motherboards actually available at this speed. All the SMP motherboards actually sighted in the wild (including hardware test web sites) are 100MHz. Counterexamples welcome.
Athlon 's current FSB = 200mhz (to be raised to 266 once a chipset is created to support DDR)
Yes. This is a 100MHz or 133MHz bus, with DDR, making 200MHz or 266MHz.
If anyone can remember what the allowed relationships beween the FSB and the Rambus speed are for the i820 and i840 then I would be interested.
Basically my point is that all manufacturers announce products before they are available in stores. Everyone pointing fingers at Motorola and Intel is missing the vaporware that everyone else, including AMD, is announcing
Intel don't normally do this. They are getting desparate.
My brother has had a retail p3600b for a week now... They don't seem that hard to get ahold of to me... That's not a Coppermine, it's an oldfashioned Katmai with 133MHz bus P-III Katmai 100MHz FSB P-IIIB Katmai 133MHz FSB P-IIIE Coppermine 100MHz FSB P-IIIEB Coppermine 133MHz FSB They drop the E above 600MHz because there's no risk of confusion, since Katmai will never get up there. And they may not use the B for speeds that are obviously 133MHz FSB-based ie they end with 66, 22 or 67.
> Netscape, the company that closed the > Mosaic source code They didn't close the Mosaic source code, they started over with new source code, which they have since opened up.
The PPro was 0.35um, but the level 2 cache wasn't on-die. There were two dies in the PPro package. On the other hand the L2 was on a single die (just not the same die as the processor), so it's quite impressive. At that price they didn't have to get a very good yield.
Well, the Clapton-impression had better be up to snuff, then!
Raw devices are on their way
on
Microsoft Janus
·
· Score: 1
If you really need raw devices (someone from Oracle said in this thread that they don't) then they are on their way. Stephen Tweedie is doing them (paid by Red Hat).
Linux is not embraced by the academic community in the same way as many of the BSD-derived stacks (e.g. Solaris)
Well, not according to this article which says Solaris is a reimplementation that doesn't use BSD, just like Linux's IP stack.
It also says Solaris isn't very good at sticking to the standards, rather like Linux 1.0, but unlike Linux 2.0.30 and 2.1.34 which are pretty good (and I bet 2.2 is better).
I wonder whether Holger Kruse ever mailed any bug reports to the Linux kernel folks. I think that would be simpler than implementing workarounds in his stack.
I checked out the RFC refered to by Kruse. It refers to paper by V. Paxon that details severe problems with the Linux 1.0 TCP stack. However, on page 14 they describe the tests they made with 2.0.30 and 2.1.34, and most of the problems seem to have been fixed. They found what looks like a few minor issues that they communicated to the Linux people. They thank Eric Schenk, David S. Miller, Craig Metz and Alan Cox for their assistance in the acknowledgements section.
This article is the major reference for the RFC and is written by the same guy as the RFC. It also has a lot of tough criticism of other systems, including Solaris and several BSD-dervived stacks. Windows gets a fairly clean bill, and they are very critical of Trumpet Winsock.
I tried to check Dawson's paper, but his server seems to be down.
For the other problems in the RFC they were either clearly marked as BSD problems, or I couldn't follow up the references. (Either because there weren't any, or because they were paper and not online.) The RFC doesn't name names, so it's impossible to say which of the others Linux has been guilty of, or is guilty of.
I think Holger Kruse should tell us what his 4 workarounds are, that he has been forced to put in to work around Linux. Linux has plenty of stuff put in to work around other people's mistakes of course. I guess having to put that sort of thing in your code can make you arrogant.
If you downloaded code from SETI@Home and ran it without reading the source and compiling it yourself, then you should be worried that their security is so lax. Perhaps you really installed a trojan that is even now uploading your/etc/passwd file to a cracked ftp server somewhere. If you installed it behind a company firewall, you should be even more worried.
I know they are not hacking the OS, but if they like writing their own scripts then Linux will run those scripts and has all the nice script languages (eg perl) and other languages (C) preinstalled. Of course Linux is Unix-compatible and cheap.
That the file formats of the CAD tools are text-based and open isn't directly a Unix thing, but it is very much in the Unix spirit, and somthing that ECAD users in my experience find useful
I wonder what apps you need that Linux doesn't have? Do you write your documentation in Word?
This is the sort of market Linux should do well in
on
EDA: Unix vs. NT
·
· Score: 1
Notice that it is the electronic (not mechanical) CAD area Linux is doing best in. The users here are technically minded, they understand Unix, they are used to open file formats and being able to do their own hacks.
If we were losing this market to NT we really would have lost.
Since fp performance is important to these users I guess Linux on the AMD Athlon/K7 and the Alpha should be ideal.
Looks much better. Tests some of the things that are difficult about web serving, espeially the question of having thousands of low speed connections open at the same time. Optimising for this benchmark might even benefit real world web serving performance. Lets hope they also specify a dataset that is much larger than RAM so you can't just use a RAMDISK to get good scores. That may be a good idea if your dataset is small enough, but most web servers have much bigger data sets than RAM so it's not too realistic.
The tuning that has gone on after Mindcraft has probably benefited performance for someone, and that's great, but I doubt it has made any difference to real web servers anywhere.
You might want to ask why it doesn't. Perhaps the design isn't capable of going to high clock rates. Perhaps their process technology isn't good enough. Perhaps both.
IA64 can issue multiple bundles at once (if the stop bit isn't set)
All modern processors can issue lots of instructions at once, the only difference is that IA64 expects the compiler to do the analysis, whereas others think it is better done at run time
I was surprised to see how many similarities there were between IA64 and Tera. There are huge differences, though. IA64 has one set of registers, and I think adding 4 or 8 would be quite an overhead. I don't think making IA64 into a low-latency multithreaded architecture would be that simple, and anyway the point is moot, since AFAIK neither Intel nor HP plan to try.
If CPUs support many suspended threads, DB servers can use them for tolerating disk latency, too. Yes, it's a really long latency, but CPU-level context switching can get rid of the OS-level context switching overhead for responses.
Context switch times are measured in microseconds, while disk seek times are measured in milliseconds. There's little need to optimise the OS context switch time if you are waiting for the disk. And remember, hardware support for hundreds of Tera-style threads would cost you a lot of performance in other areas.
And DB servers already do use threads to tolerate disk latency, but that only works if you can find something else to do in the meantime, and a 10ms seek time is an age. And a user waiting for several minutes an answer that needed thousands of disk seeks to find isn't going to be comforted by knowing how many other users got their answers at the same time, especially if they are using the same disk.
There's some people complaining that they can't see the actual #'s, so here they are
Where did you get the figures
Why aren't the figures on the official SPEC site like they should be with all relevant data, like compiler version, hardware availability dates etc. etc.
Everyone else in the industry is obliged to write 'estimated' disclaimers all over unsubmitted results. Why isn't AMD? Are they afraid to admit they used the Intel compilers (what else could they have used?).
Why do you think your IDE cables can't be any longer than [insert spec number here. it's less than 1 meter]. It's because of 0.6c and the latency that follows.
Rubbish, it's because IDE isn't terminated and isn't differential, and for all I know it isn't asynchronous. You can make Ultra-2 SCSI much much longer, even extend it to a couple of miles with fibre.
I think we need CPU architecture to build upon single simple devices that communicate in a way that is not bound by the speed of light. Once the CPUs get there, the rest will follow, as is seen to fit. Read ``Communicating sequential process'' by Hoare et.al. and think about the communication happening way above c. That's sweet:)
Either you or Hoare or Einstein has misunderstood something. I can't say for sure which of you it is...
Even an optimal caching strategy would still leave a lot of idle CPU cycles while the processor is waiting for disk.
Only if the CPU has no way to tolerate the latency involved. Go read about multithreaded architectures
This is the wrong order of magnitude. At the level of waiting for the disk the OS can context switch, there's no need for hardware support. The hardware support is only needed if you want to context switch on very short waits like a L2 cache miss.
In both cases the main problem is finding some other useful work for the processor to do while it is waiting for the answer. A lot of the time, the user is waiting for one particular job to finish, it isn't easily parallelisable and what the processor does while it waits for high-latency IO isn't that relevant.
The engineering for extremely high latencies probably gets trickier, though.
On the contrary, it gets much simpler, and any decent OS will already context switch while waiting for a disk.
Expect multithreaded architectures in the higher end workstations within the next 3-4 years (at the longest).
Introducing new architectures is a difficult business. I don't expect more than two new architecture on high end workstations, they are the Transmeta processor (if that is what they are doing) and IA64.
A certain up-coming architecture has the ability to grow in this direction pretty easily
If you mean IA64 I can't see how. All those registers would make fast context switches more difficult. They have other ways of dealing with high latency memory, though.
If you mean Transmeta, then I understand why you are posting as an AC:-)
If I understand correctly, the Alpha 21464 goes a different way, and puts 4 processors with fast interconnect on one chip. Again, the trick is to make your compiler so clever that it can split the job into several parallel parts.
we can't decrease latency, using current techonology that's bound by the speed of light.
I don't think that's the limitation just yet. Light can cross 1m in 3ns, that's less than the distance from my processor to it's RAM and back, yet the RAM has a latency around 100ns. And it's less than the distance to my hard disks and back, but they have a latency over a million times more than this.
With RAM prices falling the way they do, we'll soon be able to keep the whole contents of a HDD in the main memory.
Actually, I think hard disk capacities are pulling away from memory capacities.
After all, it's almost trivial to have as much as 1GB in your home machine right now
Yes, if you buy a new PC, but then it will probably come with a 10GB hard disk.
Argument: how about power failures? Reply: can you say UPS?
Can you say "irritating patronising phrase"
If a new fast version of ext2fs came along that always did a reformat instead of a file system check would you use it? Even if you had a UPS? You'd be crazy. Linux may be stable, but we are not at the point where I would be willing to bet the entire contents of my harddisk that none of the drivers have a lock-up bug in them.
The solution probably is something that uses RAM to hide the slow disk speed, but it has to be more complex than your suggestion if it is going to work.
RAM is about $1 per megabyte And according to rumour, IBM is about to speed up the capacity race in hard disks, while memory is about to hit the quantum effects wall.
RAM isn't a real alternative to disks and if you want to use RAM to cache disks, then you need to be very careful that your access patterns are such as to let the cache have an effect.
Research should be into how we make a large amount of RAM and a humongous amount of disk space work as fast as if the disk were RAM. Perhaos ReiserFS will help Linux with this.
Incidentally, DAT tapes aren't much cheaper than hard disk space these days, though they are more portable, which is important (if you back up by copying to different disks within the same LAN then you have a problem if lightning strikes your ethernet).
Slashdot Mirror
But far too much data to cope with so you have to recompress it.
Except if you re-encoded it into something else, like MPEG
Which is lossy, and difficult to do well. So you lose some quality compared with the original disk.
then you don't encrypt it again, right?
It would be OK to insist that DVD players only play encrypted discs. You can't stop PC's playing unencrypted discs, of course, but it limits the market for the pirate disks.
Of course hardware will be cracked eventually, but it's much much harder. Markus Kuhn did some fun stuff on that at Cambridge, and people working on smart cards have headaches about it. But it looks a lot more tenable than a software solution which is just going to get cracked again in no time.
Best socket those chips, since it's going to get cracked sooner or later anyway.
The FSB (Front Side Bus) is the bus the processor runs on. Since the RAM (incl. DDR-SDRAM) doesn't run on the the processor bus, it doesn't have an FSB.
DDR-SDRAM will have a 133MHz bus, at double data rate, hence 266Mhz.
RAMBUS 's capable FSB speed = 400mhz ? (there is a less powerfull version that will not allow 133mhz fsb speeds, which I don't understand)
Again, this is no FSB. Also it is a DDR interface, so it's 800MHz really. But it is only 16 bits wide. The other busses in this discussion have been 64 bits wide.
You can have multiple RAM busses making the RAM bus effectively wider. You can have only one GTL+ (P6/P-II/P-III) bus in a system whereas for EV6 (Athlon/Alpha 21264) you have one per processor. Rambus chips are at 300/600Mhz, 356/712Mhz or 400/800Mhz. Most benchmarks are for the 400/800Mhz version whereas most produced Rambus chips are for the lower speed grades. Rambus chipsets only support certain multipliers between the FSB and the Rambus bus, though I have forgotten the details.
Intel's current mobo FSB = 133mhz Yes. This is normal 133MHz (no DDR), though as far as I can see there are no SMP motherboards actually available at this speed. All the SMP motherboards actually sighted in the wild (including hardware test web sites) are 100MHz. Counterexamples welcome.
Athlon 's current FSB = 200mhz (to be raised to 266 once a chipset is created to support DDR)
Yes. This is a 100MHz or 133MHz bus, with DDR, making 200MHz or 266MHz.
If anyone can remember what the allowed relationships beween the FSB and the Rambus speed are for the i820 and i840 then I would be interested.
Intel don't normally do this. They are getting desparate.
> Netscape, the company that closed the > Mosaic source code They didn't close the Mosaic source code, they started over with new source code, which they have since opened up.
The PPro was 0.35um, but the level 2 cache wasn't on-die. There were two dies in the PPro package. On the other hand the L2 was on a single die (just not the same die as the processor), so it's quite impressive. At that price they didn't have to get a very good yield.
Well, the Clapton-impression had better be up to snuff, then!
If you really need raw devices (someone from Oracle said in this thread that they don't) then they are on their way. Stephen Tweedie is doing them (paid by Red Hat).
Well, not according to this article which says Solaris is a reimplementation that doesn't use BSD, just like Linux's IP stack.
It also says Solaris isn't very good at sticking to the standards, rather like Linux 1.0, but unlike Linux 2.0.30 and 2.1.34 which are pretty good (and I bet 2.2 is better).
I wonder whether Holger Kruse ever mailed any bug reports to the Linux kernel folks. I think that would be simpler than implementing workarounds in his stack.
This article is the major reference for the RFC and is written by the same guy as the RFC. It also has a lot of tough criticism of other systems, including Solaris and several BSD-dervived stacks. Windows gets a fairly clean bill, and they are very critical of Trumpet Winsock.
I tried to check Dawson's paper, but his server seems to be down.
For the other problems in the RFC they were either clearly marked as BSD problems, or I couldn't follow up the references. (Either because there weren't any, or because they were paper and not online.) The RFC doesn't name names, so it's impossible to say which of the others Linux has been guilty of, or is guilty of.
I think Holger Kruse should tell us what his 4 workarounds are, that he has been forced to put in to work around Linux. Linux has plenty of stuff put in to work around other people's mistakes of course. I guess having to put that sort of thing in your code can make you arrogant.
Simply create a 'seti' user and run the program under that id.
Even as a 'seti' user they can:
I can't imagine why you find the lack of source code reassuring.
If you downloaded code from SETI@Home and ran it without reading the source and compiling it yourself, then you should be worried that their security is so lax. Perhaps you really installed a trojan that is even now uploading your /etc/passwd file to a cracked ftp server somewhere. If you installed it behind a company firewall, you should be even more worried.
That the file formats of the CAD tools are text-based and open isn't directly a Unix thing, but it is very much in the Unix spirit, and somthing that ECAD users in my experience find useful
I wonder what apps you need that Linux doesn't have? Do you write your documentation in Word?
If we were losing this market to NT we really would have lost.
Since fp performance is important to these users I guess Linux on the AMD Athlon/K7 and the Alpha should be ideal.
The tuning that has gone on after Mindcraft has probably benefited performance for someone, and that's great, but I doubt it has made any difference to real web servers anywhere.
I'll bet it doesn't for SPEC. Take a look at the real reported SPEC data on www.spec.org. Everyone uses the Intel compiler.
What does the MS compiler beat the Intel compiler on? Is there even an Intel Fortran compiler?
But it doesn't, so it isn't.
You might want to ask why it doesn't. Perhaps the design isn't capable of going to high clock rates. Perhaps their process technology isn't good enough. Perhaps both.
IA64 can issue multiple bundles at once (if the stop bit isn't set)
All modern processors can issue lots of instructions at once, the only difference is that IA64 expects the compiler to do the analysis, whereas others think it is better done at run time
I was surprised to see how many similarities there were between IA64 and Tera. There are huge differences, though. IA64 has one set of registers, and I think adding 4 or 8 would be quite an overhead. I don't think making IA64 into a low-latency multithreaded architecture would be that simple, and anyway the point is moot, since AFAIK neither Intel nor HP plan to try.
If CPUs support many suspended threads, DB servers can use them for tolerating disk latency, too. Yes, it's a really long latency, but CPU-level context switching can get rid of the OS-level context switching overhead for responses.
Context switch times are measured in microseconds, while disk seek times are measured in milliseconds. There's little need to optimise the OS context switch time if you are waiting for the disk. And remember, hardware support for hundreds of Tera-style threads would cost you a lot of performance in other areas.
And DB servers already do use threads to tolerate disk latency, but that only works if you can find something else to do in the meantime, and a 10ms seek time is an age. And a user waiting for several minutes an answer that needed thousands of disk seeks to find isn't going to be comforted by knowing how many other users got their answers at the same time, especially if they are using the same disk.
There's some people complaining that they can't see the actual #'s, so here they are
Rubbish, it's because IDE isn't terminated and isn't differential, and for all I know it isn't asynchronous. You can make Ultra-2 SCSI much much longer, even extend it to a couple of miles with fibre.
I think we need CPU architecture to build upon single simple devices that communicate in a way that is not bound by the speed of light. Once the CPUs get there, the rest will follow, as is seen to fit. Read ``Communicating sequential process'' by Hoare et.al. and think about the communication happening way above c. That's sweet :)
Either you or Hoare or Einstein has misunderstood something. I can't say for sure which of you it is...
In both cases the main problem is finding some other useful work for the processor to do while it is waiting for the answer. A lot of the time, the user is waiting for one particular job to finish, it isn't easily parallelisable and what the processor does while it waits for high-latency IO isn't that relevant.
On the contrary, it gets much simpler, and any decent OS will already context switch while waiting for a disk. Introducing new architectures is a difficult business. I don't expect more than two new architecture on high end workstations, they are the Transmeta processor (if that is what they are doing) and IA64. If you mean IA64 I can't see how. All those registers would make fast context switches more difficult. They have other ways of dealing with high latency memory, though.If you mean Transmeta, then I understand why you are posting as an AC :-)
If I understand correctly, the Alpha 21464 goes a different way, and puts 4 processors with fast interconnect on one chip. Again, the trick is to make your compiler so clever that it can split the job into several parallel parts.
I don't think that's the limitation just yet. Light can cross 1m in 3ns, that's less than the distance from my processor to it's RAM and back, yet the RAM has a latency around 100ns. And it's less than the distance to my hard disks and back, but they have a latency over a million times more than this.
Actually, I think hard disk capacities are pulling away from memory capacities.
After all, it's almost trivial to have as much as 1GB in your home machine right now
Yes, if you buy a new PC, but then it will probably come with a 10GB hard disk.
Argument: how about power failures?
Reply: can you say UPS?
Can you say "irritating patronising phrase"
If a new fast version of ext2fs came along that always did a reformat instead of a file system check would you use it? Even if you had a UPS? You'd be crazy. Linux may be stable, but we are not at the point where I would be willing to bet the entire contents of my harddisk that none of the drivers have a lock-up bug in them.
The solution probably is something that uses RAM to hide the slow disk speed, but it has to be more complex than your suggestion if it is going to work.
Hard disks are about 3 cents per megabyte.
RAM is about $1 per megabyte And according to rumour, IBM is about to speed up the capacity race in hard disks, while memory is about to hit the quantum effects wall.
RAM isn't a real alternative to disks and if you want to use RAM to cache disks, then you need to be very careful that your access patterns are such as to let the cache have an effect.
Research should be into how we make a large amount of RAM and a humongous amount of disk space work as fast as if the disk were RAM. Perhaos ReiserFS will help Linux with this.
Incidentally, DAT tapes aren't much cheaper than hard disk space these days, though they are more portable, which is important (if you back up by copying to different disks within the same LAN then you have a problem if lightning strikes your ethernet).