Aaron44126

The bracket will just have a hole where the screw goes, but it won't help affixing your panel to the chassis unless the chassis itself also has a place for the screw to go in.

Most panels that mount with screws have such brackets on them (the panel itself doesn't have the screw holes); whether it will be compatible with your lid depends on if there are "receptors" for the screws in the right place. (I have pulled panels for Precision 7510, 7530, and 7560 that were all mounted in such a way which is why I was surprised to find that Precision 7540 uses adhesive for the panel.)

This is just accumulated knowledge from this site and also NBR. However, especially if you have done laptop GPU replacements before, you can just look at those DGFF cards and see that there is no way that the Alienware card will work in the Precision. The screws don't go in the same spots. There are no HDMI or DP ports. The shape and size are different (especially accounting for how you'd have to rotate that Alienware card to get the DGFF connectors in the same place). It simply will not fit.

The fans are slightly different sizes and have different enclosures, but the blade design is the same if you have fans from the same manufacturer. If you find a Delta CPU fan beneficial then you'd probably want a Delta GPU fan as well. The system runs the fans at roughly the same speed anyway. (I.e., a load on the CPU only will cause both the CPU and GPU fans to ramp up.)

There is at least this in post #6. Higher CFM will be beneficial as well if you care about noise. The fan can get the same work done at lower speed. Now I changed my cpu fan from the AVC #2 to the Delta fan #3, not only is the fan quieter but also a lot more powerful. The AVC fan ramped its speed to max making a horrible noise while the Delta fan roars off but still has plenty more to give if you manually control the fan speed and if you put your hand in front of the outlet grill you can already feel a hard air flow while the AVC barely tickled your face on full speed.

For information on the types of fans available, see this thread and posts by @unnoticed. Delta fan is generally preferred. It is normal for the CPU to run hotter than the GPU with the same wattage. The CPU is harder to keep cool because it concentrates power in tiny "hot spots" where the CPU cores are (a relatively small portion of the die as a whole), while the GPU distributes power use more-or-less across the entire die. (GPU dies tend to be bigger than CPU dies anyway.)

There is no compatibility between Precision and Alienware DGFF cards. In fact, there is no compatibility between Precision DGFF cards between models with different chassis designs either. The card shape and component layout are completely different even if the connector is the same. The only inter-generational upgrade that has been confirmed to work is using Precision 7X40 cards in a Precision 7X30 system.

The provided AC adapter for the Precision 7680 is not USB-C, it is the standard Dell "barrel"-style power connector and it plugs into the left side. If you don't mind connecting two cables, you are free to connect the stock AC adapter to the system and use a dock at the same time. When you do so, you do not need to rely on power from the dock. You can connect a single-cable dock like WD22TB, or just one of the connectors for the WD19DCS, and the system will still run fine. You only need to connect both of the WD19DCS connectors if you want "single-cable docking" (no standalone AC adapter connected). .....Do note that connecting only one of the WD19DCS connectors might also cause issues if you plan on using a high-bandwidth display setup (i.e. multiple 4K displays). A Thunderbolt dock like the WD22TB should be able to handle this over a single cable, though.

This sort of issue popped up semi-regularly on NBR back when these systems were "old enough to have GPU replacements done" but not yet "really old" (2015-2018 timeframe?). There isn't a whole lot of discussion of the pre-7000 series systems here on NBT.

This is a common problem with an "unsupported GPU" in this system. You should be able to set the brightness level in the BIOS. If you're running with Optimus / graphics switching turned on, it should work but you might have to use the Intel GPU driver package from Dell, not the one built-in to Windows or from Intel's web site. If you're running with Optimus / graphics switching turned off, I don't know if there is really a solution to this. 😕

I have not had this problem on my system since I disabled “c states for discrete GPU” and also enabled “Intel maximum turbo boost 3.0”, which supposedly disables NVIDIA Dynamic Boost 2.0.

Dell has made 330W power adapters for Alienware systems and you can plug one into these systems and it will work… but not provide any performance uplift. (At least, that was the case with Precision 7770.) You can provide feedback but I don’t think Dell wants to push the power envelope higher on these systems. It would require larger size for a bigger cooling system as well — and they have been trying to *shrink* the chassis with each successive generation. In any case, Dell is aware of feedback happening on this site, but they are also aware that the power users that typically visit here don’t represent the majority of Dell’s business customers. (We are due for a chassis refresh next year, and with 18” 16:10 systems starting to become normal to see, I’m hoping we will at least see that…)

This is normal and has been for the past several generations. If you check in NVIDIA control panel "Help->System Information" you will probably see that the power limit is the same between the 4000 and 5000 cards. Performance could be better with the 5000 GPU if you are doing something to take advantage of its extra capabilities (more vRAM, more tensor cores, ...), but otherwise there is no reason to expect it to be much "faster" than the 4000 GPU.

