We have detected that cookies are not enabled on your browser. Please enable cookies to ensure the proper experience.
Page 3 of 3 FirstFirst 1 2 3
Results 51 to 68 of 68
  1. #51
    Join Date
    Jul 2016
    Location
    UK
    Posts
    2,706
    Quote Originally Posted by Snowlock View Post
    I guess that's a 'no'.



    Exactly. This is the reason some people claim that an older computer will run LOTRO better than a newer one, right? It's going to increase the cap on memory resources the client can draw on. So will the new cap help performance then?

    We got 64 bit servers in 2015 (16?) It didn't help. But the type of "lag" that people generally called "server lag" is because it happens to everyone in the same place at the same time. But it's actually (the last time I spoke to a dev about it) the CLIENT maxing its resources for everyone in the same way at the same time due to some very inefficient in game mechanics). When it's confined to area.
    [waves], hello?? I have recorded 32bit programs using more than 2-3GB, I have had LOTRO.exe running with 3.8GB in use around M.T. (crashed @ ~3.85GB) for starters.

  2. #52
    I believe Snowlock is talking about players and not known locations that cause less than the optimal experience.


    It becomes more evident over time many players swap ILI's also Li's to gain the advantages of different features allocated to them while incombat.

    I recently learned some found a way to utilize Plugins to further this advantage. If its true I don't know. In any case I question if actions directed through the client at an exceptionally fast speed can be processed by the game servers without causing lag.

    If this does indeed increase the lag we already endure will any new upgrades in regards to 64bit enhancement reduce these kinds lag?
    Università degli Studi di Roma "La Sapienza" Sapienza University of Rome

    Graduate PhD con lode Scienze della Politica

  3. #53
    Join Date
    Mar 2007
    Location
    Missouri
    Posts
    368
    Quote Originally Posted by Yarbro View Post
    [waves], hello?? I have recorded 32bit programs using more than 2-3GB, I have had LOTRO.exe running with 3.8GB in use around M.T. (crashed @ ~3.85GB) for starters.
    That's called making the .exe LAW ( Large Address Aware ). It's a simple thing as it only requires the programs executable to be modified, which TurSSG likely did at some point. It enables a 32bit program to access up to 4gb of ram, however it becomes unstable the closer to 4gb the program gets.

  4. #54
    Join Date
    Feb 2007
    Location
    USA
    Posts
    6,524
    Quote Originally Posted by Korandon View Post
    That's called making the .exe LAW ( Large Address Aware ). It's a simple thing as it only requires the programs executable to be modified, which TurSSG likely did at some point. It enables a 32bit program to access up to 4gb of ram, however it becomes unstable the closer to 4gb the program gets.
    Yep, happened in June 2007.
    Installing LotRO -- One Guide to Rule Them All!
    Purchasing LotRO -- Guide to Building Your Own "Lifetime" Account.
    DirectX / Direct3D Error Messages? -- Solution.

  5. #55
    Join Date
    May 2007
    Posts
    5,283
    Quote Originally Posted by Yarbro View Post
    [waves], hello?? I have recorded 32bit programs using more than 2-3GB, I have had LOTRO.exe running with 3.8GB in use around M.T. (crashed @ ~3.85GB) for starters.
    ? Not sure your point to me here. I believe you, its just that that wasn't my statement regarding 32 bit and memory usage. You'd have to ask the guy who discussed it. I don't know the numbers or the levels.

    All I've heard since the discussion changed from "server lag" to "client lag" and this has been around for a long time, prior to the data center moves, (probably since the 2014 PC which had a good cross section of PVP'ers who, though couldn't agree the sky is blue in the daytime, did all take to heart the issue of "the lag" and engaged a number of then-Turbine employees about it) was that the issues were with the client, as in the LOTRO program, both in inefficiencies of the code and in some sloppy mechanics. A big one being account shared items.

  6. #56
    Join Date
    Sep 2016
    Posts
    2,072
    Quote Originally Posted by OghranNasty View Post
    I wished SSG would just close threads that end in personal battles. Nobody wants to read this.
    Quote Originally Posted by LabadalofDorlomin View Post
    @Cordovan

    Please don't lock this thread when you arrive in work this morning. Just deal with the 2 who hijacked it for petty arguments.
    It actually started off really interesting until over inflated egos got in the way.

    I for one am still interested in this subject and would like it to get back on track.

    Hopefully.....Thanks
    Ok, I have now pruned more than 50 posts from the thread and banned two of the folks who were most prevalent in dragging this (and other threads) off topic with personal fighting. Unless you would like to join them, I would recommend not making it personal. I will keep the thread open per the suggestions above.
    Community Manager, Lord of the Rings Online
    Follow LOTRO on: Twitter - Facebook - Google+ - Pinterest - Twitch - YouTube
    Find Cordovan on: Twitter Instagram
    Support: help.standingstonegames.com
    coolcool

  7. #57
    Quote Originally Posted by scorrp10 View Post
    Apple is not "working" on 64 bit OS. OSX has been fully 64bit since 2011 10.7 "Lion".

    The problem is that hardware manufacturers may stop providing 32 bit support, meaning operating systems will need to emulate the environment for 32 bit apps. Any such apps that presently rely on direct hardware acccess (mainly graphics) are going to see a major performance degrade.
    This is not entirely true. Apple is deprecating the ability for 32-bit applications to run on Mac OS. Right now it's in an optional thing that just throws a warning, but it's going to be problem sooner rather than later. Apple hasn't set an exact date for it, but with the pace they've been settings, I'd expect it to happen within the next two versions.

  8. #58
    Join Date
    Jul 2016
    Location
    UK
    Posts
    2,706
    Quote Originally Posted by Snowlock View Post
    ? Not sure your point to me here. I believe you, its just that that wasn't my statement regarding 32 bit and memory usage. You'd have to ask the guy who discussed it. I don't know the numbers or the levels.

    All I've heard since the discussion changed from "server lag" to "client lag" and this has been around for a long time, prior to the data center moves, (probably since the 2014 PC which had a good cross section of PVP'ers who, though couldn't agree the sky is blue in the daytime, did all take to heart the issue of "the lag" and engaged a number of then-Turbine employees about it) was that the issues were with the client, as in the LOTRO program, both in inefficiencies of the code and in some sloppy mechanics. A big one being account shared items.
    Sorry, I was in a hurry and quoted the wrong person. My 5 y/o decided today was the day to take up the quests she abandoned in Garth Agawen 2 months ago; so I was monitoring my stable horse's arrival and posting to the forum at the same time.

    Microgit have crippled their own software many times over the years, but someone usually comes along and "fixes" it; like the 32GB limit on formatting Flash memory as FAT32, when the actual limit is 2TB; the WinXP formatter was perfectly happy to do it, and so was Win7 at launch, then suddenly they decided to stop it; not sure what they allow in Win8-10, but I have FAT32 formatted 128GB cards with no issues using 3rd party software.

    dx10 on WinXP was another. WMP 11 on XP one more.

    I understand there are even artificial limits on how much RAM various flavours of 64bit Windows can "see"

  9. #59
    Rewriting for 64bit does more than give access to extra memory. The Microsoft x64 (64bit) calling conventions allow for 4 integer and 4 floating point numbers to be passed by register (much faster), versus the x86 (32bit) stdcall conventions that push numbers onto the stack (slower).
    Squirrel!

  10. #60
    Well this is getting rather juicy now on the technical fronts.

    From what I glean from this thread, pre and post pruning (thnx Cordovan), is that most informed posters don't really know or are at odds with what a 64 bit games engine/client? will do for us if anything.

    So, it;s a lottery. I'm betting that SSG don't fully know what benefits it will bring us - fairly sure they know what benefits it has to them, which is possibly why they are reluctant to weigh in to the conversation.

    Where is this new engineer who was employed to do this and got waylaid with other back end duties? Lets here from you please. Even if it is only to introduce yourself to the baying crowd.... we don't bite.... much
    ----A casual stroll through the lunatic asylum shows that faith does not prove anything----

  11. #61
    Architectural benefits of AMD64 (64bit) vs. intel386 (32bit)

    larger address space
    a richer register set

    Typically a 30% speed improvement for compute-intensive code like video processing on (64bit) compared to (32bit).
    This is most likely due to the fact that we have 16 x 64 bit general purpose registers and 16 x SSE registers instead of 8 x 32 bit general purpose registers and 8 x SSE registers.
    64-bit compilers use the SSE registers while 32-bit compilers use the standard ALU.
    This makes 64-bit code faster due to the narrower FP width (64 vs 80) plus additional instructions.


    Architectural downside of x64 mode

    all pointers (and thus many instructions too) take up 2x the memory, cutting the effective processor cache size in half in the worst case.

    Estimate the increase in the overall memory usage for a 64bit application compared to a 32bit one to be around 15-30 %.

    -

    The game will benefit from the larger amount of Ram that will be allowed to address

    in systems with 8 to >=16GB of Ram.
    If you have a pc with 4GB ram it wont make any difference.

    The crashes due to memory leak or slow garbage collection ( zone transition), will be far less, again if you have above 8GB of Ram.
    Dont forget you have the Operating System in the background and other programs like your browser etc that use system memory too.

  12. #62
    Join Date
    Jul 2016
    Location
    UK
    Posts
    2,706
    Quote Originally Posted by Chompee View Post
    Rewriting for 64bit does more than give access to extra memory. The Microsoft x64 (64bit) calling conventions allow for 4 integer and 4 floating point numbers to be passed by register (much faster), versus the x86 (32bit) stdcall conventions that push numbers onto the stack (slower).
    In real life, x64 hasnt been much of a speed boost over x86; this based on my experiences with XP32 v XP64 and Win7 32 v Win7 64; the improvements were perhaps 10-15% at best.

    As I said before, any new client needs to address the lack of gfx card use; just fixing this and ignoring the whole 32 v 64 bit would improve the game immensely; as would fixing the lack of multi core support. The fact is, the client will have to address ALL of these if there is to be any real improvement; and that is basically a complete top to bottom rewrite of the code. A job that would take a TEAM of programmers several YEARS and a lot of MONEY to get right.

    The only way to pay for that would be to launch it as a whole new subscription only game and I am not sure they could get the Tolkein estate to go for that.

    I suspect they have been tinkering with the code to try and allow multi core use; how my AMD cpu implements the game has changed over the last year; more cores are being used, as many as four*; but the total cycle time still doesnt exceed 1.5 cores worth.

    * But only if I set affinity to four cores or less; give it six cores and it reverts to using two.

  13. #63
    Quote Originally Posted by TearMaker View Post
    So, if the games engine is 64bit and is utilised correctly, my game experience would be spread over the other 7 cores or at least different aspects of the game could be handled by different cores. as in textures on one core, storage on another, game play on another etc etc..... ?? answers on a postcard please
    Moreover perfection is not attainable, but if we chase perfection we could catch excellence.
    Unfortunately, the answer to this is no. Making the game executable 64-bit will allow the game to use more RAM (whether it will be designed to use that RAM is an open question), but it has nothing to do with how many cores are utilized. A single-thread 32bit program updated to 64bit will still use only a single thread, thus only one of your cores.

    I would imagine that making LOTRO multi-threaded is not in the cards, as this would be a significant amount of work.

  14. #64
    Quote Originally Posted by Yarbro View Post
    I understand there are even artificial limits on how much RAM various flavours of 64bit Windows can "see"
    Yes, MS have been doing that for years. There was an x64 version of WinXP that was limited to 128GB of useable RAM. Win7 Pro x64 is limited to 192GB of RAM. I'm not sure about any versions of Win8 but I do know that the "Home" version of Win10 is limited to 128GB and the other current versions of Win10 are limited to 2TB of RAM.

    I'm not a programmer, but I have approx. 25 years hands on experience with system/server and network management. I've worked with some fairly high end (for their time) systems such as Cray, Masspar and others as well as mid range and low end systems, mostly in academic science/engineering research and commercial business environments. While I've never worked as a software dev, I've spent years working with software devs, so I do have some idea about that side of things.

    A 64 bit client has the potential to improve things, but going 64 bit is not some golden bullet that will make everything wonderful just because it's 64 bit. Among other factors is that Turbine/SSG did not write every line of code in the server and client software. Turbine/SSG has licenced software modules to perform certain functions inside the game code. Those modules were written by other software companies. Maybe those 3rd party modules that are integrated into the LOTRO game code will work well in 64 bit, maybe they need to be replaced. Some of those 3rd party packages may not have a 64 bit version ready for use and will need to be developed, or alternative 64 bit software modules will need to be found and work will need to be done to integrate them into the LOTRO code, replacing 32 bit modules that can't make the leap to 64 bit. The database side of the game performance may also need work as well.

    Going from 32 to 64 bit isn't as easy as some people think and isn't guaranteed to deliver the performance some people might expect. Depending on the internal details of the game code, it might be easier to start from scratch with completely new code specifically designed to be 64 bit rather than try to convert the existing code from 32 to 64 bit. The only people who will know for certain are the SSG devs. Anyone else, including me, is just speculating with only very limited information.

    All of this assumes that it's cost effective for SSG to do this. We don't know what SSG's operating costs are. We don't know what SSG's development costs to go 64 bit will be. SSG needs to keep their costs under control compared to their income or they won't stay in business. There's also SSG's other game, DDO. I've never played it but if there is enough commonality between the LOTRO and DDO software, it might make sense to develop a common 64 bit game engine/platform which can be tailored to suit each game, allowing SSG to apply any performance improvements to both games rather than just one, assuming it's feasible to even try doing that.
    Therina - Hobbit Guard Rongo - Hobbit Warden
    Frood - Man Minstrel Garmun - Man Captain
    Zorosi - Dwarf Champ Froodaroon - Elf Hunter
    Southern Defenders - Arkenstone (formerly Elendilmir)

  15. #65
    Join Date
    Jul 2016
    Location
    UK
    Posts
    2,706
    I played with XP64; in many ways it was like Win ME, a testbed for stuff that went into latter releases, and like ME, it was plagued by lack of driver support from hardware vendors. Very stable though, I dont remember it falling over at all.

  16. #66
    Quote Originally Posted by Yarbro View Post
    In real life, x64 hasnt been much of a speed boost over x86; this based on my experiences with XP32 v XP64 and Win7 32 v Win7 64; the improvements were perhaps 10-15% at best.
    That is because from what I read, it didn't.
    Where the big jump comes in a windows environment is from win8+ x86 to x64.
    I found this which made me think about folks who still cling to windows 7 and does this mean that they will be hugely limited in each user process.
    This table is billed as absolute maximum in a perfect environment.

    Version: WIN 8/8.1 WIN 10
    Version Bits: 32 64 32 64

    User Process:
    Physical Memory 2 (3) GB 8,192 GB 2 (3) GB 8,192 GB
    Virtual Memory 2 (3) GB 2 (8,192) GB 2 (3) GB 2 (8,192) GB

    Version: WIN XP WIN Vista WIN 7
    Version Bits: 32 64 32 64 32 64
    2 GB 8 GB
    User Process:
    Physical Memory 2 (3) GB 2 (4) GB 2 (3) GB 8 GB 2 (4) GB 8 GB
    Virtual Memory 2 (3) GB 2 (8,192) GB 2 (3) GB 2 (8,192) GB 2 (4) GB 2 (8,192) GB


    So, does that mean because virtual memory (which is same on 7 and 8 and 10) is disk based and limited to another set of speed bottlenecks and obvious differences to physical speeds, that the more physical memory (ram) will in fact speed up the process just by way of the type of memory utilised and the fact that you access to more?
    ----A casual stroll through the lunatic asylum shows that faith does not prove anything----

  17. #67
    Quote Originally Posted by LabadalofDorlomin View Post
    I found this which made me think about folks who still cling to windows 7 and does this mean that they will be hugely limited in each user process.
    This table is billed as absolute maximum in a perfect environment.
    [removed the table]
    So, does that mean because virtual memory (which is same on 7 and 8 and 10) is disk based and limited to another set of speed bottlenecks and obvious differences to physical speeds, that the more physical memory (ram) will in fact speed up the process just by way of the type of memory utilised and the fact that you access to more?
    Why not go to the source for such a table?
    https://docs.microsoft.com/en-us/win...ndows-releases

    While there are limits specially for the "home" versions of some of these OSes the actual values for 64bit OSes are much higher.
    Windows 7 64bit is still being used with applications that take multiples of the memory the lotroclient uses without any problem.

    Also virtual memory does NOT mean it is disk based.
    Pretty much all memory inside a user application is using virtual memory. The OS will then translate that to actual physical memory. If you use more virtual memory with all your application together as you have physical RAM then that part would be paged to disk and the OS is clever enough to page out only the parts that are not being used.

  18. #68
    Join Date
    Jul 2016
    Location
    UK
    Posts
    2,706
    That table is also wrong; I ran 8GB with WinXP64, and run 16GB with Win7 64. I have also caught WIn7 trying to set a 16GB page file.

    Ooops, just had a closer look at that table; that isnt RAM use, that is RAM use per single process. Its still wrong though, Project Cars uses more than 8GB if you let it.
    Last edited by Yarbro; Aug 15 2018 at 01:43 PM.

 

 
Page 3 of 3 FirstFirst 1 2 3

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

This form's session has expired. You need to reload the page.

Reload