Group Actions
Engagement
  • Author Author: Gough Lui
  • Date Created: Date Created
  • Views 12395 views
  • Likes 10 likes
  • Comments 12 comments
Related
Recommended

Under the Hood of the Lenovo Legion 5 & SSD Tests

Gough Lui

After receiving my prize, is it no great surprise that the first thing that I do is to take it apart? Alas, this was not in vain - this was all part of analysing just what sort of upgrade potential the Legion 5 has and to actually perform the upgrades when the parts finally arrived.

The first step to opening the laptop was to turn it upside down and remove all the screws holding down the monolithic back panel. Then, the rear panel needed to be carefully prised out as it was clipped on all sides and contributed to the "rigidity" of the chassis. With the back panel removed, the unit feels a lot more "floppy".

image

Behold - the rather spacious insides of the 17" model. I suspect the 15" model is slightly more cramped by comparison.The two blower fans and the heat-pipe cooling solution can be seen. It seems the paint on some of these pipes have been scuffed - perhaps during assembly. That's a bit "average".

It is here that we can see the answer to 's question on the last post - the battery itself looks very much user replaceable. The battery has a plastic frame that is held in place with screws around all sides. It is cabled into the mainboard with a single connector - in fact, it could have been made user-replaceable if they had bothered to design the case in such a way to allow it, but perhaps the weight penalties would not be appreciated by the users.

image

Upgradeability for storage is quite good. There is a 2.5" drive cage for an SSD or HDD, with the plastic caddy taped to the frame holding the screws necessary to mount the drive. But if SATA is not your flavour (and it isn't mine anymore), you can also convert this to an M.2 storage slot. It's an either-or situation though ...

image

To do this, you will need to remove the cage entirely, and unclip the flexible flat cable ribbon connecting the SATA connection on the cage.

image

Then, it is a case of unscrewing the metal retainer part from the chassis (just below the motherboard) and then sliding it into one of the hooked detents. This provides the support for the other end of the M.2 card. I found this arrangement to be a bit flimsy but it seems the SSD is retained well enough even though it's not a PCB-crushingly firm hold like you might find on a desktop computer motherboard. This arrangement should accommodate both 2242 and 2280 SSDs, although as for clearance for drives with a heatsink, I am not sure ... so I opted for a drive without. I don't believe the chipset supports PCIe 4.0 and I wasn't going to spare the money for it anyway, so I opted for a cheap 2TB M.2 from PNY's XLR8 range which is fast-enough while being decent value for money. As a plus, it was in-stock for immediate dispatch.

.image

Upgrading the RAM is a little more complicated than the average, as the RAM is hidden under a shielding box. This box can be removed just by prying it upwards, as it is secured by "springy contacts" on all sides.

image

The unit comes with two 8GB Samsung DDR4 3200MHz sticks for a total of 16GB. While this is probably ample for most ordinary users and the two sticks provide for optimal dual-channel performance, this was not enough for my liking. Had this been 16GB in one module, I might have had an impetus to save it by adding another 16GB module for 32GB. But this was also a regular CL22 module, so I decided to splurge all-out for Kingston Fury Impact 2x32GB 3200MHz CL20 sticks instead - I just hope that they're compatible in the end as it wasn't cheap, but they're coming all the way from the UK as that was cheaper than buying it locally.

image

Finally, the copper heatspreader hides the final potentially-upgradeable parts ...

image

Underneath the heatspreader is the Intel 802.11ax two-stream wireless card, along with the Western Digital 1TB SN730 NVMe SSD as supplied. A key benefit of this slot is the heatspreader which would help with the thermals and allow for continued high-workload operation. I decided not to change the configuration as I was happy enough with the SN730 as the boot drive.

As I tend to check all my hardware prior to commissioning to avoid failures in-use, I decided to run the standard suite of benchmarks for the SN730 even though it was the boot drive. Unfortunately, it does mean the results are perhaps lower than for a non-boot drive and full-write benchmarks cannot be done, but it will stress the drive a little to see if it's any good.

image image

Sequential reads top-out at about 3GB/s which is pretty much expected from a PCIe 3.0 x4 drive. The IOPS are perhaps affected by the benchmark software and queue depth - perhaps it's not fast enough to reach the full performance but it easily leaves SATA SSDs in the dust.

image

CrystalDiskMark is another trustworthy benchmark - it seems to report slightly higher numbers, albeit as it is testing using a 1GB size file, it probably will reflect the pSLC cache speeds of most drives. Still, a great result, but why not test using the real-world and peak mix profiles?

image image

The left results are "real-world" profile and the right is the "peak" profile - overall, the results show much higher IOPS figures which would be expected. The effect of having a 70/30 I/O mix is a slight reduction in performance - this is both realistic and a reflection of some of the weaknesses of some controllers which slow down significantly under mixed workloads.

image

The classic ATTO Disk Benchmark shows writes peaking at 128KB accesses and reads at 256KB accesses.

image image image

AS-SSD showed no compression-related effects on this drive.

image

Anvil Storage Utilities gave it a score that was miles ahead of the ~3000-4000 score of SATA SSDs.

image

Data integrity seemed okay as well ...

image

... although the way it reports temperature seems to make CrystalDiskInfo a bit unhappy. There is nothing to worry about ... although it is interesting to see this 1TB SSD is the full 1024GB rather than 1000GB or 960GB as is common on some lower-end devices.

For now, this concludes the coverage of the Lenovo Legion 5 laptop as I wait for the RAM to arrive, then it'll be time to set-up the myriad of software that I use (which will probably take quite a few months to get it just the way I like it). Hopefully you enjoyed taking a peek "inside" the prize, but that's not all. I'll be bringing another "happy" post to the blog as another prize also turned up ...

