WEBVTT 00:00:00.120 --> 00:00:05.960 if you went to the grocery store gave them your money and left with 10% less 00:00:04.080 --> 00:00:11.880 vomite than you paid for you'd probably be pretty ticked off but what if I told 00:00:07.919 --> 00:00:16.119 you that happens every day except with 00:00:11.880 --> 00:00:18.520 $350 CPUs well it's true these 12 chips 00:00:16.119 --> 00:00:23.080 were obtained over a span of a month from eight different sources spread 00:00:20.480 --> 00:00:29.439 across three separate countries and the real world difference between the best 00:00:25.680 --> 00:00:33.879 and the worst of them is 8% in factorio 00:00:29.439 --> 00:00:35.800 and as much as is 12% in csgo this has 00:00:33.879 --> 00:00:40.800 caused a lot of problems for us over the last 6 months you see in April I gave 00:00:38.640 --> 00:00:44.960 the Labs team the goal of increasing our testing throughput so that we could give 00:00:42.399 --> 00:00:50.879 you guys more juicy benchmarks in our reviews unfortunately the math was not 00:00:48.840 --> 00:00:55.440 in our favor you see the typical turnaround to troubleshoot Benchmark 00:00:53.000 --> 00:01:01.559 write film edit and QC our coverage of a new product is 5 to8 business days at 00:00:58.960 --> 00:01:05.199 about 5 minutes per test times three runs for consistency checks times 00:01:03.600 --> 00:01:09.439 however many products we want to compare times however many games or applications 00:01:07.040 --> 00:01:14.920 you guys want to see it is easy to run out of time now we could shorten each 00:01:12.280 --> 00:01:19.159 test but we' found that longer tests are more consistent from run to run and end 00:01:17.520 --> 00:01:24.119 up being more reflective of the real world experience of using the product so 00:01:21.880 --> 00:01:28.000 that's out and I guess we could work through the nights like a bunch of AD 00:01:25.360 --> 00:01:32.320 oral out Master students but come on guys we're not that young anymore 00:01:30.280 --> 00:01:36.399 automation with mark bench does help a lot but if our system hangs in the 00:01:34.280 --> 00:01:40.799 middle of the night which it happens sometimes we're right back where we 00:01:38.200 --> 00:01:45.640 started which leaves us with one real option building up more of our test 00:01:43.360 --> 00:01:53.520 benches and running our tests in parallel except as I already told you 8% 00:01:49.880 --> 00:01:56.280 difference in factorio 12% in 00:01:53.520 --> 00:02:03.280 csgo now when I signed the procurement authorization for 11 CPUs I knew that we 00:02:00.640 --> 00:02:07.399 were likely to find an outlier or two but then it turned out that this Rabbit 00:02:05.039 --> 00:02:13.520 Hole went way deeper than I could possibly have known like this deep 00:02:10.280 --> 00:02:15.480 Saveway to our sponsor nexigo whether 00:02:13.520 --> 00:02:19.120 you're in need of webcams or VR accessories nexigo has products that'll 00:02:17.480 --> 00:02:25.519 make you nexigo wow those are cool learn more 00:02:23.480 --> 00:02:29.200 about them at the link below now before you start sharpening your pitchforks and 00:02:27.160 --> 00:02:33.959 demanding that AMD's Executives be turned into Al paste or something it's 00:02:31.840 --> 00:02:38.519 worth noting that most of our chips were within a few percentage points of each 00:02:35.519 --> 00:02:40.599 other even in csgo at 1440p which was 00:02:38.519 --> 00:02:45.159 the test that saw the greatest overall spread also when we expand our 00:02:43.280 --> 00:02:52.000 comparison to include our full Suite of games that maximum difference Falls to 00:02:48.159 --> 00:02:53.959 around 2 and 1 12% far less outrageous 00:02:52.000 --> 00:02:57.120 so you don't really have to worry about Buddy in front of you in line getting a 00:02:55.720 --> 00:03:04.599 way better gaming experience for the same price but still too big big for us 00:03:00.480 --> 00:03:07.159 to buy any two random 7800x 3DS use them 00:03:04.599 --> 00:03:12.280 to test two different gpus in parallel and then say well these results should 00:03:09.159 --> 00:03:14.480 be comparable now the obvious conclusion 00:03:12.280 --> 00:03:19.480 at this point then is guys there's something wrong with your csgo test I 00:03:16.959 --> 00:03:24.440 think it's time to get good but the thing is there aren't a lot of variables 00:03:21.560 --> 00:03:29.799 here and that's by Design we used the same motherboard same memory same 00:03:26.519 --> 00:03:31.799 Windows drive and install we even tested 00:03:29.799 --> 00:03:36.200 using phase change thermal pads to ensure that our paste application wasn't 00:03:33.640 --> 00:03:40.680 an issue and we chucked our bench in the thermal chamber just for good measure we 00:03:38.840 --> 00:03:45.319 are very confident that our numbers are valid and we're going to have the process doc Linked In the video 00:03:43.159 --> 00:03:50.680 description if you want to have a look which is all finding good but doesn't 00:03:47.519 --> 00:03:53.360 answer the much bigger question of why 00:03:50.680 --> 00:03:58.720 do these CPUs vary so much in the first place AMD gave them the same model 00:03:56.239 --> 00:04:04.200 number and specifications AMD charges the same price so they should have the 00:04:01.000 --> 00:04:07.319 same performance right well back in the 00:04:04.200 --> 00:04:09.239 day that was true CPUs would run at 00:04:07.319 --> 00:04:13.760 their rated speed and if they didn't it meant they were either broken or they 00:04:11.360 --> 00:04:18.040 were about to be but thanks to a relatively recent Innovation called 00:04:15.599 --> 00:04:23.120 Dynamic frequency scaling that's no longer the case you see no two pieces of 00:04:21.079 --> 00:04:27.720 silicon are the same and whether it's through rolling improvements to 00:04:24.840 --> 00:04:31.600 manufacturing or just sheer blind luck you can end up with a processor that is 00:04:29.280 --> 00:04:36.280 capable of better than the advertised clock speed now in the old days you 00:04:34.080 --> 00:04:41.720 could unlock this extra performance manually through overclocking but 00:04:38.759 --> 00:04:46.039 nowadays processors just adjust their own speeds and they do it on the Fly 00:04:43.919 --> 00:04:50.919 based on a whole host of factors including user configurable power 00:04:47.960 --> 00:04:55.919 profiles and thermal limits AMD's approach is to allow the CPU to clock as 00:04:53.440 --> 00:05:00.840 high as it's able until the CPU die average reaches about 90° C at which 00:04:59.039 --> 00:05:05.759 point the clock will be dialed back until it reaches equilibrium sounds good 00:05:03.320 --> 00:05:11.560 right I mean why be bound by some artificial performance limiter when I 00:05:08.440 --> 00:05:13.800 got a golden chip that can go higher and 00:05:11.560 --> 00:05:18.759 I actually agree but for the folks who end up with a lesser chip can feel a 00:05:16.280 --> 00:05:24.360 little bit like missing out even if AMD is careful to only guarantee clock 00:05:20.720 --> 00:05:26.919 speeds that 100% of the chips can hit 00:05:24.360 --> 00:05:30.440 and as I mentioned before it's also very inconvenient for our parallel testing 00:05:29.160 --> 00:05:36.560 endeavors so what do we do testing lots of it 00:05:34.479 --> 00:05:41.720 after throwing cinch at our very first CPU we ran into our very first roadblock 00:05:39.880 --> 00:05:48.520 the numbers from run to run can be vastly different I am talking 300 point 00:05:44.520 --> 00:05:51.479 spreads on a single CPU run back to back 00:05:48.520 --> 00:05:57.039 what the heck right how on Earth are we supposed to narrow down which two CPUs 00:05:53.840 --> 00:06:00.479 are within 1% of each other if one CPU 00:05:57.039 --> 00:06:03.199 isn't within 1% of itself 00:06:00.479 --> 00:06:08.039 as it turns out software was the culprit and software is notoriously hard to 00:06:05.680 --> 00:06:11.840 account for have you ever opened up task manager right when you boot up your 00:06:09.520 --> 00:06:17.800 system there's no programs running nothing should be happening except wrong 00:06:14.880 --> 00:06:21.880 what was that here's the thing even when you're doing nothing your operating 00:06:19.599 --> 00:06:25.400 system is busy managing all the behind the-scenes work that keeps your system 00:06:23.400 --> 00:06:28.759 running like updating the weather widget synchronizing the clock with a trusted 00:06:26.960 --> 00:06:35.919 time server prepping the next thing it thinks you might installing updates and 00:06:31.560 --> 00:06:37.800 so much more and we don't really get to 00:06:35.919 --> 00:06:44.599 decide when that stuff happens which means that no one result can ever be 00:06:41.000 --> 00:06:46.599 taken as gospel truth we do have custom 00:06:44.599 --> 00:06:51.560 Windows images that are intentionally debloated to remove some startup 00:06:48.960 --> 00:06:56.039 processes to help with this but it only partially mitigates the issue and it 00:06:53.919 --> 00:07:00.560 introduces new ones like making our results slightly less representative of 00:06:58.240 --> 00:07:04.800 the typical user we feel this trade-off is worthwhile because it helps us to 00:07:02.440 --> 00:07:09.039 better isolate our variables in testing but it's not even enough to further 00:07:07.199 --> 00:07:15.000 mitigate the amount of work that Windows is doing in the background we can also 00:07:11.520 --> 00:07:16.960 increase a process's priority in cinch 00:07:15.000 --> 00:07:22.160 we went from seeing points varying in the hundreds down to the tens on the 00:07:19.240 --> 00:07:26.560 same CPU that's a big Improvement and enough to use cinebench for our binning 00:07:23.919 --> 00:07:31.520 process but we're not out of the woods yet you see with some tests it's not 00:07:29.680 --> 00:07:36.759 enough to use the same Hardware at the same process priority because the 00:07:33.479 --> 00:07:39.160 benchmarks themselves have built in 00:07:36.759 --> 00:07:44.960 inconsistencies Red Dead Redemption 2 for example simulates physics and AI 00:07:42.360 --> 00:07:49.080 behavior during a bench run that's a really good thing because if that stuff 00:07:46.720 --> 00:07:54.159 was canned our results would not be comparable to actually playing the game 00:07:51.840 --> 00:07:58.840 but the bad news is it means that sometimes Arthur loses his hat sometimes 00:07:56.199 --> 00:08:02.560 he doesn't sometimes the horse gets shot sometimes it doesn't 00:08:00.000 --> 00:08:07.560 which can impact our run-to-run consistency can we ever fully account 00:08:04.720 --> 00:08:11.759 for this unfortunately not but by running each test multiple times and 00:08:09.720 --> 00:08:17.479 then taking an average we can get a pretty good picture and we can bake that 00:08:14.639 --> 00:08:23.879 expectation of noise into our data analysis which finally happens now sorry 00:08:20.639 --> 00:08:25.759 for all the Preamble first up gaming for 00:08:23.879 --> 00:08:30.400 the sake of legibility we named each of our samples after a Pokémon why Pokémon 00:08:29.039 --> 00:08:35.760 I don't know cuz it seemed better than deadly diseases any who looking at the 00:08:33.680 --> 00:08:40.000 geometric mean of our gaming results we found a 00:08:37.279 --> 00:08:46.200 2.07% spread in average frames per second between the best performing and 00:08:42.360 --> 00:08:49.880 the worst performing CPUs and a 2.4 6% 00:08:46.200 --> 00:08:52.920 spread in our 1% lows this puts all but 00:08:49.880 --> 00:08:55.360 one of our CPU samples within three 00:08:52.920 --> 00:09:00.200 frames per second of each other which gives us confidence that we'll be able 00:08:57.000 --> 00:09:01.480 to find some close enough CPUs but but 00:09:00.200 --> 00:09:07.640 given that 2.46% isn't 1% it also tells us that we 00:09:05.399 --> 00:09:13.560 can't just pull any three chips at random nor can we simply look at the 00:09:11.000 --> 00:09:18.079 average returnal for instance is a benchmarker dream because a it's 00:09:16.640 --> 00:09:23.760 actually a good game that people might want to play and B it is a stunningly 00:09:21.480 --> 00:09:29.560 consistent Benchmark which is great for producing results that we can trust when 00:09:25.880 --> 00:09:32.640 we're comparing gpus but the real world 00:09:29.560 --> 00:09:35.560 is a lot messier than returnal and while 00:09:32.640 --> 00:09:41.440 most of our other games both at 1440p and 1080p showed a similar small level 00:09:38.880 --> 00:09:46.160 of variance in CPU performance in a couple of games notably Total War 00:09:43.519 --> 00:09:52.000 Warhammer 3 and cyber Punk we found larger variants in the 1% lows this 00:09:49.320 --> 00:09:57.680 indicates that as run these games are more CPU bottleneck which better reveals 00:09:55.200 --> 00:10:04.720 the deficiencies of our worst chips but as you're about to see not all CPU bound 00:10:01.040 --> 00:10:08.320 games are bound in the same ways we went 00:10:04.720 --> 00:10:11.360 into this process thinking ah CSG go 00:10:08.320 --> 00:10:14.240 what a classic CPU gaming Benchmark it's 00:10:11.360 --> 00:10:20.440 a shame that it's been replaced by CS2 and we came out of it thinking ah CS 00:10:17.240 --> 00:10:22.640 good ridds I mean on the one hand it 00:10:20.440 --> 00:10:29.640 does certainly separate the CPUs from each other and our slowest chip Corola 00:10:25.839 --> 00:10:32.880 was the slowest s in csgo but on the 00:10:29.640 --> 00:10:35.959 other hand the overall variance is so 00:10:32.880 --> 00:10:38.000 high and so different from the entire 00:10:35.959 --> 00:10:43.680 rest of our test Suite that it becomes almost an outlier data point having an 00:10:40.639 --> 00:10:46.399 outsized impact on our results and this 00:10:43.680 --> 00:10:51.600 could be for a number of reasons first csgo uses a game engine that is older 00:10:48.920 --> 00:10:56.760 than YouTube which has been useful over the years since it was originally built 00:10:53.920 --> 00:11:00.279 just for single core CPUs and it can make use of just about all the single 00:10:58.880 --> 00:11:05.079 threaded performance that you can give it but it also means that its 00:11:02.920 --> 00:11:08.800 performance requirements just aren't very similar to more modern games that 00:11:07.079 --> 00:11:16.360 are going to want to see a number of fast cores rather than just one or two 00:11:12.440 --> 00:11:18.440 second csgo itself is also old old 00:11:16.360 --> 00:11:22.760 enough that any modern gaming CPU can run it so fast that no professional 00:11:20.920 --> 00:11:28.480 Esports gamer even could tell the difference anyway and so fast that 00:11:26.040 --> 00:11:33.839 limitations in the software itself can start to rear their ugly heads which 00:11:30.480 --> 00:11:35.880 adds potential variables basically csgo 00:11:33.839 --> 00:11:41.079 is having its Quake three Arena moment after a long run it's time to drop it 00:11:39.160 --> 00:11:46.160 and when we reviewed the overall variance numbers without csgo it shows 00:11:44.000 --> 00:11:50.360 just how much of an outsized influence that it had on our results the new 00:11:48.320 --> 00:11:56.880 results show far less variance closing the spread to just 46% and 1.43% for the 00:11:54.160 --> 00:12:02.040 average and 1% lows respectively which is somewhat reassuring for you the 00:11:59.399 --> 00:12:08.760 consumer but still doesn't change that our runaway loser corsola is still a dud 00:12:06.240 --> 00:12:13.360 Corola consistently underperformed the rest of the chips by so much that when 00:12:10.959 --> 00:12:19.120 we remove it from our results our overall spread and performance goes from 00:12:15.639 --> 00:12:23.519 1.43% in our lows to 00:12:19.120 --> 00:12:25.760 86% that is a massive decrease so what 00:12:23.519 --> 00:12:30.360 the heck is wrong with this thing we don't know for sure but one guess is 00:12:28.120 --> 00:12:35.199 that the 3D V cach on this chip could be struggling some way because it fumbles 00:12:32.440 --> 00:12:40.360 pretty hard in our factorio test where most of the Benchmark can actually fit 00:12:37.279 --> 00:12:42.440 on that 3D V cache another possibility 00:12:40.360 --> 00:12:47.279 is that it could be the PCIe controller the part of the CPU that communicates 00:12:44.320 --> 00:12:51.240 with our PCIe lanes and consequently our GPU this idea comes from the fact that 00:12:49.800 --> 00:12:56.120 when it comes to productivity performance sure it's still ain't top of 00:12:53.800 --> 00:13:01.079 the class but it isn't flunking like it used to speaking of we actually found 00:12:59.279 --> 00:13:06.079 greater variance between our chips in our productivity tests which kind of 00:13:03.839 --> 00:13:11.639 makes sense since we no longer have the GPU getting in the way of raw CPU 00:13:09.079 --> 00:13:16.519 performance szip brought us a spread of around 3 to 4% for compression and 00:13:13.920 --> 00:13:21.519 decompression and blender hovers in the same realm along with our video and 00:13:19.079 --> 00:13:25.519 audio encoding Suites the biggest contributor to the size of the spread of 00:13:22.959 --> 00:13:29.680 our sample though is Lugia who takes up the bottom spot in pretty much every 00:13:27.880 --> 00:13:33.480 productivity benchmark since it wasn't so bad in gaming this 00:13:31.639 --> 00:13:38.760 leads us to believe that perhaps there's a problem with the integrated heat 00:13:35.120 --> 00:13:40.279 spreader but AMD has made that much more 00:13:38.760 --> 00:13:45.120 difficult to evaluate now that all of their CPUs just kind of run at the same 00:13:43.240 --> 00:13:50.399 temperature and then adjust their clock speeds to reach their thermal limit so 00:13:48.000 --> 00:13:55.279 across our small sample variance in performance is present but not egregious 00:13:53.480 --> 00:14:00.639 of course we aren't trying to quantify variants what we're trying to find is 00:13:57.759 --> 00:14:04.839 equivalence so how do we do that it turned out to be a bit tricky we ended 00:14:02.600 --> 00:14:09.560 up using ukian distance to determine which CPUs were the most similar 00:14:07.240 --> 00:14:14.000 unconventional but also kind of cool here's how it works first we scaled our 00:14:11.959 --> 00:14:18.839 data so that our five-digit cinebench scores don't overshadow those low 00:14:16.240 --> 00:14:22.519 flacking code numbers then we took those scaled numbers and treated each as a 00:14:21.160 --> 00:14:26.880 coordinate for a point in multi-dimensional space think about it 00:14:24.880 --> 00:14:31.560 kind of like this if we took a plane and chose two points those would each have 00:14:28.560 --> 00:14:33.680 an X and y-coordinate well the ukian 00:14:31.560 --> 00:14:37.560 distance is the distance between those two points the closer together the 00:14:35.519 --> 00:14:41.680 points are the more similar they are and this can be applied for points that 00:14:39.000 --> 00:14:46.480 exist in any dimension in our case a 12-dimensional space for productivity 00:14:43.720 --> 00:14:50.360 and the 19th dimension for gaming since we're weighing all of our tests as equal 00:14:48.720 --> 00:14:55.600 we can then do a bunch of comparisons to determine which CPUs are the most 00:14:52.639 --> 00:15:01.480 similar to one another from that four emerge as extremely comparable EV Mewtwo 00:14:59.040 --> 00:15:07.600 Raichu and Zapdos with Zapdos being the least equivalent so sorry bro just the 00:15:04.680 --> 00:15:13.399 other three they are outside of our tolerance in csgo but the issue is that 00:15:10.560 --> 00:15:17.880 the CPUs that did perform identically in that one game were not the tightest 00:15:15.959 --> 00:15:22.320 across the rest of the suite meaning that they can't really be trusted on 00:15:19.800 --> 00:15:26.240 games that you know you might actually be able to play in conclusion 00:15:24.440 --> 00:15:33.240 productivity saw these CPUs perform within roughly 24% of one another and in 00:15:29.560 --> 00:15:37.199 gaming we see a spread of 86% in the 1% 00:15:33.240 --> 00:15:40.040 lows and just. 1% in average frame rates 00:15:37.199 --> 00:15:44.639 now that's tight tight enough we figure that it will allow us to directly 00:15:41.720 --> 00:15:52.000 compare GPU results across our test benches wait Ben jez oh yeah you see 00:15:49.759 --> 00:15:58.519 where I'm going with this we found near identical CPUs but what about the other 00:15:55.000 --> 00:16:01.720 components do they vary time for another 00:15:58.519 --> 00:16:03.519 round of testing the main secondary 00:16:01.720 --> 00:16:07.639 performance contributors in your GPU test bench are going to be your 00:16:05.040 --> 00:16:12.519 motherboard and your RAM but since those still run at fixed clock speeds we're 00:16:09.839 --> 00:16:17.720 not expecting nearly as much variance with RAM for example you set the speeds 00:16:14.800 --> 00:16:23.480 in your BIOS and then it's either capable or it's not and your system is 00:16:20.319 --> 00:16:25.240 unstable and probably crashes all of our 00:16:23.480 --> 00:16:29.279 testing is done at the recommended RAM speed from AMD 6,000 megat transfers per 00:16:27.959 --> 00:16:32.600 second and if you want to learn even more about how we test our Hardware 00:16:31.040 --> 00:16:36.519 we've got a recent exclusive over on Floatplane.com where we have a 00:16:34.319 --> 00:16:40.319 featurelength deep dive looking at the improvements we've made to our testing 00:16:38.079 --> 00:16:46.240 processes anyway to validate our hypothesis we took one of our future 00:16:42.519 --> 00:16:49.680 test CPUs EV and threw it into both of 00:16:46.240 --> 00:16:53.600 our new parallel benches in gaming we 00:16:49.680 --> 00:16:55.560 landed on. 45% variance in the 1% lows 00:16:53.600 --> 00:17:01.560 and less than a tenth of a percent in average FPS that is more than acceptable 00:16:59.199 --> 00:17:07.400 and in productivity we ended up in the. 13% neighborhood that means in our 00:17:04.559 --> 00:17:11.160 upcoming GPU reviews performed on these three parallel benches we're going to 00:17:09.400 --> 00:17:18.120 consider our results to be accurate within plus or minus about. 00:17:14.760 --> 00:17:21.039 25% of course that doesn't mean that our 00:17:18.120 --> 00:17:24.919 results will be identical to your CPU or to other media and this is one of the 00:17:23.160 --> 00:17:28.480 big reasons that we have always encouraged our viewers to look at 00:17:26.240 --> 00:17:33.440 reviews from multiple Outlets whenever making a purchase decision oh before you 00:17:31.039 --> 00:17:39.039 ask by the way there does not appear to be any Foul Play from AMD with respect 00:17:35.960 --> 00:17:41.400 to review sample selection so you don't 00:17:39.039 --> 00:17:46.480 have to pick a reviewer for example that buys their own CPUs versus one that gets 00:17:43.679 --> 00:17:51.280 seated at least we don't think so we'd have to buy hundreds of CPUs to know for 00:17:48.320 --> 00:17:56.360 sure but it appears that the unit that was sent to us for a review which is 00:17:53.039 --> 00:17:58.640 Raichu Falls somewhere in the good but 00:17:56.360 --> 00:18:05.159 not exceptional range so I think we can put put that conspiracy theory to rest 00:18:01.280 --> 00:18:08.000 again another before you ask is yes 00:18:05.159 --> 00:18:12.480 driver updates operating system updates and new software that we add to our test 00:18:10.080 --> 00:18:16.080 Suite could change our CPU performance spread in the future and we're going to 00:18:14.360 --> 00:18:20.159 do our best to maintain our data Integrity by performing periodic what 00:18:18.200 --> 00:18:25.080 we're going to call equivalence checks because you guys have asked for Reliable 00:18:22.919 --> 00:18:31.480 trustworthy information and you deserve it which brings us to a big issue why is 00:18:28.440 --> 00:18:33.000 this task falling to random YouTubers I 00:18:31.480 --> 00:18:37.440 mean the automotive industry for instance has government bodies that are 00:18:35.440 --> 00:18:42.080 dedicated to verifying the performance of vehicles and ensuring that companies 00:18:39.679 --> 00:18:46.960 aren't cheating on their testing then they Dole out big fines when they 00:18:44.159 --> 00:18:54.159 inevitably do cheat on their testing with computer hardware there's no such 00:18:49.720 --> 00:18:57.600 oversight we and our peers are this thin 00:18:54.159 --> 00:19:00.080 open-mouth thumbnail line between you 00:18:57.600 --> 00:19:04.760 and getting ripped off and that's a big problem I mean for one thing we don't 00:19:02.400 --> 00:19:09.000 have access to the types of testing that large tech companies have and we don't 00:19:07.159 --> 00:19:14.039 operate at the kind of scale where we can say for sure if an observation is a 00:19:11.159 --> 00:19:18.799 fluke or if it's the result of conniving suits that are trying to save a quick 00:19:15.960 --> 00:19:22.799 Buck even buying 11 chips for this investigation that was a huge investment 00:19:21.080 --> 00:19:29.000 from our side and not the sort of thing that we can do with every single review 00:19:26.880 --> 00:19:32.760 unfortunately all I'm doing is Rand in right now I don't have a solution to 00:19:30.600 --> 00:19:37.960 this other than well we're going to keep trying gosh darn it but it just struck 00:19:35.960 --> 00:19:42.080 us as we worked on this project that the fact that these companies don't have to 00:19:39.799 --> 00:19:47.000 report things like estimated performance in a regulated and standardized fashion 00:19:44.679 --> 00:19:51.480 is kind of crazy especially if you consider the kind of money that they're 00:19:48.960 --> 00:19:57.880 asking for their most expensive CPUs so what's next well first is going 00:19:56.200 --> 00:20:03.679 to be going through the exact same rig remoral with however many 490s it takes 00:20:00.640 --> 00:20:05.799 to parallelize our CPU test platforms 00:20:03.679 --> 00:20:10.080 and then slowly but surely we're going to be improving our automations and 00:20:07.960 --> 00:20:15.559 increasing our test volume especially once we get the lab's website up and 00:20:11.600 --> 00:20:18.400 running but good things take time and we 00:20:15.559 --> 00:20:26.919 aren't going to rush a good thing especially I'm not going to rush this 00:20:21.520 --> 00:20:28.960 segue to our sponsor delete me your 00:20:26.919 --> 00:20:32.320 personal information sounds like it should stay personal right I mean it's 00:20:30.640 --> 00:20:35.799 right there in the name well data Brokers and other sketchy companies 00:20:33.960 --> 00:20:41.280 disagree so they're sharing your data online like it's a family style dinner 00:20:38.159 --> 00:20:42.600 eat eat your skin and bones is what it's 00:20:41.280 --> 00:20:46.039 what they're saying to each other thankfully delete me is here to crash 00:20:44.640 --> 00:20:50.480 the party they'll find out who's spilling your info and get it removed so 00:20:48.360 --> 00:20:54.640 that scammers can't use it to batter you with Robo calls and spam emails never 00:20:52.799 --> 00:20:59.159 mind that it can also lead to fraud or identity theft because delete me can 00:20:56.640 --> 00:21:03.880 mind that for you now what wiping out data held by hundreds of sites by 00:21:01.360 --> 00:21:07.159 yourself sounds borderline impossible which is why this whole time I've been 00:21:05.280 --> 00:21:11.200 trying to tell you that delete me can do it you don't have to their Nifty 00:21:09.280 --> 00:21:15.640 software and expert Squad can sweep it away in minutes not hours delete me 00:21:13.320 --> 00:21:20.720 averages over 2,000 pieces of personal data gone for a customer in their first 00:21:17.480 --> 00:21:22.559 two years yeah go on delete me get them 00:21:20.720 --> 00:21:27.480 and you should get on over to the link below and use code LTT for a sweet 20% 00:21:25.679 --> 00:21:31.679 off if you guys enjoyed this video why not check out our motherboard turbo nerd 00:21:30.000 --> 00:21:38.760 Edition video where we went into what exactly are all those little things that 00:21:33.159 --> 00:21:38.760 look like cities and towns on the PCB