Athlon II X3 vs. Ryzen 3: How AMD's Performance Has Evolved & Performance-Per-Watt

[schmidtbag]

Cool. My last Ebay purchase to salvage didn't turn out as well. I still came out ahead, I spent $500 to get what turned out to be something worth about $700. But I hoped to get $1000 out of the purchase... and then discovered that the PSU and GPU were junk (with the former probably the reason the latter was broken).

Again, are you able to do video encoding with that V7900 on Linux? Are there programs I'm missing?

Yeah, desktop PSUs, HDDs, and fans are pretty much the only components I will absolutely refuse to buy used. I'll gladly take any given to me and repurpose them, but I wouldn't ever buy them.

Like I said, this PC is for BOINC, so I haven't tested video encoding and I probably never will. I hear handbrake is better off with CPU encoding, at least if you care about quality. If you want good GPU accelerated encoding, I'd recommend you use ffmpeg or gstreamer (with the "bad" plugins):

https://trac.ffmpeg.org/wiki/HWAccelIntro#AMDUVDVCE

I'm not really sure if video encoding cares about FP64 (double-precision floats) which FirePro and Quadros are good for. That being said, don't limit yourself to workstation graphics, but I personally found they're usually a better value compared to gaming cards when bought used. Just pay close attention to the architecture used, because things like drivers, OpenCL, and VAAPI don't support all hardware.

[JustRob]

I remember back in Athlon and Pentium 3 days and before, each upgrade was significant. Now each year we have 10% improvement to the speed. ...

I was thinking the same thing.

Oversimplification of the results: 8 years gives 2 to 4x faster Benchmarks (nothing to brag about).

When I was a Tech (decades ago) we could tell the customer that they probably wanted to buy a new Computer in 3 to 4 years because the replacement would be twice as fast for half the cost.

Things have slowed down because for many tasks an old computer is fast enough and there's not the necessity to upgrade, whereas before you'd be left in the dust if you didn't.

Nowadays people cry about Internet speed, we didn't cry about that back then (especially after the huge upgrade to 1200 Baud, 4x speed).

[coder]

If you want a power efficient thin client, I would highly recommend ARM boards. Even the original Raspberry Pi would be great for that.

No, the Pi is not great for thin client. Its GPU is weak. Even the CPU is pretty poor. And the I/O performance is utter crap.

If I were going for something ARM-based, ODROID C2 would be near the top of my list. I'm sure there are even better options, depending on how much one is willing to spend.

IMO, Apollo Lake is the gold standard for performance + hardware support, but now you're talking about some real money.

[schmidtbag]

No, the Pi is not great for thin client. Its GPU is weak. Even the CPU is pretty poor. And the I/O performance is utter crap.

Do you not know what a thin client is? It isn't a standalone PC. It's not supposed to have a good GPU or CPU, because that's that the server end is for. As long as the thin client's hardware can keep up with your workload (whether that be SSH, VNC, NX, or whatever) then it is good enough. The only reason a Pi would be insufficient is the Ethernet bandwidth - the hardware otherwise should be perfectly capable.

If I were going for something ARM-based, ODROID C2 would be near the top of my list. I'm sure there are even better options, depending on how much one is willing to spend.

The C2 is overkill; the C1 would be just as good.

[duby229]

Do you not know what a thin client is? It isn't a standalone PC. It's not supposed to have a good GPU or CPU, because that's that the server end is for. As long as the thin client's hardware can keep up with your workload (whether that be SSH, VNC, NX, or whatever) then it is good enough. The only reason a Pi would be insufficient is the Ethernet bandwidth - the hardware otherwise should be perfectly capable.


The C2 is overkill; the C1 would be just as good.

I've never worked with ARM thin clients yet, but I do work with a lot of thin clients. And really they do need decent network latency, but bandwidth isn't really that big of a problem. So for a thin client I've learned the leaner the host OS is the better. Keep that host OS doing nothing but running the thin client and you can run it on almost anything.

[schmidtbag]

I've never worked with ARM thin clients yet, but I do work with a lot of thin clients. And really they do need decent network latency, but bandwidth isn't really that big of a problem. So for a thin client I've learned the leaner the host OS is the better. Keep that host OS doing nothing but running the thin client and you can run it on almost anything.

Correct me if I'm wrong but can't you effectively trade bandwidth for latency and vise versa? Compression takes time, as does decompression. The more you compress something, the worse the latency will be. If you want to retain quality, you'll need more processing power. So really, if your bandwidth is good enough, so should your latency. That's not to say you can't get good latency with low bandwidth, but you'll have to make other sacrifices (such as quality) or framerate.

