You'd think with this much computer I would have actually decent framerates. Windows 10, Build 1607 (1709 is way worse for "hitching") Threadripper 1950X 32GB of DDR 4-3200mhz Quad Channel GTX 1070 Few settings: Minimum Texture Quality Balanced Memory Mode All lighting turned off No shadow no LOD No post effects particle effects are 5% me+NPC Game is installed on an SSD Windowed mode 2400x972 resolution
For as many threads as your CPU supports have a CPUAffinity*=-1 line for them in your eqclient.ini For example: eqclient.ini *********************** [Defaults] CPUAffinity0=-1 CPUAffinity1=-1 CPUAffinity2=-1 CPUAffinity3=-1 .... BTW, Windows 10, Build 1709 - no hitching. AMD FX-8350 16GB of DDR3-1866MHz GTX 970 See this thread for more ideas.
AMD CPUs have always had a interesting history with EQ namely the superspeed effect. A quick google search of"AMD and Everquest" brings up some reddit posts that suggest setting your CPU affinity like the previous poster suggested. https://www.reddit.com/r/everquest/comments/6m16z4/amd_ryzen_everquest/
Just curious, do you get low framerates and hitching when running Full Screen Mode? I think you can probably max out your graphics settings. That's not the cause of your low framerates. You have plenty of horsepower. There's something else at play here. It almost sounds to me like the CPU is attempting to render the frames and the GPU is simply displaying them. Did you happen to copy this install of EQ from a different/old machine? If so, go into the EQ folder and run the EQDisplay.exe (i think that's the name of it, going off memory here) so EQ knows what device it's supposed to be rendering with.
I'll answer each post in order. Note, I do not have hitching anymore since I re-installed Build 1607 and blocked feature updates to 1709. However the lag is still there. I use fraps to test my FPS. For as many threads as your CPU supports have a CPUAffinity*=-1 line for them in your eqclient.ini: Yes already had that set. I use software called ParkControl to watch my CPU usage and to shutdown cores when not needed. While running CPU2 (real core not a smt core) is nearly maxed while the other 15 (i have turned off all SMT cores) are near 0% usage (windows 10 will actually turn them off on its own. with Park control i can tell all to stay on). I can go to the guild lobby turn all names on and not move and end up in single digit fps and core 2 will MAX out at 100% again, rest of the cores are near 0% usage. Even when I ran an i7-4790k overclocked to 4.5ghz the framerates were dismal. Just curious, do you get low framerates and hitching when running Full Screen Mode? Yes, no change to low framerates. Hitching was fixed by "downgrading" to build 1607 and getting away from the fall creator update. Did you happen to copy this install of EQ from a different/old machine? If so, go into the EQ folder and run the EQDisplay.exe (i think that's the name of it, going off memory here) so EQ knows what device it's supposed to be rendering with. At one point it was a copy, however about a month ago I reinstalled EQ from scratch and it did not really seem to improve the situation. Definitely open to more suggestions. I have run 3dMark on the system to make sure the video card/cpu get within normal results and it does so I know the video card is working correctly in that instance.
Have you tried disabling ParkControl to ensure it's not having any unforeseen effects? Make sure in Nvidia Control Panel > 3D Setting > Manage 3D settings Program Settings tab setup eqgame.exe as a program then find Power management mode set it to Prefer Maximum Performance. Also, Start>Run>powercfg.cpl set it to High Performance.
Have you tried disabling ParkControl to ensure it's not having any unforeseen effects? Parkcontrol was disabled on Tues raid, enabled last night and enabled again tonight. No change. It is really nothing more than a gui to affect windows 10 built in core parking function Make sure in Nvidia Control Panel > 3D Setting > Manage 3D settings Program Settings tab setup eqgame.exe as a program then find Power management mode set it to Prefer Maximum Performance. Been that way since I installed windows because if not my GTX1070 wont event clock all the way up to 1594 (and it doesn't even boost to 2000mhz) Also, Start>Run>powercfg.cpl set it to High Performance. Already set there. With core parking its really nothing anyways as core parking takes C-states to another level and completely shuts the core down vs downclocking. It's inherent to the Ryzen architecture and newer Intel cpus. For example my cpu is overclocked to 4050mhz full time it never clocks down but the power usage is the same as Win10 shuts off the core until needed. Park control forces them to all stay on.
Try pulling back Max. Frames Per Second, Actor Clip Plane, and Far Clip Plane until you find something you can live with. Also make sure Allow hw Vertex Shaders and Allow 2.0 Pixel Shaders are on. Otherwise the CPU will handle that, and we want the GPU to do so. Window Transparency set to anything less than 100% supposedly will slow things down as well.
I run a very old AlienWare M14x R2 from 2012. It runs both my clients flawlessly. Whatever they changed in the recent patch has done wonders for my own ability to play. EverQuest doesn't care what video card you have. It's too old of an engine to take advantage. The better CPU you have the better it plays.
You still need to tell the game client which card is supposed to be doing the rendering. Especially if the game files were transplanted from a different install.
Do you have logging turned on? If you do, turn it off and see if you still have the problem. If turning logging off solves your problem, then turn it back on and type "/loginterval 1" without the quotes. That will fix it, provided the issue is logging.
On a related note, I used to have big issues with low FPS on raids whenever I had logging on. At the time, I still had some leftover in game ATs setup from long ago, but they were still there. Deleting all of those fixed it. Odd, but maybe whatever internal string searching EQ does with its own ATs isn't efficient. Of course, this was years ago, but maybe still relevant.
The specific issue I'm referring to is related to the way EQ defaults writing log files and the performance problems it can cause with SSDs. By default, EQ opens the log file, writes ONE line, then saves/closes the log file. It does this hundreds of times a second when there is a lot going on like in a raid. For a HDD this isn't really a problem. SSDs however are different and use wear leveling among other things. Basically, every time you save a file, it saves to a new location on the SSD, so that it doesn't continually write to the same spot and wear it out quickly. Now combine that with EQ saving the file after every line, and your SSD is saving to a new location hundreds or even a thousand times a second. This is compounded by a thing called "write amplification" which basically means SSDs have to write more data than you actually saved. The /loginterval command adjusts how EQ saves the logs. A value of 0 is the default and writes any changes in real time as they happen as I mentioned above. Changing that value to 1 tells EQ to only write to the log file every 1 second. So, instead of hundreds or thousands of writes a second, there is only 1 write each second. If you set the value to 5 (0-5 are the options) it will save to the log file once every 5 seconds. (Don't do this, I'll explain why). Be aware that you are literally delaying writes to the file. Thus, if you get an emote at 12:00:00 it will not write into your log file until 12:00:01. If you use a log file parser program such as GINA, this means your triggers will be delayed by that amount of time. If you have 10 seconds before you get DT'd, you will only have 9 seconds because the log file was delayed by 1 seconds. This is why you don't want to set loginterval to something like 5. If you delay writing to the log by 5 seconds, by the time GINA parsed it you would only have 5 seconds to cure your DT. This isn't exactly related to EQ, but it describes the issue: https://redislabs.com/ebook/part-2-...e-options/4-1-2-append-only-file-persistence/ Code: WARNING: SSDS AND appendfsync always [write every change] You’ll want to be careful if you’re using SSDs with appendfsync always [write every change]. Writing every change to disk as they happen, instead of letting the operating system group writes together as is the case with the other appendfsync options, has the potential to cause an extreme form of what is known as write amplification. By writing small amounts of data to the end of a file, you can reduce the lifetime of SSDs from years to just a few months in some cases. As a reasonable compromise between keeping data safe and keeping our write performance high, we can also set appendfsync everysec [write once per second]. This configuration will sync the append-only log once every second. For most common uses, we’ll likely not find significant performance penalties for syncing to disk every second Since the OP mentioned using an SSD, this could be his issue. That's why I suggested turning logs off first if they are on. If the problem persists when the log is off, then this isn't relevant to the problem.
Using my i7 3770k i found setting CPU affinity to specific cores worked better, and kept HT cores out of the possible usage. i run 2 clients so CPUAffinity=2 and 3 for my ini. also set performance to prefer max instead of the default adaptive. the settings within advanced video also checked to ensure HW is being used and not software render via allow hardware vertex shaders and pixel shaders. drivers also have a large impact on preformance (video). i have also found deleting/renaming my eqclient.ini and repatching has helped when fps slow to a crawl on some machines with a UI reset if all of the above failed to remedy.
I also use gina and gamparse (I run the "official raid parse"). I have downloaded AMDs ramdisk software and setup a 4gb ramdisk and offloaded my log file to that. Will see how it does at tomorrow night's raid.. Ive debated picking up an AMD card (RX580) or trying my RX560 out as well to see if it is an Nvidia issue.
Well, first off, did you try just turning logs off and see if that stopped the slowdown? If it didn't do anything then there is no reason to mess with your logs. What exactly do you mean by "offloaded my log file to that" ? As far as I'm aware you can't adjust where EQ saves log files. You would have to mount the ramdisk as your eq log folder, (or put all of EQ on the ramdisk, but that requires more than 4GB). I hope you didn't mean you just moved the log file to it because that won't do anything...
Using a Junction works quite well for changing the disk that eq logs to. I have EQ installed to my SSD, but log to a regular mechanical drive. Didn't want all the writes beating up an SSD.
My SSD is nowhere near modern, and I log several characters on the same machine, same SSD. I have never experienced any difference with logs on or off during raids. Must be an AMD thing.... (I'm on the blue team).
This is a clever solution. However, I think it's probably unnecessary. Even second and third-gen consumer SSDs have read/write cycle capability in the billions before data degradation occurs. If you have any sort of modern, name-brand SSD the drive and the data stored on it will far outlast the hardware running it regardless what you're tasking it with.
