(POL097-2006-09-16) polcore().sysload on DualCore system

[Xandros]

We recently moved our game shard from a single core (Athlon) to a
DualCore (Pentium D) system. Before, polcore().sysload would correctly
show the CPU load of the system. Now it shows values like 30% or 50%,
although both cores have only like 5% load. Our system is running on
Windows 2000.

Thanks,
Xandros

[MuadDib]

Technically we do not support dual core, dual processor, and so forth. That would not be a bug, but a feature request

Let's us get, honestly, the core to where we would like it to be, then we can look into other hardware/os type situations. Personally those are less important than fixing and finishing the core

[CWO]

Actually this happened to me too but my processor is hyperthreaded so its counted as 2 processors. But I actually found out it was the hard drive access that did this because on the old server it was an SCSI drive and on the new one it was just a regular old 7200 RPM drive. I upgraded it with 2 drives on RAID 0, extended the size of the virtual memory, and suddenly, the CPU went to 0 most of the time.

[Marilla]

hmmm... Please take my post... aww hell; take it as whatever you wanna take it as, I don't care

But that just seems backwards: While waiting for disk I/O, the CPU does nothing. Now, that's not to say that the program in question could not have multiple threads doing different things while one thread waits for disk I/O, but that's actually the point: While waiting for Disk/Network/Bus I/O, the CPU is idle - this is how MultiThreading brings benefits to a computer, even though a single-core CPU can only be executing one instruction at a time.


When a thread reaches a point where it must 'wait' for an external event - disk I/O, for example, that thread is stopped from executing and some other thread is given time by the OS. If Multithreading did not do this, then your computer would be molasses slow, no matter how fast the CPU was, because your CPU would be wasting all it's time just sitting there, waiting for the rest of the computer to respond to it.

So even though only one code thread can execute per-CPU/Core at a time, multithreading works by knowing that when a thread is waiting for external stuff, like disk I/O, it can put that thread to sleep and do another thread for a bit. In this way, the CPU is used most efficiently.


=====================

That said, I've run POL on systems with butt-slow 5400 RPM, ATA33 drives under 'modest' test server load, and not had a single problem. Of course, world saves take a few extra seconds, but that's it.

======================

However, I think you also said something else that was much more likely the issue: Adjusting the virtual memory. Essentially, it's very important that POL -never- have to use Virtual memory, IMO. POL should be able to keep every single bit of data in physical memory. Anyone who has run a shard on a system with not enough physical memory knows the result: A shard-wide momentary lag spike every time the hard drive light flashes, due to paging memory to/from virtual memory.

No matter how fast your hard drives are, they are orders of magnitude slower than physical memory. The time to swap a page of memory in/out of virtual memory may be a small fraction of a second, and for a spreadsheet (or even for loading a new location's graphics when you are gated in the UO client), that's not a big deal at all - we hardly notice it. But when we're talking about needing to access the weapon skill of a mongbat in combat, that 100ms can be a big drain.



Assuming you get the virtual memory/physical memory configured properly (so that POL never uses virtual memory), the only time the disk drives are important at all is during world saves. Incidentally, how much physical memory you have is also important during world saves - it seems, roughly speaking, that if you have roughly twice the physical memory required for your shard, that your world save times are dramatically reduced, likely due to lack of need for virtual memory shuffling while POL is indexing and sorting everything to write it or buffer it while saving the disk files; All I know in this regard is that going from a few hundred megs more physical memory than POL was using to just a bit over twice what it was using reduced my world save times to about 15% of their former times - with no other changes at all.

[MuadDib]

Technically, if you are using Windows. Ever see if your shard runs different in linux vs windows? The difference for the larger shards is un-freakin-real. World saves that are 5s on a Win machine, is like 25ms on a Linux box.

Back to the subject......... He is stating, that the core is Mis-reporting the cpu load on the dual core. Which did not exist when POL was made.... so that's a feature request for more specific support of dual core processors

And yes, virtual memory SUCKS ASS for POL. Plain and simple. However, I would personally LOVE for some people to test sysload with new findpath() fixes in place (run it hardcore!), and also with the memory disabled for all realms, so that it is read from file instead of stored in memory. The memory bit, would be ideal tested with findpath() not used, and then used also, to see how it all affects each other

[Marilla]

[Xandros]

I'm not pushing you to do something about it, I just thought,
since I observed it, I might tell you about it.

Xandros

[CWO]

Umm POL seems to ALWAYS use virtual memory even though theres a crapload of RAM available to it. Even right now, POL is using 700MB VM with 250MB RAM and I have 1.1GB RAM freely available doing nothing... If I shrink the VM size, all I get is bitching about the VM being full. Seems I have no choice in the matter, POL is going to use VM. Luckily I'm on a RAID 0 so its slightly faster to access.

[Marilla]

Well, it may also be that it's got itself worked out to only keeping seldom-used stuff in VM, and it's able to keep all the stuff that it uses often in physical memory. As long as it's working well, though... whee!

[OWHorus]