Good to see it. The SqlData Servers on SSD NVME hardware is a big leap forward and its 4TB DDR4 RAM especially.
Maybe it’s a reason why you are specifically using the Intel architecture, like a historic background. It’s not clear why you decided to upgrade your machines to 3rd Gen Gold 6334 in 2022, which is a 10 nm Tech! The CPU has high base frequency, but not so many cores and relatively low cache especially. I don’t have the data and maybe there is a reason why this CPU. In my opinion a good CPU for EVE nodes isn’t one with many cores but one with highest base frequency and biggest cache. And here’s a problem, this architecture isn’t scalable for the future tech generation. The Gold 6334 CPU can run on a socket FCLGA4189 and supports max DDR4-3200. Therefore, the next hardware upgrade needs the entire new server machine.
For example, the 4th Gen Gold 6444Y (cost on $1000 more) has Intel7 or 7 nm Tech architecture and higher frequency of course, two times more cores and cache (45 MB). It runs on socket FCLGA4677. What is much more important, this CPU architecture supports DDR5-4400! Based on the latest news, in Q4 2023 we can see the first DDR5 server DIMMs and 95% of the IT industry will completely switch to DDR5 by 2025-2026. Experts say that DDR5 will double the performance of DDR4, because current CPU cores frequently idling while transferring data to RAM. The DDR5 is supposed to be expensive. It’s not a bad idea to run “Rank-and-File” machines on 4th Gen Gold cores with DDR4 and slowly switch to DDR5 by 2025. That hardware foundation will serve for many years, I don’t know, until 2030.
[update] There’s no a transitive memory support no matter that’s the same Intel Optane memory tech. I see. Well, upgrade will be expensive…
DDR5 is also not backwards compatible with DDR4 and has a new physical design. Whilst the memory is still in a 228-pin formfactor, DDR5’s layout of the pins is different so the DIMM’s cannot physically occupy the same type of slot as a DDR4 module. Firstly, the keying notch is slightly more centralised on the DDR5 module, although it is still not exactly in the middle. The other notable difference is the highlighted Power Management Integrate Circuit (PMIC) cluster - this is the new power management circuits and capacitors that allow power regulation on the DIMMs rather than the motherboard
Now I understand why a tooltips selectable untick box may be impossible to implement, and why these appear crazy upon mouse over …
Of course, thanks a lot for the tech IV hardware explanations.
I am a computer engineer and this devblog put shame on my current knowledge of hardware (I’m mostly a software guy) but also made me realize that even if you improve performance of all server-side processing and services, if the game client is not able to keep up, the perceived experience of the final user might be lower than expected.
Could it be possible to explore the idea of “best PC hardware configuration” for the common folk that wants the best experience even in large fleet fights? (or with ultra-level graphics details?)
Typically we use SOL as a interchangeable term for solar system node - a windows OS based server that can run one or more in-game solar systems/services.
For TQ, all sols are physical servers, most test servers run sols as virtual machines
I mix up terms sometimes, so it depends on who you are talking to and the context
SOL Server would typically be either the physical or virtual server that our code runs on. A sol node would be one instance of the application code running on the actual SOL Server
A node is a PROXY or SOL process in the game cluster that is assigned specific tasks. PROXY nodes are the nodes that the loadbalancer connect to on inbound connections from the Clients and they mostly handle session management and routing but SOL nodes handle solarsystem simulation and run other services (such as market, skill training, industry).
A SOL node is a process on a machine; we run 8 to 14 of them on each machine. But we often use no. 1 as well to refer to machines that only host SOL nodes.
As I remember - and I may well be incorrect here - ship change timers had been made a thing of the past until the launch of citadels, where it was possible (through not very nefarious means) to hopin your fortizar and start warping it about the system due to session changes not propagating correctly.
Needless to say that while this was hilarious, it needed shutting down pretty quickly to prevent madness.
I got a little misty-eyed reading the happy Devs reporting the elimination of ship change timers. Happy times! I hope that your teams’ continued excellence allows this blissful state to return one glorious day.
In the meantime, thanks for the cool blogs and of course the most excellent tinkering to keep the hamsters running and magic electric pixies dancing in the right circles…!