Railworks Poor Performance

[ttjph]

To look at it another way: perhaps think of it as thread-limited, rather than core-limited.

Railworks seems to run one major thread (and one, or possibly more, smaller ones) and this thread can only be run by one core at once, so it can only use (100/n)% of your total CPU where n is the number of cores. The other thread(s) take less time to complete, so take up less than one extra core in total.

On my dual-core, for example, that one thread can only ever use 50% of the CPU - and if it does use 50%, then it has become the limiting factor because it's executing as fast as it can. With another thread taking up (say) half the available time of the other core, the total usage is then 75% - but that's as fast as it can run, because the CPU can't use more than one core to run the major thread any faster.

Windows may 'bounce' that thread between the cores to keep the load and temperature roughly equal, but that's irrelevant for looking at performance - it can only run on one core at a time.

I always set Task Manager to "One graph, all CPUs" since, as Nigel implies, it doesn't matter which core is running which thread at any moment in time - just that the thread is running continuously, without waiting for another process at any point.

[sdark2]

Ah I think I get what you mean now. Yes, monitoring resolution is somewhat restrictive - I opted for the highest resolution available when recording the data (500ms intervals) - I would imagine one would need to have the resolution set to log each of the billions of floating operations carried out by each core in order to get an exact picture of what's going on in terms of load.

However, the only tools I have available is what I've been using and, when comparing Railworks performance against other equally, if not more, demanding applications - I have to use the most advanced processor I have available (my brain) in order to ascertain whether the pattern of loading is better or worse. Bearing in mind that all I'm looking for is a "perception" of good performance and not a clinical sense of the word.

When comparing the clinical aspects of performance against other applications of similar intensity, Railworks is not performing as well as it should - particularly when compared to its performance with the older tech I was using. However, perceptive performance was great, as far as I was concerned, previously - since destroying the bank balance to gain extra performance from it, definitely not so.

Kr, Steve

[sdark2]

Very nice explanation ttjph, thanks for your input. That makes a lot of sense and very nicely answers a lot of my questions.

Kr, Steve

EDIT: I think this now puts to bed (for now) my issues on the poor performance of railworks (well at least how my CPU could possibly be the limiting factor) - assuming of course that the performance of Railworks improves if I can get the cpu upgraded

However, I think this thread has become a useful resource for those wondering why all of a sudden the performance of Railworks has suffered as a result of upgrading their hardware. I'll keep you posted how things go when I eventually get sufficient funds to upgrade!

Thank you everyone for your contribution here.

[paulz6]

Windows may 'bounce' that thread between the cores to keep the load and temperature roughly equal, but that's irrelevant for looking at performance - it can only run on one core at a time.

Is that a definitive statement or just an educated guess? It used to be the case on some multi processor O/S's that the scheduler would try to keep a thread running on the same processor (or core) to avoid context switching. In practice, a busy thread will bounce around processors due to involuntary context switching. For example, if you have 2 processors and suddenly 10 threads become active, the scheduler will start timeslicing those 10 threads across the 2 available cores. If you have 1 main thread and several helper threads, the main thread is not going to exclusively use one CPU, and the helper threads use the other CPU. The helper threads will inevitably take time slices out of the main threads activity. The more cores you have to process these active threads will reduce the chance that the main thread will end up waiting in the run queue. So a hex core will run RW better than on a dual core as the main thread is going to spend less time run queue.

[ttjph]

@paulz6: I'm not a CPU architecture expert, and what you describe sounds plausible - but I'd be surprised if it made a significant difference. I'd imagine any difference due to having five spare cores versus three would be outweighed by differences in execution speed due to different architectures or clock speed.

For practical purposes, though, I'm suggesting that it's not useful to know that your individual core usage is

Core1 = 18%, Core2 = 49%, Core3 = 27%, Core4 = 53%, Core5 = 2%, Core6 = 5%

- only that the total CPU usage equates to, say, 1.5 cores or whatever.

[shanyiqua]

The helper threads will inevitably take time slices out of the main threads activity. The more cores you have to process these active threads will reduce the chance that the main thread will end up waiting in the run queue. So a hex core will run RW better than on a dual core as the main thread is going to spend less time run queue.