Parents

  • It's crazy that we're starting to need to heatsink our storage. How're laptops going to cope? They're already embedding nVidia GeForce 30 series chips that are thermally throttling because they get too hot too quickly, and CPUs not able to reach their peak speeds.

    And I'm sure we can't find something like this on a laptop SSD:
    image

    I fear we'll move towards remote access and subscriptions for processing being more common.

  • in reply to cstanton

    Throttling is a way of coping ... it's an understanding that the thermal constraints prevent full utilisation of the silicon. It is exactly the reason why many CPUs now have "boost" when one core is heavily loaded and the others are not, and why GPUs throttle back - sometimes due to heat but other times due to power availability. It allows for configurable TDPs to meet the "limits" of certain cooling solutions, and SSDs already do this for the most part.

    It might not be so nice to hear that your performance is being capped because of overheating ... but it's preferable to not having the peak performance for "spiky" workloads and it's preferable to hardware damage.

    I do some remote access work and in general, I am not a big fan of it. When you work with large datasets, or complex graphics, the latency and bandwidth limitations of connectivity really make remote work a poor choice. Similarly, when you are working with real hardware, often you need a direct connection between the software and hardware - virtualised USB over network is just painful.

    - Gough

  • in reply to Gough Lui

    "When you work with large datasets, or complex graphics, the latency and bandwidth limitations of connectivity really make remote work a poor choice. Similarly, when you are working with real hardware, often you need a direct connection between the software and hardware - virtualised USB over network is just painful."

    We're certainly not there yet with the remote access tech'.

    We're getting there, if you've ever used valve's 'steam remote play' and streamed your desktop, the capturing of the environment to a MP4 video stream works a lot better than most remote desktop protocols, X11 forwarding isn't quite there either but allows for some leniency with how the windows are handled and the data is transferred to/from. 

    I would've expected more now with WebGL and hardware acceleration, and why when we have lag compensation for games, can it not do that with moving a window across the screen? Rendering limitations I would suspect. Software just isn't designed for partial information transfer (only transmitting what's important) over a network at the moment.

    Virtualised USB is indeed awful. Try doing a 5.1 surround sound USB DAC over the network :D 

  • in reply to cstanton

    "a MP4 video stream works a lot better than most remote desktop protocols"

    Yes, I suspect this is because Valve are basically using the hardware-accelerated encoding features of most modern GPUs to their full extent, which would be quite a bit snappier and less CPU-intensive than traditional screen capture using older VNC/RDP servers. The downside is that you still can't get away from issues of latency, compression artifacts and bandwidth consumption. It may work well in the home, but internet-based cloud gaming is still trying to find its feet - Google Stadia isn't exactly doing a roaring trade, although GeForce Now seems to be a bit more loved. Of course, many of the VNC codecs are actually bandwidth-optimised - they herald from a day when a thin client needed to work on a dial-up/ISDN line, but often this means a frame-rate and latency tradeoff for better compression. Many of them haven't had the benefits of predictive/bidirectional-frame compression like MPEG-series codecs have, topping out with MJPEG-like intra-frames only for ease of implementation. The best some of them have is to do certain graphic commands remotely (e.g. block-copy, cached off-screen areas).

    I think we can thank broadcast/streaming for introducing the world of RTP + MPEG4 transports which are somewhat loss-tolerant, latency-optimised. TCP always grinds to a halt (eventually) when packets get lost.

    X-forwarding often does work better than capturing the screen and sending differences, but some user interfaces are so elaborate and require so many graphics primitives to draw that it can be death by an overload of small commands that suffer from latency-overheads. I've seen it have good days on certain apps and trouble with others ...

    Unfortunately, living the LTE-quota-limited-life that I do, none of this is viable from a latency, bandwidth and price consideration.

    I guess I'll feel more and more like a dinosaur as I watch others go and enjoy their virtualised PCs ... while living with an actual box/laptop, with actual direct-attached storage ...

    - Gough

Comment
  • in reply to cstanton

    "a MP4 video stream works a lot better than most remote desktop protocols"

    Yes, I suspect this is because Valve are basically using the hardware-accelerated encoding features of most modern GPUs to their full extent, which would be quite a bit snappier and less CPU-intensive than traditional screen capture using older VNC/RDP servers. The downside is that you still can't get away from issues of latency, compression artifacts and bandwidth consumption. It may work well in the home, but internet-based cloud gaming is still trying to find its feet - Google Stadia isn't exactly doing a roaring trade, although GeForce Now seems to be a bit more loved. Of course, many of the VNC codecs are actually bandwidth-optimised - they herald from a day when a thin client needed to work on a dial-up/ISDN line, but often this means a frame-rate and latency tradeoff for better compression. Many of them haven't had the benefits of predictive/bidirectional-frame compression like MPEG-series codecs have, topping out with MJPEG-like intra-frames only for ease of implementation. The best some of them have is to do certain graphic commands remotely (e.g. block-copy, cached off-screen areas).

    I think we can thank broadcast/streaming for introducing the world of RTP + MPEG4 transports which are somewhat loss-tolerant, latency-optimised. TCP always grinds to a halt (eventually) when packets get lost.

    X-forwarding often does work better than capturing the screen and sending differences, but some user interfaces are so elaborate and require so many graphics primitives to draw that it can be death by an overload of small commands that suffer from latency-overheads. I've seen it have good days on certain apps and trouble with others ...

    Unfortunately, living the LTE-quota-limited-life that I do, none of this is viable from a latency, bandwidth and price consideration.

    I guess I'll feel more and more like a dinosaur as I watch others go and enjoy their virtualised PCs ... while living with an actual box/laptop, with actual direct-attached storage ...

    - Gough

Children
No Data