I've been playing around with my new Lexar M.2 drive and while my results aren't by any means scientific, I thought they might still be of interest to others. All of these observations are specific to this one drive, on my PBP, running the default OS.
Lexar bills the drive as "ideal for smaller notebooks" and "an entry-level PCIe NVMe", and so far I think the description fits. The three active power options for the drive are:
PS 0: 3.05W
PS 1: 2.44W
PS 2: 2.02W
The full power state information returned by the drive to nvme-cli is:
When I try to change the power state using the -s switch per the instructions on the wiki, it doesn't throw an error but the new setting doesn't persist after a reboot:
However, there is a workaround for drives that won't save settings across reboots, using crontab.
Interestingly, I've found that if I set the drive to an inactive power state (PS 3 or 4), and then click on the drive to open it, Debian sets the power state to 1, instead of the otherwise default of 0. Also, regardless of what power state the drive is in when the laptop is put to sleep, Debian resets it to state 0 on wakeup.
I've toyed with the idea of setting a cron job to run every few minutes to reset the power state to 4, since I'm not currently using it as root and what I really want it for is fast (compared to an SD card) access to periodically needed data. My thought was that this would minimize the power draw the bulk of the time, and still give me fast access to the data when needed. However, while drive state 1 would be fine for my purposes, I'm not sure how much power this would really save while idle. Whatever the difference, it is too small for me to really measure (more on this below).
To get a better handle on how the drive performed in different scenarios, I wrote a simple loop to continuously read from the drive while reporting current power state, temperature (of the drive and CPU), and a rough estimate of read speed. I toyed around a bit with write speed as well, but didn't do as much sampling because SSDs are a consumable when it comes to writes. Here is the loop I ran in bash:
While the script was running I modified the power state of the drive as well as the PBP CPU power settings, and opened up the power statistics utility in the default Debian. While each test was running I waited as the screen dimmed and the power used "Rate" statistic continued to drop. Once "Rate" stopped going down I noted the total watts along with the other information in the tables below:
Under Read Load. CPU set to On Demand
Power State Drive Temp CPU Temp Total Watts Read MB/S low Read MB/S high
0 51 55 6.3 613 631
1 49 49 5.4 488 499
2 50 48 5.0 363 370
Under Read Load. CPU set to 1.99 Ghz
Power State Drive Temp CPU Temp Total Watts Read MB/S low Read MB/S high
0 51 57 6.7 631 650
1 50 54 6.0 511 na
2 50 53 5.9 397 na
I included the two temp readings since changes in temp give a rough indication of changes in energy use. However, the absolute values vary by the ambient temperature when I did the test, so I generally wouldn't compare these figures across tables (but they should have some value within each table). The two tables above make some intuitive sense, but my results when I set the cpu to 408 Mhz. For some reason, throttling the CPU this way causes the normally slower power state of 1 to be faster than power state 0. I ran this several times on different days, and every time I ran this the same pattern emerged:
Under Read Load. CPU set to 408 Mhz
Power State Drive Temp CPU Temp Total Watts Read MB/S low Read MB/S high
0 49 44 4.5 311 346
1 49 43 4.8 376 390
2 48 42 4.4 278 290
I have no idea what to make of that.
I also wanted to try to capture a difference between power consumption of the various power states at idle (not reading or writing). There may well be a difference, but it wasn't something I could really capture. Since I couldn't reliably capture a difference between the highest draw power states and the lowest draw ones, I ended up not filling in the chart with the missing states (PS 2 & PS 3). Since the power draw figure reported tends to oscillate by a tenth of a Watt, I captured both the lower and higher observations for each state (in one sitting). I thought I had found a slightly lower power draw for PS4 at one point, but then I ran the test again and it came back the same as the others (this is why I have PS 4 listed twice below):
Idle. CPU set to On Demand
Power State Low Watts High Watts
0 3.5 3.6
1 3.5 3.6
4 3.4 3.5
4 3.5 3.6
The above was with a nearly fully charged battery. When I did the same test with around an 85% charge the Wattage for all of the states I tested came back as 4.0. I'm not sure if the battery charge was indeed the issue, or something else was up with the machine at that particular moment.
I don't have a final conclusion at this point, but for now it seems to me that setting the power state for this particular drive isn't that important, at least based on my current use model. Setting the power mode of the CPU seems to manage power consumption of the drive at the same time. However, others here might have a clearer understanding of what is going on here.
I'll also note that pricing and availability of variants of this drive seem to be all over the map. When I first started looking at it I planned on buying the 128 GB variant for just over $30 on Amazon. Then that model went out of stock so I moved up to the 256GB model for $50. Shortly after I ordered the larger drive, it too went out of stock, only to come back a week or so later for $100, which at the time was the same price as the 512 GB variant. Now the 256 GB drive is back down to $50 on Amazon, but with expected shipping of 1-3 months, and the 512 GB variant is now $140.
If you can find one for a good price I think it is an excellent fit for the PBP, given both the size and power constraints. I've attached a picture of the drive in my PBP after I trimmed the adapter. Note that it looks like a 60mm drive would fit as well. Since I took that photo I've added a 1.5 mm thick strip of thermal pad between the drive and the bottom of the case, which seems to be a perfect fit.
trackpad_clearance.jpg (Size: 71.4 KB / Downloads: 2,872)
Lexar bills the drive as "ideal for smaller notebooks" and "an entry-level PCIe NVMe", and so far I think the description fits. The three active power options for the drive are:
PS 0: 3.05W
PS 1: 2.44W
PS 2: 2.02W
The full power state information returned by the drive to nvme-cli is:
Quote:ps 0 : mp:3.05W operational enlat:0 exlat:0 rrt:0 rrl:0
rwt:0 rwl:0 idle_power:- active_power:-
ps 1 : mp:2.44W operational enlat:10 exlat:10 rrt:1 rrl:1
rwt:1 rwl:1 idle_power:- active_power:-
ps 2 : mp:2.02W operational enlat:10 exlat:10 rrt:2 rrl:2
rwt:2 rwl:2 idle_power:- active_power:-
ps 3 : mp:0.5704W non-operational enlat:300 exlat:800 rrt:3 rrl:3
rwt:3 rwl:3 idle_power:- active_power:-
ps 4 : mp:0.0054W non-operational enlat:1800 exlat:3700 rrt:4 rrl:4
rwt:4 rwl:4 idle_power:- active_power:-
When I try to change the power state using the -s switch per the instructions on the wiki, it doesn't throw an error but the new setting doesn't persist after a reboot:
Code:
sudo nvme set-feature /dev/nvme0 -f 2 -v 2 -sHowever, there is a workaround for drives that won't save settings across reboots, using crontab.
Interestingly, I've found that if I set the drive to an inactive power state (PS 3 or 4), and then click on the drive to open it, Debian sets the power state to 1, instead of the otherwise default of 0. Also, regardless of what power state the drive is in when the laptop is put to sleep, Debian resets it to state 0 on wakeup.
I've toyed with the idea of setting a cron job to run every few minutes to reset the power state to 4, since I'm not currently using it as root and what I really want it for is fast (compared to an SD card) access to periodically needed data. My thought was that this would minimize the power draw the bulk of the time, and still give me fast access to the data when needed. However, while drive state 1 would be fine for my purposes, I'm not sure how much power this would really save while idle. Whatever the difference, it is too small for me to really measure (more on this below).
To get a better handle on how the drive performed in different scenarios, I wrote a simple loop to continuously read from the drive while reporting current power state, temperature (of the drive and CPU), and a rough estimate of read speed. I toyed around a bit with write speed as well, but didn't do as much sampling because SSDs are a consumable when it comes to writes. Here is the loop I ran in bash:
Code:
for i in {1..30}
do
date
tmpfilename="/home/rock/ssd/f3temp/10gb.tst"
echo "copying: " $tmpfilename " to the bitbucket."
echo; echo "Drive power state is:"
sudo nvme get-feature /dev/nvme0 -f 2
starttime=$SECONDS
cp $tmpfilename /dev/null
cp $tmpfilename /dev/null
endtime=$SECONDS
secondstocopy=$(($endtime-$starttime))
echo "Seconds to read 10GB file to bitbucket two times: " $secondstocopy
mbpersec=$((21474/$secondstocopy))
echo "Speed is " $mbpersec " MB per second."
echo; echo "Drive power state is:"
sudo nvme get-feature /dev/nvme0 -f 2
echo; echo "Drive temperature is:"
sudo nvme smart-log /dev/nvme0 | grep "temperature"
echo; echo "System temperature is:"
cat /sys/class/thermal/thermal_zone*/temp
echo; echo
doneWhile the script was running I modified the power state of the drive as well as the PBP CPU power settings, and opened up the power statistics utility in the default Debian. While each test was running I waited as the screen dimmed and the power used "Rate" statistic continued to drop. Once "Rate" stopped going down I noted the total watts along with the other information in the tables below:
Under Read Load. CPU set to On Demand
Power State Drive Temp CPU Temp Total Watts Read MB/S low Read MB/S high
0 51 55 6.3 613 631
1 49 49 5.4 488 499
2 50 48 5.0 363 370
Under Read Load. CPU set to 1.99 Ghz
Power State Drive Temp CPU Temp Total Watts Read MB/S low Read MB/S high
0 51 57 6.7 631 650
1 50 54 6.0 511 na
2 50 53 5.9 397 na
I included the two temp readings since changes in temp give a rough indication of changes in energy use. However, the absolute values vary by the ambient temperature when I did the test, so I generally wouldn't compare these figures across tables (but they should have some value within each table). The two tables above make some intuitive sense, but my results when I set the cpu to 408 Mhz. For some reason, throttling the CPU this way causes the normally slower power state of 1 to be faster than power state 0. I ran this several times on different days, and every time I ran this the same pattern emerged:
Under Read Load. CPU set to 408 Mhz
Power State Drive Temp CPU Temp Total Watts Read MB/S low Read MB/S high
0 49 44 4.5 311 346
1 49 43 4.8 376 390
2 48 42 4.4 278 290
I have no idea what to make of that.
I also wanted to try to capture a difference between power consumption of the various power states at idle (not reading or writing). There may well be a difference, but it wasn't something I could really capture. Since I couldn't reliably capture a difference between the highest draw power states and the lowest draw ones, I ended up not filling in the chart with the missing states (PS 2 & PS 3). Since the power draw figure reported tends to oscillate by a tenth of a Watt, I captured both the lower and higher observations for each state (in one sitting). I thought I had found a slightly lower power draw for PS4 at one point, but then I ran the test again and it came back the same as the others (this is why I have PS 4 listed twice below):
Idle. CPU set to On Demand
Power State Low Watts High Watts
0 3.5 3.6
1 3.5 3.6
4 3.4 3.5
4 3.5 3.6
The above was with a nearly fully charged battery. When I did the same test with around an 85% charge the Wattage for all of the states I tested came back as 4.0. I'm not sure if the battery charge was indeed the issue, or something else was up with the machine at that particular moment.
I don't have a final conclusion at this point, but for now it seems to me that setting the power state for this particular drive isn't that important, at least based on my current use model. Setting the power mode of the CPU seems to manage power consumption of the drive at the same time. However, others here might have a clearer understanding of what is going on here.
I'll also note that pricing and availability of variants of this drive seem to be all over the map. When I first started looking at it I planned on buying the 128 GB variant for just over $30 on Amazon. Then that model went out of stock so I moved up to the 256GB model for $50. Shortly after I ordered the larger drive, it too went out of stock, only to come back a week or so later for $100, which at the time was the same price as the 512 GB variant. Now the 256 GB drive is back down to $50 on Amazon, but with expected shipping of 1-3 months, and the 512 GB variant is now $140.
If you can find one for a good price I think it is an excellent fit for the PBP, given both the size and power constraints. I've attached a picture of the drive in my PBP after I trimmed the adapter. Note that it looks like a 60mm drive would fit as well. Since I took that photo I've added a 1.5 mm thick strip of thermal pad between the drive and the bottom of the case, which seems to be a perfect fit.
trackpad_clearance.jpg (Size: 71.4 KB / Downloads: 2,872)
