Cormyr is UP

Archest

Well-known member
because the higher the latency the more lag complaints in front of you here in this forum.
 

Natashaelle

Time Bandit
proves the point lag is caused by latency
No, according to whar Severlin said, the major lag-reducing benefit of 64-bit versus 32 is that they can load a ton more data into a much larger RAM, so that the game relies far less on virtual memory and a ton more of the game's resources are permanently available in live memory -- which leads to less lag from virtual memory loading and cleanup.

Doesn't fix any non-memory sources of lag, and sure poor latency can cause that on individual client-side player rigs, but the deeper improvements we've seen are mostly from the above, though I'm sure that the 64-bit code itself can also handle complex game situations (like the stress test and causes of red & purple DA) more effectively than the 32-bit.
 

Br4d

Well-known member
Most lag is not caused by latency.

When I get lag my latency is at 40ms or so and it does not change whether I am lagging on not. There are moments when things suddenly go wrong and I get packet loss and step lag but that's a different thing.

If I log into any server but Wayfinder it takes a minute to get in. That's purely a code or data center issue. Any lag that is causing that delay is in the data center not somewhere between me and the data center. More likely there is a set check interval between a request to Enter and actually landing in the game.

The code is pre-packing the layers in the character so they don't all explode at once when I land or somesuch. I also come in somewhere beneath the surface layer, sometimes deep and sometimes just waist-deep in the ground before my character resets. 15-20 seconds later my character resets and is at surface layer. Also, my astral shards register as 000000 while I am being "pre-processed" and then to the correct sum when my character surfaces.

When I logged into the 64-bit server it was instantaneous. Click character. Click Enter. In the game a second or two later.

Edit: I should have transferred my main over to do the test. I will do that next time Cormyr is up. However except on Wayfinder I do not see faster entrances into the game and all my Wayfinder characters are 3rd life or earlier, at least one with a TR cache. The faster entrances on Wayfinder are 5-10 seconds after the request and still buried in the ground for another 5 seconds.
 
Last edited:

Verran

Well-known member
No, according to whar Severlin said, the major lag-reducing benefit of 64-bit versus 32 is that they can load a ton more data into a much larger RAM, so that the game relies far less on virtual memory and a ton more of the game's resources are permanently available in live memory -- which leads to less lag from virtual memory loading and cleanup.

Doesn't fix any non-memory sources of lag, and sure poor latency can cause that on individual client-side player rigs, but the deeper improvements we've seen are mostly from the above, though I'm sure that the 64-bit code itself can also handle complex game situations (like the stress test and causes of red & purple DA) more effectively than the 32-bit.
That "a ton more" is literally the 4 GB cap a 32bit process has - it is 2 to the power of 32 vs the power of 64. To give you perspective: 4GB is what a particularly busy chrome tab costs you. Most modern phones have more memory then that.
And "virtual memory" is a fancy term for "it's stored on disk instead". Which even with modern m2 drives is still factors slower then RAM and causes CPU load too, by page faults.

64bit "code" is not something that exists, at least not in the sense of program code. Assuming the servers runs on some form of C++ code too, it would be the compiler's job to create either a 32 or 64 bit binary out of the same program code. You can do particularly dirty things that make it harder to switch to 64 bit (a classic would be to assume the size of various primitive data types and try to do the compiler's job yourself in program code), which unfortunately was prevalent in early C++ code (steming from C code habits), but that is besides the point here.

Switching to 64 bit will not magically cure inefficient pathing code ("dungeon alert") though. But what it does is give you the option to throw more hardware at the problem - just use more RAM, everyone else solves their problems that way too..... (which is the reason chrome tabs consume what they do.. why fix problems if you can throw more hardware at them...).
 

Natashaelle

Time Bandit
That "a ton more" is literally the 4 GB cap a 32bit process has
Computers typically run more than one single process. And it's dubious that the 64-bit servers will be running 32-bit DDO server software for 64-bit DDO Client rigs.
64bit "code" is not something that exists, at least not in the sense of program code. Assuming the servers runs on some form of C++ code too
???

Code that can be interpreted to generate 64-bit binaries must be interpretable for that purpose, so here you're really just splitting hairs.
 

Sethvir

New member
Computers typically run more than one single process. And it's dubious that the 64-bit servers will be running 32-bit DDO server software for 64-bit DDO Client rigs.

???

Code that can be interpreted to generate 64-bit binaries must be interpretable for that purpose, so here you're really just splitting hairs.
He is not splitting hairs. In fact, his post is probably the most accurate i have seen in the past 2 weeks. To put it very very nicely ...

And there is nothing dubious about 64bit hardware with 64bit OS running 32bit server-software/app for 32bit clients. Thats totaly perfectly, fine.
Since the days that 64bit hardware became mainstream, its a also more or less mainstream, that apps used 64bit variables inside 32bit software (at least compiled and interpreted code). There is nothing strange about it. The only real advantage nowadays in true 64bit software is the address-space available to the software and that there is no longer any need of translation/mapping between 32bit adressspace for 32bit progs and the actual adressspace. Because as Verran already 'explained', nowadays sw and devs dont care anymore about memory efficiency (use) and thus the demands are spiking even for non big-data sw.
For server sw that has hundreds or thousends of client connections at a time with no-trivial taks per conn, the migration to 64bit now, is already very very late, aka overdue.
 

