Putting Kuju file on a Diet

[jarmstro]

JohnA
Yes on some routes/scenarios the VAS is not always "cleared" (VMMAP) after they are finished and if you do not clear the cache then you have a defragmented VAS or it is depleted and you usually see a lengthened loading time and if worst comes to worst a SBHH. Physical RAM, cpu cache and the paging file seem to be unaffected - I couldn't find a memory leak. Except on one occasion I was using process monitor to see what was causing a "Kuju" issue and suddenly the RAM usage rose to 100% and I had to reboot to get going again. Hmm.

I have got into the habit of clearing the blueprint cache at the end of every scenario and that seems to alleviate the problem. Funnily enough the later "complex" routes don't cause a problem.

Regards
pH

Peter.

I find that too. VAS is often not cleared. Especially after an SBHH or indeed after quitting a route and starting another. The cumulative affect of loading more and more data inevitably leads to an SBHH. In addition to clearing the cache I find rebooting the PC cures any SBHH problems.

Is there any way to manually purge VAS via the Command Prompt (ie a .bat file)? As this is a 32bit program running in an emulator on 64bit systems is there any way to "3GB Switch" the emulator??

I run Win7 64bit with 8GB RAM. Would there be any point in me adding another 8GB re SBHH in RW2013?

Best Regards

John A

[peterfhayes]

John
There is no physical way to clear the VAS - well there is - you have to close TS2013 and then restart it (like following clearing the cache) and when we re-start TS2013 it loads into a "pristine" VAS. But that is the only way but see my registry hack below.

Funny you should talk about RAM - I am having to rebuild my PC and I've just received another 8GB RAM taking the total to 16 GB.
Reasons:
I run Photoshop 64-bit and X-Plane 64 bit so they can access the extra RAM as well as having 8 TERABYTES of VAS,
I want to try a RAMDISK to see if it affects TS2013 performance.
I have 3 x SSDs on that rig and extra RAM actually prolongs their life as it reduces the number of R/W to those disks.

The most RAM usage I see in TS2013 and Windows 64-bit is around 5.4GB so 8GB is plenty for TS2013 but not for the reasons above, and 16GB will not affect anything adversely.

The /3GB switch is NOT needed in a 64-bit OS running a 32-bit app with the Large Address Aware Flag set (TS2013) as it is already set at 4096MB ie 4GB, so the /3GB switch would REDUCE the VAS by 1GB which would not be good. However there is a registry Hack that I have had only partial success with called the "HeapDecommitFreeBlockThreshold" in Windows Server (should work in Win 7 32/64 bit) it prevents the defragmentation of the VAS and can prevent SBHH's due to VAS fragmentation. I cannot find the optimum setting in Win 7 64-bit - hence the partial success.Here's the reference: Ref: http://support.microsoft.com/kb/315407 and http://technet.microsoft.com/en-us/libr ... g.65).aspx.

Regards
pH

[jarmstro]

John


The most RAM usage I see in TS2013 and Windows 64-bit is around 5.4GB so 8GB is plenty for TS2013 but not for the reasons above, and 16GB will not affect anything adversely.

The /3GB switch is NOT needed in a 64-bit OS running a 32-bit app with the Large Address Aware Flag set (TS2013) as it is already set at 4096MB ie 4GB, so the /3GB switch would REDUCE the VAS by 1GB which would not be good. However there is a registry Hack that I have had only partial success with called the "HeapDecommitFreeBlockThreshold" in Windows Server (should work in Win 7 32/64 bit) it prevents the defragmentation of the VAS and can prevent SBHH's due to VAS fragmentation. I cannot find the optimum setting in Win 7 64-bit - hence the partial success.Here's the reference: Ref: http://support.microsoft.com/kb/315407 and http://technet.microsoft.com/en-us/libr ... g.65).aspx.

Regards
pH

Thanks Peter

Trying it out not. I've set the key to the value recommended in the article.

Another thing I have definitely noticed is that after an SBHH and quitting RW2013 if I load up another game such as Crysis 3 (which otherwise runs perfectly) it will cash after a minute or so. Something lingers on after an SBHH which affects the whole Windows OS?

John A

[peterfhayes]

John
I haven't seen that effect ie starting another game after finishing TS2013' It may not be due to RAM or cpu usage as with my Pertelian after I close TS2013 I see that the cpu usage falls from around 14% to 2% and RAM drops immediately from around 45% to around 25%.
My theory (FWIIW) - STEAM will have its own VAS and that may become fragmented/depleted when running/interacting with TS2013 and that may be causing the new program crash. Can you, as well as closing TS 2013 down also exit STEAM then re-start it and see if you get the same effect?
Just a thought.
pH

[jarmstro]

John
I haven't seen that effect ie starting another game after finishing TS2013' It may not be due to RAM or cpu usage as with my Pertelian after I close TS2013 I see that the cpu usage falls from around 14% to 2% and RAM drops immediately from around 45% to around 25%.
My theory (FWIIW) - STEAM will have its own VAS and that may become fragmented/depleted when running/interacting with TS2013 and that may be causing the new program crash. Can you, as well as closing TS 2013 down also exit STEAM then re-start it and see if you get the same effect?
Just a thought.
pH

Hi Peter

In fact Crysis 3 is an Origin game and not Steam although Steam is running in the background. I've done some non scientific testing:

If I run various scenarios in RW2013 on different routes until I get an SBHH and CTD and then start Crysis3, Metro Last Light or Skyrim the game crashes after around 30 seconds.