To my knowledge, RPi has decent video decoders so depending how you want to stream your content, it is perfectly capable of acting as a thin client. Whether or not it would make for a good one is debatable, but it is an adequate one for 720p or 1080p and a very affordable one. Devices like the Odroid C1+ would make for a better thin client, since that offers gigabit ethernet and sufficient processing power in the event you can't rely on GPU transcoding, while still remaining very cheap and low-power.

Personally, I think ARM devices are the way to go for thin clients, and would highly recommend them. But as you said, it depends what else you intend to run on the OS.

[duby229]

Correct me if I'm wrong but can't you effectively trade bandwidth for latency and vise versa? Compression takes time, as does decompression. The more you compress something, the worse the latency will be. If you want to retain quality, you'll need more processing power. So really, if your bandwidth is good enough, so should your latency. That's not to say you can't get good latency with low bandwidth, but you'll have to make other sacrifices (such as quality) or framerate.

To my knowledge, RPi has decent video decoders so depending how you want to stream your content, it is perfectly capable of acting as a thin client. Whether or not it would make for a good one is debatable, but it is an adequate one for 720p or 1080p and a very affordable one. Devices like the Odroid C1+ would make for a better thin client, since that offers gigabit ethernet and sufficient processing power in the event you can't rely on GPU transcoding, while still remaining very cheap and low-power.

Personally, I think ARM devices are the way to go for thin clients, and would highly recommend them. But as you said, it depends what else you intend to run on the OS.

No, I'd say you got it spot on really. Of course you need enough CPU capacity to actually run the thin client itself at decent performance. And depending on what protocols, cryptography, compression, etc you choose their can be hardware acceleration you can take advantage of.

I've been using RDP/NX for windows sessions using a linux to host the think client. I mean even single core P4 and Athlon era hardware using integrated Intel and Via graphics run well. Most of the hardware is newer than that, but some of that old hardware is still around.

[grok]

"Even" Pentium 4 and Athlon? Pentium II 233 with 32MB or 64MB RAM will do. It did for LTSP thin client mode, booted from PXE (if you don't have a bootrom on the ethernet card, you can use a floppy for PXE boot). This set up didn't have sound or advanced features but besides slowish graphical performance (for e.g. flash games ; youtube videos played in the default small window, if slower than normal) it had advantages over stand alone workstations : the multiples cores and gigs of RAM of the powerful back then target PC, as well as home directory on local storage instead of NFS mount.

Relative quietness thanks to the lack of hard drive. Pentium II and III PCs with Intel chipset had better reliability than Pentium 4 and Athlon XP.
If I recall correctly, Raspberry Pi 1 had around the CPU power of a better Pentium II, but worse I/O as the Pentium II PC has a PCI bus.

[duby229]

"Even" Pentium 4 and Athlon? Pentium II 233 with 32MB or 64MB RAM will do. It did for LTSP thin client mode, booted from PXE (if you don't have a bootrom on the ethernet card, you can use a floppy for PXE boot). This set up didn't have sound or advanced features but besides slowish graphical performance (for e.g. flash games ; youtube videos played in the default small window, if slower than normal) it had advantages over stand alone workstations : the multiples cores and gigs of RAM of the powerful back then target PC, as well as home directory on local storage instead of NFS mount.

Relative quietness thanks to the lack of hard drive. Pentium II and III PCs with Intel chipset had better reliability than Pentium 4 and Athlon XP.
If I recall correctly, Raspberry Pi 1 had around the CPU power of a better Pentium II, but worse I/O as the Pentium II PC has a PCI bus.

Cool, that's good to know. For my personal experience I don't have anything that old anymore that I maintain.

[coder]

Do you not know what a thin client is? It isn't a standalone PC. It's not supposed to have a good GPU or CPU, because that's that the server end is for. As long as the thin client's hardware can keep up with your workload (whether that be SSH, VNC, NX, or whatever) then it is good enough. The only reason a Pi would be insufficient is the Ethernet bandwidth - the hardware otherwise should be perfectly capable.

People mean different things by "thin client", with some thinking a web client qualifies as thin.

Anyway, I stand by what I said. It's not a "great" thin client. Given the small price differential, faster cores, faster GPU, and especially its faster ethernet, the C2 would be a much better choice.