What I was alluding to is that in the future, AMD will have to support a non-x86 platform. After all these years, the x86 platform is truly a well-documented standard. Even its undocumented features are very well-known.
However, when Intel moves to their own VLIW RISC solutions, (which they call EPIC instead) AMD will likely be forced to follow them, sooner or later. And cloning that chip (or even creating a compatible interface) should prove to be a far larger challenge than merely making yet another x86-compatible chipset.
AMD hopes to avoid all of this with Sledgehammer, and keep people on at least a quasi-x86 platform. And that might work for a couple of years. But eventually the x86 architecture will run out of steam, and when that happens, Intel will be there to take over again, for at least a few more years, until everyone else catches up again.
The Pentium IV is essentially still in development. And considering that it debuted at 1.5Ghz, I don't think this should be any surprise.
We already knew that the P4 offered less performance, clock-for-clock, than other modern chipsets, but it is nice that someone has identified why. Also, it's about time that more people realize just how important cache performance can be.
However, the real question here is, what can we do about it? I mean, switching to AMD is fine in the short term, but Intel is likely to dominate the platform war in the long-term. And the P4 will likely be the first step in migrating people to their new architectures. Unless AMD's Sledgehammer is wildly successful, they will have an enormously more complicated cloning job on their hands.
Use ttcpw; it's a Windows port of the classic ttcp network testing program, and will prove very useful in networked file transfer tests, with or without interference.
And yes, it's probably the broadband.
SMB is often faster than some distributed filesystems, but it also doesn't do as much. However, compared to a local hard drive, it's painful.
Wow, this works a lot better than 2.4.1 did; that completely hosed my system, and I had to reinstall. 2.4.2 still had some bugs. But this seems to work so far, and I'll keep testing it.
I just patched up my kernel and recompiled everything, and converted my two IDE drives to use Software RAID 5 on four partitions, and I'm using ReiserFS. Can I get my slash partition on/dev/md0? At the moment I'm using it for/usr, and I symlink/home into/usr/home.
It seems to work ok so far, but it's a bit sluggish. Do you think this is a kernel issue, and should I recompile with optimization, or try to get ATA/100 support?
Slashdot Mirror
What I was alluding to is that in the future, AMD will have to support a non-x86 platform. After all these years, the x86 platform is truly a well-documented standard. Even its undocumented features are very well-known.
However, when Intel moves to their own VLIW RISC solutions, (which they call EPIC instead) AMD will likely be forced to follow them, sooner or later. And cloning that chip (or even creating a compatible interface) should prove to be a far larger challenge than merely making yet another x86-compatible chipset.
AMD hopes to avoid all of this with Sledgehammer, and keep people on at least a quasi-x86 platform. And that might work for a couple of years. But eventually the x86 architecture will run out of steam, and when that happens, Intel will be there to take over again, for at least a few more years, until everyone else catches up again.
The Pentium IV is essentially still in development. And considering that it debuted at 1.5Ghz, I don't think this should be any surprise.
We already knew that the P4 offered less performance, clock-for-clock, than other modern chipsets, but it is nice that someone has identified why. Also, it's about time that more people realize just how important cache performance can be.
However, the real question here is, what can we do about it? I mean, switching to AMD is fine in the short term, but Intel is likely to dominate the platform war in the long-term. And the P4 will likely be the first step in migrating people to their new architectures. Unless AMD's Sledgehammer is wildly successful, they will have an enormously more complicated cloning job on their hands.
News for Nerds. Stuff that matters.
During a war, slashdot would bitch about how hard it is to get RAM through trade embargoes.
They would use cryptography, and get arrested. And their user base would bitch about it.
They'd talk about GPS, and how it's used for missle tracking.
In short, it would help the war effort exactly not one iota, and still waste the time of our geeks overseas.
But you knew that, right?
Use ttcpw; it's a Windows port of the classic ttcp network testing program, and will prove very useful in networked file transfer tests, with or without interference.
And yes, it's probably the broadband.
SMB is often faster than some distributed filesystems, but it also doesn't do as much. However, compared to a local hard drive, it's painful.
Wow, this works a lot better than 2.4.1 did; that completely hosed my system, and I had to reinstall. 2.4.2 still had some bugs. But this seems to work so far, and I'll keep testing it.
/dev/md0? At the moment I'm using it for /usr, and I symlink /home into /usr/home.
I just patched up my kernel and recompiled everything, and converted my two IDE drives to use Software RAID 5 on four partitions, and I'm using ReiserFS. Can I get my slash partition on
It seems to work ok so far, but it's a bit sluggish. Do you think this is a kernel issue, and should I recompile with optimization, or try to get ATA/100 support?