Verran

Well-known member
Computers typically run more than one single process. And it's dubious that the 64-bit servers will be running 32-bit DDO server software for 64-bit DDO Client rigs.

???

Code that can be interpreted to generate 64-bit binaries must be interpretable for that purpose, so here you're really just splitting hairs.
Computers do run more then one process, nearly all the time I would say, but I heavily doubt they were smart enough to split the server into multiple processes - I honestly even doubt there is more then one thread. This all smells like a giant monolothic main loop that performs as well.. as we can see now.

And C++ code (or rust, or let's say most other compiled languages) is not inherently "64 bit". And usually server processes that need to handle more then very basic functionality are not written in interpreted languages (like php or perl), but rather in compiled ones (or sometimes mixed cases such as JIT compilation, but that goes even further beyond the scope).

So the most likely scenario is that they had to touch up their old C++ code a bit and then compile it with something akin to -march=x86-64 set.

Also it doesn't matters in the slightest whether client and server use the same memory bandwith (32 bit vs. 64 bit), since the network packets they use to communicate are standardized anyway. The only thing 64 bit "gives us" is more useable RAM on the server.
 

LurkingVeteran

Well-known member
Does the game server really rely on virtual memory (hdd) or was this something lost in translation?

Possibly the database would rely on virtual memory if they have locking queries to a ginormous backend loot database. That would explain a lot. I still don't understand what that has to do with 32bit server processes though, they would only need to upgrade the database to 64bit? Very strange the whole thing. As long as it works, who cares though. People will be overjoyed if this finally fixes the lag.
 

DDO Gaming

Well-known member
64bit "code" is not something that exists, at least not in the sense of program code. Assuming the servers runs on some form of C++ code too, it would be the compiler's job to create either a 32 or 64 bit binary out of the same program code. You can do particularly dirty things that make it harder to switch to 64 bit (a classic would be to assume the size of various primitive data types and try to do the compiler's job yourself in program code), which unfortunately was prevalent in early C++ code (steming from C code habits), but that is besides the point here.
// The main difference between a "32-bit" and a "64-bit" system is as follows: in "64-bit", the applications and the system no longer have memory allocation limitations. In "32-bit" configurations the operating system is limited to 4 GB, while in "64-bit", there is nearly no limit (18 billion GB). //

its the compiler that's either 32 bit or 64 bit since 64bit C++ will manage memory in a dramatically different way to the 4GB limited 32bit C++ compiler.

I have no idea if [extended] 32bit C++ compilers have special instructions to deal with the limited memory addressing however I assume all base code modules will need to be recompiled against a 64 bit C++ compiler AND there may need to be SOME code-rewrites that reflect the fact the C++ being used is 64bit instead of 32 bit.

A "dirty" solution is to run the code in a 32 bit environment however that then kills the purpose of using a 64 bit server
 

Ryiah

Well-known member
My ping on the normal servers is currently around 40 and on this new test server it is just shy of 80. That said I am in the NE section of central FL so the recent storm might be having some impact but then again it might not.
I'm in Central Virginia with fiber-to-the-premises. Khyber is 16ms. Cormyr is 66ms.

64bit "code" is not something that exists, at least not in the sense of program code.
It exists it's just rare because the criteria to end up with it is rare. Regardless of that though you need to have a 64-bit capable compiler, a 64-bit linker, and 64-bit libraries. I've listened to Severlin's explanation a few times. He mentioned the system in question is running on top of a virtual machine. My impression was that it's possibly similar to the Java VM. If that's the case it'll need to be rewritten or even completely replaced.

Where is the entrance to the level 1 story dungeon for lanterns?
Hall of Heroes near the VIP rewards NPC.
 
Last edited:

Natashaelle

Time Bandit
He is not splitting hairs. In fact, his post is probably the most accurate i have seen in the past 2 weeks. To put it very very nicely ...
Well, last time I was a programmer, it involved variously machine code, creating new OS commands and programming language commands, combining 1st through 4th generation programming languages, and even having to work with divergent file systems.

That deep level work has been done with programming languages to get the same written code to provide 32-bit or 64-bit compiled outcomes on demand is certain, but the 64-bit outcomes need to be an intrinsic element of the programming languages themselves to provide that possibility.

I suppose there's a dumb question about whether the development tools used by SSG are themselves 32-bit or 64-bit, but that's a complete irrelevance. The initial Windows x64 created by Microsoft and AMD on the software side was written with 32-bit tools.
And there is nothing dubious about 64bit hardware with 64bit OS running 32bit server-software/app for 32bit clients. Thats totaly perfectly, fine.
What's dubious is what would be the point of 64-bit hardware if all that SSG would do is run 32-bit software on it, with the same limitations as the current Live server software. I mean, given the existence of the 64-bit DDO Client software, their development tools clearly can generate 64-bit software.
 
Last edited:

Ryiah

Well-known member
What's dubious is what would be the point of 64-bit hardware if all that SSG would do is run 32-bit software on it
To run multiple copies of the same program. It's not a single program running per server. It's a single program running per instance on the server which is why you can have one dungeon lock up while another dungeon can be just fine. A system with 128GB RAM can run a whole lot more apps than a system with just 4GB. Plus it's not like you can just buy 32-bit servers now.
 
Last edited:
Top