No they don't take time slices from main thread, because since it uses one core at 100% the os will dispatch one core only for that. Other threads work in time slices on other core, but since those have very low cpu usage, those extremely tiny queue times not causing measurable slowdown.
By the way, it's easy to to test how much those more cores helping on rw, by setting core affinity. I've disabled two of the 4 cores for railworks, and the slowdown that i noticed was exactly zero...

Windows surely bounces threads on cores, since the task manager shows equal core usage when i running a test application that i've made, so i'm sure that uses one core and no more http://forums.uktrainsim.com/viewtopic. ... a#p1524105
Someone in some topic linked an article from intel about this windows task manager faked cpu usage graph, and a recommendation for a better system monitor made by intel.

[peterfhayes]

There may be another aspect to performance with TS2102. Using VMMAP and monitoring TS2012 you see the Virtual Process (Address) space becomimg more and more fragmented and the contiguous block size becoming smaller and this is much worse and occurs earlier on some routes WCML - NEC for example (on my machine anyway). Certainly in a lot of games performance may be affected if the VAS is fragmented and/or there is not enough contiguous space for the code to be loaded into. So the "bottleneck' may well occur before the cpu (ie at the OS level) and be compounded when the cpu passes the working set into RAM. I'm not saying that this is the primary cause but it may contribute as to how performance hits can occur.
The Video card setup could also affect performance with TS2012 by not allowing the application to use its own settings but overriding or modifying them via the various control panels and this may result in code having to be sent back across the motherboard to the cpu/RAM and back again.

Its a complex issue and I'm sure that, threads, heaps and stacks also play a major part. It would be interesting wrt to threads to see if there are performance gains or losses with Hyperthreading enabled or disabled. Certainly in some software thread clashes occur when HT is enabled.

Very interesting post
PeterH
PS ShanyQ

since the task manager shows equal core usage when i running a test application that i've made

Unfortunately the task manager is quite poor at showing core usage as it use alogirithms from way back prior to multicore systems the best way to monitor core performance is using the Intel Performance Counter Monitor app: http://software.intel.com/en-us/article ... r-monitor/. To rely on the task manager may give a false impression as to what is really going on multicore wise.

[paulz6]

The helper threads will inevitably take time slices out of the main threads activity. The more cores you have to process these active threads will reduce the chance that the main thread will end up waiting in the run queue. So a hex core will run RW better than on a dual core as the main thread is going to spend less time run queue.

No they don't take time slices from main thread, because since it uses one core at 100% the os will dispatch one core only for that. Other threads work in time slices on other core, but since those have very low cpu usage, those extremely tiny queue times not causing measurable slowdown.
By the way, it's easy to to test how much those more cores helping on rw, by setting core affinity. I've disabled two of the 4 cores for railworks, and the slowdown that i noticed was exactly zero...

Windows surely bounces threads on cores, since the task manager shows equal core usage when i running a test application that i've made, so i'm sure that uses one core and no more http://forums.uktrainsim.com/viewtopic. ... a#p1524105
Someone in some topic linked an article from intel about this windows task manager faked cpu usage graph, and a recommendation for a better system monitor made by intel.

I've got to admit, my knowledge is ancient, and it is over ten years since I looked at a kernel source code. I will ask you this simple question: How does the O/S know what is a main thread, and how does it know that it is better stack helper threads on spare CPU's, and keep the main processing thread on one CPU? In fact, how does an application know it is supposed to be the main processing thread anyway?
Why is windows bouncing threads between cores? I'm sure it does it just for the sake of it. Hey, I'm going to save the state of my registers and pass that along to the next CPU just for the fun of it.
As for process CPU binding, unless you unbind all other process threads from it, you will probably find a spare CPU doing nothing as the main thread cannot use it, and the bound CPU is busy processing some other thread.
Fundamentally, a kernel scheduler sees a number of processes that wish to run. It will allocate a thread based on a priority algorithm to run on the next available core. That thread will either finish its task and give the CPU up voluntary, or it will exceed its timeslice and will be forced off the processor involuntarily for the next prioritised thread that is waiting in the run queue. Some O/S's will even record these statistics so that they can be monitored using various tools.
Like I say, my knowledge is rather ancient and technology moves so rapidly that even the most experienced of people working on multi-processor systems should feel out of their depth.

