Here are the original posts made on SOMETHING AWFUL DOT COM.
--------------------------------
They're already there.
Because nForce4 is buggy as **** and their HyperTransport implementation ****ing bites? Because their SATA doesn't work? Because they see competition and seek to crush it?
PRACE BETS NOW!
--------------------------------
They don't have any good, successful southbridges. Video cards are the only thing they do well.
-
Millions of people don't have to work around the ****ing thing's bugs. And, yeah, in terms of units shipped they're pretty successful; however, I suspect they're looking for a new HyperTransport implementation. Don't ask me how I know, I just do, OK?
-
And the reason for that is that someone like me has spent a year ****ing around with an Arium and an Ugly Yellow Book That Won't Fit On The Shelf in order to patch the hideous bugs in the chipset.
All chipsets have bugs- they have a hundred million ****ing transistors in them, you have to expect that. The problem is that nVidia are intransigent. They don't care that there are margining problems. They don't care that there are bugs that need patching- they supply a vendor BIOS and if you don't like that BIOS, or it doesn't work properly, well then you can buy your chipsets elsewhere.
Except, of course, you can't, because they've either pushed them out of business or bought them.
That's what they did with video cards, and it's what they're doing with chipsets, and I ****ing hate it.
-
[QUOTE=nuclear fish]I know I'm joining the fray late, but it looks like you pissed some nVidia fanboi off, and now they're giving you a nice custom title.
As an EE for a long, long time, and having worked with nVidia **** (thank GOD we use ATI's chipsets now; as an EE I far prefer ATI gear to work with), I am going to voice solidarity with you in the fact that nVidia is a terrible hardware manufacturer.[/QUOTE]
-
Am not a "him".
As for a "good" Athlon64 board, well, the nForce3 boards are actually more reliable than the nForce4 ones. Except when they're not. I'd go for a Via one, actually, even if they don't have the AWESOME features
-
...
I looked at this for about a minute before I realized there really isn't any nicer way to say this:
Then stop ****ing around with the HyperTransport. That interface was marginned by people far smarter than either one of us. LEAVE IT ALONE UNLESS YOU WANT YOUR MACHINE TO CRASH.
-
Go and look up what "C1 power state" is. Know that your Athlon runs in this state at all times. Know that unless you're running gcc's optimizer or compressing H.263 the whole time, you're not even getting close to hitting peak TDP or stressing the bus (rather, SDRAM controller and HT initiator) fully.
Yeah, that sucks, but I am a firm believer in crossing bridges when I come to them, so if I need to get a dual core, I'll get a new board to go with it if I need to.
Incidentally, nForce4 boards are even less stable with the dual core chips. These dual core parts can actually continuously saturate the HT, which stresses everything more. There's also other stuff I can't talk about.
Becasue it shortens lifespan for no real performance gain, because it reduces reliability, and because it forces the people who design the bus electronics to build them in a way that is annoyingly difficult to validate (-> nVidia doesn't seem to bother) due to metastability.
I don't want to get into a huge off-topic rant about this, but seriously, if you want a machine that's 400MHz faster than the one you can afford today, just wait three weeks or sell your Ritalin on the black market or something. Don't insist that hardware should support being run outside of spec.
-
One of the big problems with the Athlon64 (and Opteron, and friends) is that because it has a radically different way of interacting with the host system (HyperTransport, on-board DRAM controllers, NUMA, etcetera) to previous processors, the chipset vendors haven't really got the hang of it yet. I expect these problems to be worked out in time- after all, the chipsets I work with generally haven't actually been released to the public at the time I work with them- but this is taking longer than expected.
Because HyperTransport is a system where both initiator and target have lots of state, there are complex bugs which can manifest themselves in obscure ways, and the real test of a chipset vendor is not in whether they have these bugs- they all do- it's in how responsive they are to the reports of system builders. AMD, to their credit, turn up with a HyperTransport analyzer whenever we say "Uh, little help here guys". nVidia refuse to accept the existence of bugs even when we send them logic analyzer printouts with red circles drawn around the protocol errors on the PCIe system. That's why I'm so down on nVidia- they don't give a **** about bugs in their product, they don't give us adequate documentation, and they don't help us when things break. It's an attitude thing.
Right now, believe it or not, VIA is pretty good- they seem to have a good handle on HyperTransport- and the newer ULi stuff is, while not the most popular or featuresome, at least pretty clean.
-
The problem is that customers demand them. And the customer is always right! Even when he doesn't know jack ****!
-
I do. It's 16 bits wide.
-
It's double-pumped at 1GHz on sock939, and on the older sockets it's double-pumped at 800MHz. There are skew compensation delay locked loops on each line. I'm not sure if all implementations are 16 bits wide- I suspect some of the older ones are only 8 bits. (HyperTransport supports 1, 2, 4, 8, 16 and 32-bit widths, though any particular host chipset generally only supports one width.)
Any given HyperTransport link only goes in one direction (it's a so-called write-only fabric) so you can actually achieve full bandwidth in both directions at the same time as long as the synchronizing state machines at both ends can cope with doing that. And the power supply, heh.
Surprisingly, a wax spill on a motherboard in the area over the processor socket track fanout can stop it working, even though it doesn't conduct- wax has a different dielectric constant to air, which can alter the effective length of a track by enough to push the signals out of skew spec.
These fast signals are really, really touchy- a bit on HyperTransport at 1GHz travelling down the tracks is only a few centimetres long.
-
The HyperTransport is a point-to-point network. There is an 'in' bus on each processor and an 'out' bus on each processor, and the same on the chipset. The chipset fans out narrower HyperTransports to other HyperTransport devices. It's (almost) a tree-structured network.
Because each HyperTransport link is unidirectional, the hardware is cheap and (relatively) simple. The price of operating 'up' and 'down' links simultaneously is that there is a potential for deadlock where a 'down' transaction needs a lock held by an 'up' transaction; the system can't resolve which one should go through and so consistency can be lost.
The signalling of the HyperTransport is much more complicated than "sixteen pins and a strobe", to the point where I'd have to start defining really tricky concepts here if I were to try and explain it, and I'd probably not make myself understood so I won't do that.
Each data line in the HyperTransport has its own little adjustable delay line that is calibrated and adjusted during the link training phase of chipset initialization. This is done by a hardware state machine- obviously, since the system firmware hub is on the other side of the HyperTransport so the processor can't boot until HyperTransport is up at least at a slow rate.
The link training sequence measures the relative delay, required drive strength and some other stuff and sets the link up properly. Later, when the BIOS is running, a block of AMD-provided code properly enumerates and initializes the entire HyperTransport tree.
-
To be entirely honest, the best chipset I've worked with lately is the Intel Hance Rapids. It's lovely and almost bug-free. Sadly it means you have to use sodding Noconas...
-
Yeah, I've had some nice experiences with e7520/e7320/Nocona systems.
Intel's memory controllers seem to be 'honourable but stupid'. There's nothing much wrong with them, but they're not very fast and they don't do any of the good stuff they could do. I think Intel was late to the game on a lot of scores, and one of those was DDR SDRAM. They were busy with Rambus... oh god. RDRAM.
They would be shorter, but the clock toggle is actually spread around the chip by the clock tree design, and also the capacitors on the package help a lot to spread the pulses. Without those factors it would be impossible to build a chip like P4.
I don't design motherboards for Google; I write firmware for Google, and work on hardware debugging motherboards we have too. I probably can't talk about the sort of level of design work we do, but suffice to say that when you buy a lot of motherboards, companies like Asus (actually, not Asus) stop asking you what kind you want and start asking which kind you'd like them to make.
-
Uh, I don't think you really understand what we do at Google.
-
Sorry, I didn't mean to snipe; all I was saying was that we don't let people see our hardware, and hardware is very tightly tied to firmware, so we couldn't really release our firmware... not to mention the fact that the whole reason I hack BIOSes at all at Google is that a standard type BIOS is grossly inappropriate to a large cluster. I mean, if you had thousands of machines, none of which had keyboards attached, and periodically some of them would lose CMOS contents (it happens) and decide that it needs F1 pressing to continue, you'd have a problem, right?
-
The processor is not the problem; we get good support and lots of information from Intel and AMD (and also Freescale, should we want it). The problem is the motherboard chipset- if we use Intel ones, we get excellent support, and I'm sure if we used AMD ones we'd be fine too, but AMD don't make chipsets any more. Instead, we have to deal with nVidia, and they're a bunch of *****.
-
Documentation for pre-release hardware is almost always provided only on paper. We had to really twist their arms to get a register list with no explanation of what registers actually did. It took us three weeks to work out how to turn on power to the ethernet PHY.
-
Last week they tried "It's AMD's fault!"
AMD turned up on our doorstep with a HyperTransport analyzer and a bunch of really ****ing hardcore EEs to check out what the Opterons were doing.
Turns out that the Opteron is all coo'...
-
AMD are really nice guys. They always treat us with respect and they always follow through on their promises.
-
nVidia outcompeted them. Hooray.
