The Intel Core i9-7980XE and Core i9-7960X CPU Review Part 1: Workstation
by Ian Cutress on September 25, 2017 3:01 AM ESTOpinion: Why Counting ‘Platform’ PCIe Lanes (and using it in Marketing) Is Absurd
It’s at this point that I’d like to take a detour and discuss something I’m not particularly happy with: counting PCIe lanes.
The number of PCIe lanes on a processor, for as long as I can remember, has always been about which lanes come directly from the PCIe root, offering full bandwidth and with the lowest possible latency. In modern systems this is the processor itself, or in earlier, less integrated systems, the Northbridge. By this metric, a standard Intel mainstream processor has 16 lanes, an AMD Ryzen has 16 or 20, an Intel HEDT processor has 28 or 44 depending on the model, and an AMD Ryzen Threadripper has 60.
In Intel’s documentation, it explicitly lists what is available from the processor via the PCIe root complexes: here 44 lanes come from two lots of sixteen and one twelve lane complex. The DMI3 link to the chipset is in all but name a PCIe 3.0 x4 link, but is not included in this total.
The number of PCIe lanes on a chipset is a little different. Chipsets are for all practical purposes PCIe switches: using a limited bandwidth uplink, it is designed to carry traffic from low bandwidth controllers, such as SATA, Ethernet, and USB. AMD is limited in this regard, due to spending more time re-entering the pure CPU performance race over the last few years and outsource their designs to ASMedia. Intel has been increasing its PCIe 3.0 lane support on its chipsets for at least three generations, now supporting up to 24 PCIe 3.0 lanes. There are some caveats on what lanes can support which controllers, but in general we consider this 24.
Due to the shared uplink, PCIe lanes coming from the chipset (on both the AMD and Intel side) can be bottlenecked very easily, as well as being limited to PCIe 3.0 x4. The chipset introduces additional latency compared to having a controller directly attached to the processor, which is why we rarely see important hardware (GPUs, RAID controllers, FPGAs) connected to them.
The combination of the two lends itself to a variety of platform functionality and configurations. For example, for AMD's X399 platform that has 60 lanes from the processor, the following combinations are 'recommended':
| X399 Potential Configurations | |||
| Use | PCIe Lanes | Total | |
| Content Creator | 2 x Pro GPUs 2 x M.2 Cache Drives 10G Ethernet 1 x U.2 Storage 1 x M.2 OS/Apps 6 x SATA Local Backup |
x16/x16 from CPU x4 + x4 from CPU x4 from CPU x4 from CPU x4 from CPU From Chipset |
52 Lanes |
| Extreme PC | 2 x Gaming GPUs 1 x HDMI Capture Card 2 x M.2 for Games/Stream 10G Ethernet 1 x M.2 OS/Apps 6 x SATA Local Backup |
x16/x16 from CPU x8 from CPU x4 + x4 from CPU x4 from CPU x4 from CPU From Chipset |
56 Lanes |
| Streamer | 1 x Gaming GPU 1 x HDMI Capture Card 2 x M.2 Stream/Transcode 10G Ethernet 1 x U.2 Storage 1 x M.2 OS/Apps 6 x SATA Local Backup |
x16 from CPU x4 from CPU x4 + x4 from CPU x4 from CPU x4 from CPU x4 from CPU From Chipset |
40 Lanes |
| Render Farm | 4 x Vega FE Pro GPUs 2 x M.2 Cache Drives 1 x M.2 OS/Apps 6 x SATA Local Backup |
x16/x8/x8/x8 x4 + x4 from CPU x4 from CPU From Chipset |
52 Lanes |
What has started to happen is that these companies are combining both the CPU and chipset PCIe lane counts, in order to promote the biggest number. This is despite the fact that not all PCIe lanes are equal, they do not seem to care. As a result, Intel is cautiously promoting these new Skylake-X processors as having ’68 Platform PCIe lanes’, and has similar metrics in place for other upcoming hardware.
I want to nip this in the bud before it gets out of hand: this metric is misleading at best, and disingenuous at worst, especially given the history of how this metric has been provided in the past (and everyone will ignore the ‘Platform’ qualifier). Just because a number is bigger/smaller than a vendor expected does not give them the right to redefine it and mislead consumers.
To cite precedent: in the smartphone space, around 4-5 years ago, vendors were counting almost anything in the main processor as a core to provide a ‘full core count’. This meant that GPU segments became ‘cores’, special IP blocks for signal and image processing became ‘cores’, security IP blocks became ‘cores’. It was absurd to hear that a smartphone processor had fifteen cores, when the main general purpose cores were a quartet of ARM Cortex A7 designs. Users who follow the smartphone industry will notice that this nonsense stopped pretty quickly, partly due to anything being called a core, but some hints towards artificial cores potentially being placed in the system. If allowed to continue, this would have been a pointless metric.
The same thing is going to happen if the notion of ‘Platform PCIe Lanes’ is allowed to continue.
Facebook
Twitter
RSS
152 Comments
View All Comments
mapesdhs - Monday, September 25, 2017 - link
Just curious mmrezaie, why do you say "unofficially"? ECC support is included on specs pages for X399 boards.frowertr - Tuesday, September 26, 2017 - link
Run Unbound on a Pi or other Linux VM and block all thise adverts at the DNS level for all the devices on your LAN. I havent seen a site add anywhere in years from my home.Notmyusualid - Thursday, September 28, 2017 - link
@frowertrInteresting - But that won't work for me - I'm a frequent traveller, and thus on different LANs all the time.
But what works for me, is PeerBlock, then iblocklist.com for the Ad-server & Malicious lists and others, add Microsoft and any other entity I don't want my packets broadcast to (my Antivirus alerts me when I need updates anyway - and thus I temporarily allow http through the firewall for that type of occasion).
realistz - Monday, September 25, 2017 - link
This is why the "core wars" won't be a good thing for consumers. Focus on better single thread perf instead quantity.sonichedgehog360@yahoo.com - Monday, September 25, 2017 - link
On the contrary, single-threaded performance is largely a dead end until we hit quantum computing due to instability inherent to extremely high clock speeds. The core wars is exactly what we need to incentivize developers to improve multi-core scaling and performance: it represents the future of computing.extide - Monday, September 25, 2017 - link
Some things just can't be split up into multiple threads -- it's not a developer skill level or laziness issue, it's just the way it is. Single threaded speed will always be important.PixyMisa - Monday, September 25, 2017 - link
Maybe, but it's still a dead end. It's not going to improve much, ever.HStewart - Monday, September 25, 2017 - link
As a developer for 30 years this is absolutely correct - especially with the user interface logic which includes graphics. Until technology is a truly able to multi-thread the display logic and display hardware - it very important to have single thread performance. I would think this is critically important for games since they deal a lot with screen. Intel has also done something very wise and I believe they realize this important - by allowing some cores to go faster than others. Multi-core is basically hardware assisted multi-threaded applications which is very dependent on application design - most of time threads are used for background tasks. Another critical error is database logic - unless the database core logic is designed to be multithread, you will need single point of entry and in some cases - they database must be on screen thread. Of course with advancement is possible hardware to handle threading and such, it might be possible to over come these limitations. But in NO WAY this is laziness of developer - keep in mind a lot of software has years of development and to completely rewrite the technology is a major and costly effort.lilmoe - Monday, September 25, 2017 - link
There are lots of instances where I'd need summation and other complex algorithm results from millions of records in certain tables. If I'm going the traditional sql route, it would take ages for the computation to return the desired values. I instead divide the load one multiple threads to get a smaller set in which I would perform some cleanup and final arithmetic. Lots of extra work? Yup. More ram per transaction total? Oh yea. Faster? Yes, dramatically faster.WPF was the first attempt by Microsoft to distribute UI load across multiple cores in addition to the gpu, it was so slow in its early days due to lots out inefficiencies and premature multi-core hardware. It's alot better now, but much more work than WinForms as you'd guess. UWP UI is also completely multithreaded.
Android is inching closer to completely have it's UI multithreaded and separate from the main worker thread. We're getting there.
Both you and sonich are correct, but it's also a fact that developers are taking their sweet time to get familiar with and/or use these technologies. Some don't want to that route simply because of technology bias and lock-in.
HStewart - Monday, September 25, 2017 - link
"Both you and sonich are correct, but it's also a fact that developers are taking their sweet time to get familiar with and/or use these technologies. Some don't want to that route simply because of technology bias and lock-in."That is not exactly what I was saying - it completely understandable to use threads to handle calculation - but I am saying that the designed of hardware with a single screen element makes it hard for true multi-threading. Often the critical sections must be lock - especially in a multi-processor system.
The best use of multi-threading and mult-cpu systems is actually in 3D rendering, this is where multiple threads can be use to distribute the load. In been a while since I work with Lightwave 3D and Vue, but in those days I would create a render farm - one of reason, I purchase a Dual Xeon 5160 ten years ago. But now a days processors like these processors here could do the work or 10 or normal machines on my farm ( Xeon was significantly more power then the P4's - pretty much could do the work of 4 or more P4's back then )