[gptech]

All very clever and complicated stuff, but have you tried going back to basics?.... just the one card installed, drivers that came on the CD with it installed?

[sdark2]

gptech, the answer is still the same when you asked on page 1 of this thread lol > http://forums.uktrainsim.com/viewtopic. ... a#p1532515

Even tried it with a nice clean os and the result is still the same (in fact, it was the first thing I tried when I installed the os from scratch).

Kr, Steve

[gptech]

Hey, cut me some slack--I'm old and you can't expect me to remember that far back

I admit to only having half an eye on this thread too, my experience of SLI is very limited---not much call for it on machines crunching spreadsheets or firing off e-mails all day long, though your problem does defy all logic. If it was hardware related you'd expect it to manifest itself across the board but as you get excellent results in other games.....
Unfortunately you haven't the 'old' cards to drop back to to check that they still work, though as you've done a fresh OS install any 'old' configuration would be lost too. The 560Ti should handle RW (mostly) without trouble, regardless of whether you've an AMD or Intel CPU. The possibility of having a 'rogue' card is rather blown out of the water by you having a pair...1 duff card is a bad bit of luck, 2 is nigh on impossible!
Any chance of slipping one of the cards into a friends/unwitting guinea pigs PC to test it?

[sdark2]

lol your memory sounds just as good as mine! What day is it again???

I had managed to pinch one of the old 9800GTX+ cards off my mate to sneak back in... out of the box, and default configuration, I was back to 30fps performance without any form of tweaking. Which was rather interesting given I'd had 3 of those in the machine before. The way it comes across, it's almost as if Railworks is actually ignoring the fact I have a graphics card at all when either or both of the GTX560Ti's are in.

I had ruled out the possibility of a faulty card, or even the motherboard and RAM, with the burn in tests I've managed to complete without failure. Any fault with the hardware at all would result in the system becoming unstable or even failing completely - that's certainly not the case. The system is solid as a rock with everything maxed in terms of loading of cpu, ram and gpu(s) - not had even one BSOD.

Kr, Steve

[gptech]

I always seem to get confused on Wednesdays.....

I had managed to pinch one of the old 9800GTX+ cards off my mate to sneak back in... out of the box, and default configuration, I was back to 30fps performance without any form of tweaking. Which was rather interesting given I'd had 3 of those in the machine before. The way it comes across, it's almost as if Railworks is actually ignoring the fact I have a graphics card at all when either or both of the GTX560Ti's are in.

Time to drop Asus support a line?----probably a bit academic as the cards perform so well with other titles, but surely can't do any harm?
What we, or rather you, need is somebody running the same (or similar) card in a single configuration to chip in with their observations--- I honestly cant see it being down to a conflict between your CPU and the GPU, nor the motherboard given your figures in other apps/games.

[Kariban]

I have thought from the start that the game is not talking to the card - is that a DX ( and therefore driver ) issue perhaps?

[sdark2]

Already done and awaiting a response... however, given everything seems to function properly, I'm not sure what they could suggest other than replace the gpus... the motherboard is past its warranty so I would have to buy a new one (or if anyone feels the need to donate a decent one... with a decent cpu? )

I did go to nVidia directly when I first suspected that there may be an issue with SLI and my cpu or even just one gpu and my cpu - which, and I actually thought I heard them laughing, there wasn't any such. They did indicate (as I interpreted) that in some cases the throughput required by sli could put my cpu under significant load which MAY result in a performance drop out, although it was highly unlikely.

In my view the result is fairly conclusive, as said repeatedly, we can rule out a potential hardware fault - I cannot say with any degree of certainty that my cpu isn't the limiting factor when it comes to railworks - as our recent, fairly technical, discussion revealed, it is a very real possibility. However, until I can raise the funds to buy a new one, it will have to be "best guess" as to what the cause is until it can be proved categorically that railworks does or does not perform better with a higher rated cpu than what I have.

Kr, Steve