If I run these games from a clean reboot they run flawlessly and I can jump from game to game without any problem.

Could the issue have anything to do with VRAM? (I am using oldish NVidia drivers (v314 series) as I have found the newer 320 series to be unstable with my 660Ti in that they cause random TDR's.)

I am definitely left with the impression that an RW2013 SBHH (caused by memory faults/overload?) leaves Windows in an unstable and unrecoverable state which only a reboot solves? Weird?!

Best Regards
John A

[peterfhayes]

John
I doubt that it has anything to do with VRAM. I have a GTX 660TI (latest drivers) and I don't see the usual signs of VRAM depletion ie artefacts, spiking, flashing textures, etc, that would suggest any issue with it. I would have thought that just going to the desktop would have "refreshed" the card.
But with computers you never know and by rebooting you have certainly flushed all of the usual buffers.
It is a very interesting question that I do not have an answer to, and as I say now that I have stopped using 3rd party free add-ons I rarely see a SBHH except when I do something silly.
It might be worth you running Procmon in the background and then analyse what is causing the crashes. I did analyse Procmon logs from about 20 different TS2013 simmers who were experiencing SBHH's due the "KUJU Folder effect" but there was no apparent error that seemed to cause the crashes (or none that I could find or interpret).
Hope you can find a solution that would be a breakthrough!
Regards
pH

[darren10000]

Thanks guyz, I had the same problem after installing the Class 90 pack and SBHH all over the place. Made a separate skinny folder just for GEML and IT WORKS!!!!

Now all we need is a few Class 302,305,309 & 312 units...Is anyone thinking about doing them?

Darren
73E

[Juanillo99]

Hello.
One contributor that the Kuju/RailSimulator folder "fattening" excessively, are the re-skins of "UKTS Freeware Packs".
Ideally, the "UKTS Freeware Packs" were installed in a different folder to Kuju/RailSimulator.

[nobkins]

One contributor that the Kuju/RailSimulator folder "fattening" excessively, are the re-skins of "UKTS Freeware Packs".
Ideally, the "UKTS Freeware Packs" were installed in a different folder to Kuju/RailSimulator.

Unfortunately that would require copying all the sounds files, scripts, bogies etc etc etc for every locomotive that is in the freeware pack.

Not only do we not have permission from RSC to do this the amount of work editing and testing every single BIN file prevents this from happening.

Many of the rolling stock packs (not the asset packs as they are already in their own developer folders) do indeed "bloat" the Kuju\RailSimulator folder but they were created before this was a known issue and unfortunately it is not something that can be changed now as every single route, scenery etc that uses a freeware pack item would no longer work if the bin files were moved to a new location.

The ideal is of course for RSC to fix the problem.

[Juanillo99]

The ideal is of course for RSC to fix the problem.

Yes, you're right.

But I doubt that RSC do something about, because they already have resolved to their way: not putting more DLCs in Kuju/RailSimulator but in individual folders under RSC provider.

[jarmstro]

Here is another great tweak that has definitely (I think!!! Well, it seems to..) reduced my SBHH's and provided better FPS and smoother gameplay. I'm running Win7 64bit and cannot say whether it works in any other OS.

If your BIOS has an option for HPET, enable it and make sure it is set correctly for your OS. Either 64 or 32 bit. If your BIOS does not have this setting do not use this! And if you do not know about your BIOS don't use it either.

In a CMD prompt window opened as an administrator type:

bcdedit /set useplatformclock true

Restart PC

To go back type:

bcdedit /set useplatformclock default

Restart PC

John A

PS: To see if its working, or if you have it correctly set check Device Manager for 'High Precision Event Timer'

[peterfhayes]

John
HPET is a BIOS setting so it should work in any 64-bit OS irrespective of the OS (or 32-bit as the case may be).
I have not seen it having any significant effect wrt SBHH's but computers are funny things!
pH

[gptech]

The 'bcdedit /set useplatformclock true' command makes the system exclusively use the HPET, normally the most appropriate timer is chosen on an ad hoc basis. Reducing the 'wait states' (for want of a better description) whilst the machine decides which timer to use can give positive results so the tweak is certainly worth a try if you're experiencing problems. The beauty of it is that it's easily reversed if things don't work.
It was originally developed (jointly by Intel and Microsoft) to improve streaming media and has been around for about a decade so most modern PCs running Vista or newer will have it enabled by default.

[jarmstro]

John
HPET is a BIOS setting so it should work in any 64-bit OS irrespective of the OS (or 32-bit as the case may be).
I have not seen it having any significant effect wrt SBHH's but computers are funny things!
pH

Hi Peter. Well, although I cant prove anything I would swear blind it has reduced the memory related SBHH-ing on my system? It could well be placebo! But if the placebo works.....???

In any event, I confidently predict a worldwide SBHH epidemic of staggering proportions once the new marketplace (assets etc) and Workshop user-routes are up and running!

Cheers
John A

[peterfhayes]

John
I had a senior's moment on this one I should have said 'dependent on the OS" and NOT irrespective. (Gary thanks for the correct interpretation)
Don't know what I was thinking!!!
I guess HPET could help with some SBHH's but it would be mighty odd if any SBHH was purely due to timing at that level.
But Hey, Computers are so varied anything can happen!! I'm glad it helped you!!
Lets hope TS 2014 has overcome a few issues.
pH