5480 and 5680 are now available for order in the US. https://www.dell.com/en-us/shop/workstations-isv-certified/precision-5480-workstation/spd/precision-14-5480-laptop https://www.dell.com/en-us/shop/workstations-isv-certified/precision-5680-workstation/spd/precision-16-5680-laptop

Dell Precision 5480 and 5680 support pages are up, so those systems are presumably launching soon. https://www.dell.com/support/home/en-us/product-support/product/precision-14-5480-laptop https://www.dell.com/support/home/en-us/product-support/product/precision-16-5680-laptop

(@Ionising_Radiation) I just realized that Dolphin has a more robust "bookmarks" system that is entirely separate from "places" left bar thing that you can pin things to. It's just sort of hidden away by default. To access it you have to manually configure toolbars and add the "Bookmarks" button. From there you can easily add folders to the bookmarks list (Ctrl+B), and using the "Edit bookmarks" function you can sort them how you like, group them into folders, and even add custom icons. And if you have a folder full of bookmarks, it will let you open them as a set of tabs all at once.

That is not too bad a price as far as new motherboards with a high-end CPU go. Only you can decide if it is "worth it". Motherboard replacement is not a difficult job (if you're already comfortable with a repaste), just a time-consuming one. I replaced the motherboard in my Precision M6700 once and it took me an hour or so. Just follow the steps in the service manual and set up something to keep your screws organized.

Sounds good, then just a matter of finding the motherboard that you want for a not-killer price ...! Of course Dell has the full replacement steps in the service manual and you'll be repasting as well, but it sounds like you're comfortable with that (I see that you've actually done it in this system already).

AFAIK, the only differentiating factor between the different mobo versions is the CPU, so if you drop in a different motherboard everything should "just work". Minor concerns I can think of: Intel vPro may or may not be enabled on your new mobo. There is a one-time process to set up vPro which is done the first time that the motherboard is powered up (typically at the factory, but I've seen techs do it after a motherboard replacement). Probably, you don't use or need vPro, so this doesn't matter. The system service tag will change. The Windows product key is "burned in" to the BIOS, so you might have to jump through hoops to reactivate Windows if you're using the stock OEM install. (You can pull your current Windows product key with ProduKey. Note on antivirus false positives.) One more thing: If your workload is already multi-threaded, you might find that going from six cores to eight cores doesn't help as much as you'd think. You should check and see what your CPU power usage is like and if you are power throttling. The 6-core and 8-core CPUs probably have the same power limit, so if you are already hitting that regularly, then you will find that going from six to eight cores means more threads running but each at a lower speed, so about the same amount of work being done overall in the end. This would be because the system has to spread the same amount of power across more cores, so they can't run as fast. Running at a lower speed is more power-efficient, so there would be a modest performance improvement from adding cores, but we're talking about something in the range of 5% and not like 33%. (If your workload is not multi-threaded then this upgrade probably won't help at all.)

All good. Min quantum 512 still resulted in some dropouts but 1024 seems completely fine. (Can't tell that anything is off from an audio latency test.) No GPU power limit hiccups either, for the third day in a row. Maybe this is finally going to start working properly...

So, PipeWire was originally started as a project to handle video streams, but they added audio support later on. It's not just Ubuntu that is switching to use PipeWire as the default audio server, in fact Ubuntu is sort of late to the party. Ubuntu switched with version 22.10 (October 2022), but Pop!OS switched at version 22.04 (April 2022) and Fedora switched at version 34 (April 2021). It looks like they're trying to unify use cases for PulseAudio and JACK and generally fix some other architectural issues around audio with this transition. In fact, PipeWire supports to protocols/APIs used by ALSA, PulseAudio, JACK, and GStreamer, so it can be used by applications that support any of those without applications specifically needing to add support for PipeWire. Also, PipeWire supposedly addresses some issues with audio over Bluetooth that have plagued PulseAudio, and is also lighter in terms of CPU use. (When I originally tried Linux as a full-time OS back in 2008, I think that the process to move from ALSA to PulseAudio was just getting underway, so funny to see that PulseAudio is now being phased out right when I switch over again...) So, if that is clearly the way that things are going, I am going to start with trying to use PipeWire instead of PulseAudio and find a way to fix the audio drop-out issue. This guy seems to have run into the same issue and the solution appears to have been to change the value for "default.clock.min-quantum" to 1024. The default value is 16, so that's a big jump. I found other threads reporting stuttering issues and messing with the "quantum" setting seems to be a common recommendation. In fact, I found a note here on the Debian wiki specifically saying that because PipeWire has lower latency that PulseAudio by default, it can be "choppy" on systems with a high CPU load, and they also recommend increasing the quantum value. My system doesn't seem to have any sort of PipeWire config file in /etc/pipewire or ~/.config/pipewire, so I can only assume that it is using the default values for everything. I take it back, I found the config files in /usr/share/pipewire. It did have the "min-quantum" value explicitly set to 16. This command will return the current value for min-quantum: pw-metadata -n settings 0 clock.min-quantum You can change the value on the fly with: pw-metadata -n settings 0 clock.min-quantum (value) This page describes how to set up a split-file configuration so that you can adjust your own values and not worry about them conflicting with the config files that the packages wrote out, when the packages are updated later on. You can also run pw-top and it will give you a tool that shows details of connected PipeWire clients, including what the "min-quantum" value is currently. With Firefox as the only client it is reporting a quantum of 512, but if I fire up yuzu (game emulator) it appears to want to lower the quantum to 256. The config is pretty robust, you can set up rules for specific applications. ArchWiki has an example for Discord. What is the quantum, anyway? It's basically the buffer window, and thus audio latency? Best I understand it, it's the scheduling period for drivers and impacts how long applications have to fill in the audio buffer before a dropout will occur. To measure the window, you have to divide the quantum by the playback rate. On my system, PipeWire is reporting that the playback rate is 48,000 Hz, so yuzu's observed quantum of 256 means 256/48000 = 5.3ms of latency (and also a 5.3ms buffer window). The "min-quantum" of 16 means an absurd 0.3ms. ...Since I generally play at 60 FPS, frame times are 16.7 ms, so audio latency of up to around 30 ms or so is totally fine (I'm not going to be able to tell if a sound comes one frame late) and I don't mind raising the min-quantum to 1024 (21.3ms). For reference... What's latency like with PulseAudio? I'm not running it right now so I cannot easily check myself, but I found this blog post where the guy reported latency of 100ms with default values (includes commands to measure it and configuration to lower it). This bug report also mentions 100ms as the default latency. 100ms seems really high to me?? But, if that is right, it totally makes sense that if my setup used to allow for 100ms of latency and now it was pushed down to 5ms then maybe there will be issues with audio buffer underruns that were not there before. The plan for me is, I will see if just forcing PipeWire processes to run on P cores helped, and if not, I will try min-quantum = 512 and see if that helps, and if not, double it until it is good. This big post is sort of me just unpacking this as I figured it out myself, but maybe it will help someone else down the line!

Yeah, I generally agree, so I need to spend some time figuring out what the motivation and supposed benefits of the switch are here before I decide if I'm just going to just switch back to PulseAudio, which seems like it would be the easiest thing to do, or if I am going to try to make PipeWire work. I have heard about PipeWire in the context of something that exists to help with the transition to Wayland (...which I am all for, I get the benefit of Wayland, even though I am not using it yet...). I know for example that it can help screen sharing apps (i.e. virtual meeting apps, Zoom/WebEx/etc.) that are written for X11 to work under Wayland. I do not know why there is an audio component to it though. I didn't even know that there was until I ran into this issue. The Reddit post I linked above has a potential solution (adjust the "default.clock.min-quantum" value in PipeWire). Similarly, I don't want to go and make that change without first understanding what that value even does. So. Investigation to follow, when I have time. I'll post what I find out back here.

...Ran into audio stuttering for the first time when gaming after upgrading to Ubuntu 22.10. Maybe "audio dropouts" would be a better way to describe it. Come to find out, they have switched the default audio server from PulseAudio to PipeWire. I had previously added some scripting to make sure that the PulseAudio server runs on P cores only, so I guess I'll do the same for PipeWire, but if that doesn't fix it then I guess I can just switch back to PulseAudio and see if that fixes it. (Sort of a shame because the GPU / power throttling has not been an issue at all over the past two days, likely because of the BIOS settings changes I made on Friday? Fix one thing and now have something new to figure out.) [Edit] Looks like maybe it's not just me.

Confirmed, no S3 sleep in Precision 7560 or Precision 7770 here. Attempts to force it back on have not been successful. (You can edit BIOS variables and Windows will show it as an option, but it still won't work right.)

Well. Decided to go current with KDE Plasma, rather than sitting on version 5.24 which is what Ubuntu has in their current LTS repo, so I went ahead and upgraded to (K)Ubuntu 22.10 and pulled Plasma 5.27 from the Kubuntu backports PPA. (Well, it is Plasma 5.27.4, but they should have 5.27.5 shipped out any time now, it's already in the staging repo...) The upgrade was smooth and everything seems stable so far. I'll look to fully upgrade to (K)Ubuntu 23.04 in July around when 22.10 is going out of support. (I'm already using the 23.04 kernel packages...) I can already see some appreciable differences, for example, it starts "listening" for a fingerprint scan as soon as I touch anything on the lock screen. On 5.24, I had to hit the "enter" key to try to enter a blank password before it would initiate fingerprint scan.