Quote from Scawen :

As mentioned, I can reproduce high CPU usage when minimised, after ALT+TAB from full screen vertical sync.

Perversely, my Win XP box now behaves better with vsync than it did with 0.6H. If you recall, I saw CPU usage rise to a full core's worth any time I used vsync, despite the rate-limited 60 fps CPU load being really low. NOW, with H5, I'm seeing "normal" CPU load with vsync while driving, and it also doesn't rise when I minimise with alt-tab. (I forgot to try windowed mode - my testing so far is all full-screen.) Perhaps this will help you to understand what's going on!

Thanks for explaining the sleep/phys/wait columns btw - that helps a lot. I had a somewhat confused idea of what they meant Will look at them again tonight with my new understanding.

Quote from cargame.nl :

some copper heat transfer shafts

Those are actually heat pipes Dave - the copper is all but irrelevant.

@matijapkc: I'm surprised your GPU is still alive, if that temperature (127.5°C) was accurate. I thought that would kill pretty much anything. I would therefore suspect a bogus temperature display.

I haven't had a chance to test the new patch myself, but it does seem pretty clear that it puts more load on the GPU. I still believe that this isn't in any way a concern for LFS though: all PC kit (CPU, GPU, whatever) should be self-protecting - e.g. throttle back when over-heating occurs.

Sounds good - looking forward to testing. (And thanks for clarification on Sleep() calls.)

I've seen Firefox do really bad stuff to my laptop as well. Not sure how/why...

I may well be misremembering/misunderstanding how Windows scheduling works. But... I really do doubt that the Sleep() is necessary at all.
IIRC, it used to be that as long as an app is doing a PeekMessage() or similar (or its modern equivalent) now and then, stuff just works.

In this direction, how about trying something like
if (minsleep != -1) Sleep(minsleep);
and of course allowing the user to reduce min. sleep to -1?

Then people could see what happens when the Sleep() doesn't happen.

Quote from Matrixi :

Quote from Neilser :

Input lag: surely this isn't noticeable with vsync on, even at only 60Hz refresh?

It's easily noticeable, atleast on FFB wheels.

Not to mention VR headsets.

I use a G27. At 20fps (frame rate limited) I can certainly observe input lag. At 60 fps, I personally can't.

Quote from loopingz :

Yep input lag is mainly a monitor issue. It is impossible to feel if you are spectating but behind the wheel you will notice. Some monitors are above 100ms and it is way too much.

If you're spectating, there is NO input, so lag is impossible by definition, so I think I don't understand your point.

Quote from DANIEL-CRO :

1. Frame

(get wheel data)
-1. physics calc

2. Frame

(get wheel data)
-2. physics calc
-3. physics calc (same input data is used)

3. Frame
...

Thanks Daniel - nicely put. However, I would say that having multiple physics calcs with one input setting isn't by itself a problem; rather it's having too long between fresh fetches of the wheel data. I personally don't think 17ms (i.e. 60fps) is too long.

EDIT: why not get wheel/controller data and do the physics updates at the same rate? (100Hz right now, I believe.) That intuitively feels like the right thing to do. Reading the inputs each time the display updates seems... wrong. I would hope, perhaps incorrectly, that it's not a major code change. (I know this has been discussed in the past but a quick search didn't find me the threads in question.)

Last edited by Neilser, Thu, 23 Jul 2015 16:58.

Quote from Degats :

An interesting input lag investigation with V-Sync vs no V-Sync, FreeSync vs G-Sync at different target framerates: https://www.youtube.com/watch?v=MzHxhjcE0eQ
Jump to ~ 11:40 for graphs, although there is some interesting stuff earlier in the video.

Interesting results. VERY hard to make sense of 'em though!

My thoughts on the last several posts:

• GPU overheating - IMO, no need for the game to fret about this. In any case, why would high fps be any different from low fps but much higher workload per frame? Users can choose how how hot to run their GPU, and whether or not to impose fps limit. Having said that, I have never seen the point of very high fps (e.g. > 100)
  
• min sleep: firstly, as Scawen is probably aware, Sleep(0) does actually do something (it ends the process timeslice but leaves it ready to run). I *think* that on a pre-emptive multitasking OS, LFS shouldn’t need to do this at all. Scawen - do you remember which OS gave the trouble? Unless it was pre-NT it shouldn’t have happened... I'd be keen to see if totally removing the Sleep() call does anything bad on any machine.
  
• Furthermore, Sleep(1) should be barely distinguishable from Sleep(0) - provided I'm correct to think the Sleep is once per frame. Even if frame rate is only (say) 60 fps, then it’s going to sleep for 1ms in every 16.7ms, thus barely noticeable... Only someone who is (pointlessly! ) running at more like 200+ fps is gonna see a significant fps drop.
  
• Input lag: surely this isn't noticeable with vsync on, even at only 60Hz refresh?
  

In some old thread, I came across Scawen explaining why it's there - to allow Windows to do a spot of message handling etc... Well, that explains the presence of the sleep, not the fact that it's a user-settable parameter. Indeed, other games don't expose such an option.
(Last time I programmed a time-critical Win32 app, there was only one CPU to deal with so I'm not sure about this but you'd really think that most systems today could handle LFS never yielding at all, provided they have multiple cores... But maybe that's now how Windows works.)

No worries. (In fact, music to my ears!)

Good stuff, sounds promising!
Meanwhile, is there any mileage in the band-aid that Dave proposes, i.e. releasing a decimated version of Westhill?
(Only worth doing if it's semi-trivial for you guys, which I'm hoping it would be.)

Is 1366x768 any better?
I would also suggest lowering or switching off the various graphics options to see what helps, e.g. texture quality, sky, shadows, mirrors, whatever else you can see.
For me personally, AA is about the only option I don't like doing without - apart from that it's all about the driving and for that I'd rather have decent fps than gorgeous images Without AA, the visual jaggies are distracting.

Wow, I had forgotten that existed. 2008: "hopefully LFS will have this function in the future"
Indeed, wd be useful to have it built in.

Holy crap. H4 is now installed. After a race a moment ago, I got this weird music in my ears for the first time ever!
Whatever you did Scawen, it made the music work on my PC and I don't ever remember hearing it before...
(I turned it off again mind you, cos it's, em, awful )

Quote from cargame.nl :

Quote from Neilser :

Depends on the track of course - the OP didn't mention which track(s) were tested.

Let's not spread disinformation!

He did. South City open config. I don't believe you achieve 100 fps @1280x1024 there with AA on with a GPU which scores 120 Passmark. 30 FPS would be amazing.

Umm, lol, he actually said CityDriving. That meant nothing to me as a non-cruiser

And I just tested three things: SO1 w/o open (typically 170fps, didn't see lower than 140 fps, sometimes 210fps), SO1X (surprisingly, very similar :O) and then the actual CityDriving server, which was almost full.
With a whole bunch of other cars I did indeed get lower frame rate, but still over 100fps almost all of the time, and often over 150 fps. I saw a couple of moments where it fell to 40ish fps, just after I joined the server, but after that I didn't see anything less than 60.
This was all at 1280x1024, 4xAA, 4xAF, quite a few other settings on low or off (too many to list).
I tried 640x480 but it didn't seem to make much difference (despite the CPU not quite being pegged.)

Also, I may have been too generous when I said my card scores around 120 on the Passmark G3D benchmark. It's an X1650XT, which is not listed in their chart; the highest score for any similar card they list is an X1600XT, which scored 110 (dunno where I got 120 from) with all other X16xx variations being lower.

Last time I personally ran their benchmark (in May) it only scored 19 on G3D (!!) before my £8 ebay CPU upgrade - I swapped out the E4300 for an E6600 (both Core 2 Duo). It then scored a massive 44 with the E6600... I didn't mention that because I'm not convinced the Passmark suite is really running properly, and I have seen big variations in multiple parts of the overall system score on repeated runs on an unloaded machine.

Perhaps you are amazed now...
Either that or you still won't believe me!

Quote from racerss :

...just 40FPS :o

I use 1920x1080

Quote from Eclipsed :

You shouldn't compare if you use resolution with half as much pixels to be drawn...

Agreed - it's well worth testing with a resolution more like 1366x768 (which still ought to be good enough to see what you need to see )...

Quote from cargame.nl :

It's quite normal. Intel is nothing when it comes on GPU performance. Just look at the 3DMark benchmark results.

Or even Passmark for a quick comparison; http://www.videocardbenchmark.net/gpu.php?gpu=Intel+HD+4600

Gosh, you really don't like Intel integrated graphics Dave
Benchmarks are never quite the same as any given application, but they can be useful guides.
In this benchmark the HD4600 scores around 720. My current GPU scores around 120 - 6 times lower - and yet I can get way over 100 fps most of the time (1280x1024) with AA on, and frequently over 200 fps (so I mainly now limit the frame rate). Depends on the track of course - the OP didn't mention which track(s) were tested.

Let's not spread disinformation!
The posts from the people who actually own systems with Intel HD graphics suggest that this really isn't normal. And HD4600 is much quicker than most of the other HD flavours...

Quote from Eclipsed :

Sounds like lags,as LFS client receives packets with car locations that are different then your client calculates to be from normal full throttle acceleration.

Quote from Neilser :

Hmmmmmmm, OK, I will compare with other cars in the replay to make certain the "hacker" had implausibly good acceleration and/or speed.

Phew, you had me doubting myself I've now checked carefully. The particular hacker I saw a couple of days ago was NOT reaching stupidly high speeds, but his car was repeatedly hopping forwards while he had the throttle on, but never stepping backwards under braking (or sideways while cornering) - not consistent with lag. Also his engine note and speed reading were hopping around while this was going on, and finally his forward/backward acceleration reading (F9) was generally -0.1 or more (i.e. accel backwards) even while accelerating forwards, and while other cars he was keeping pace with were showing small positive readings (e.g. +0.03). So yes, I'm very very certain he's hacking, though I don't know how.
However, I don't think "speedhack" is a very good name for what he's doing - maybe "positionhack" is part of what's going on.
I also found older replays with hacking going on: some had the same guy (different car); another had some other idiot doing the same stuff but in a much more exaggerated fashion so it was really unambiguous (crash, then catch and pass quick cars one corner later, plus reaching silly speeds). I didn't check which LFS version was in use for each of these replays (is this possible?).

Quote from Gutholz :

I do not know details about this in LFS, and imo no point to discuss it too much.
[snip]
(I think this is quite vague but if a mod thinks this should not be discussed then just delete it. I think sometimes players wonder how it is done and that gives cheaters way too much 'respect' or attention for their nonsense.)

Indeed, I know how hacking works, in general. However it's much easier to cheat if you don't have to make it work online, in communication with both a master server and a remote dedi server over which you have no control, and which ought in principle be able to detect rather a lot of your trickery. I'm surprised and a bit disappointed that the LFS server can't detect these cheating clients.

My motivation to discuss it at all here is primarily to help us get rid of it. Understanding how it works is also of interest to me (as a programmer) but I don't want to assist others to hack. I suspect though that anyone who looks hard enough will find "script kiddie" answers out there, as you say, so discussion here shouldn't hurt the LFS community, though providing excessive detail about how the hack works probably wouldn't be very prudent

Hmmmmmmm, OK, I will compare with other cars in the replay to make certain the "hacker" had implausibly good acceleration and/or speed. He did claim it was lag, LOL.

However, I could swear I read somewhere in this forum that LFS transmitted position, speed & acceleration in the position packets (and maybe the 3rd derivative of position too), in which case that shouldn't happen. It could only happen if LFS only used position and speed...

Quote from Draggo :

This currently speedhack add some "power" to engine, it using Engine Damage to do it. Default value is 1 (the engine is not damaged). In normal situation this value aims to 0, but when someone want to use it as a speedhack he must incrase value (and lock it). So value 1.2 = +20% to engine power.

This fixed speedhack was added rotation to wheel spins.

OK, thanks. How did you find this out? (Regarding either of these techniques.)

I'm confused about the engine power idea - what I've witnessed recently didn't look like a steady excess of acceleration (or speed), but more like a fairly regular supply of small "bumps" in speed, almost like the car was repeatedly being bump-drafted by an invisible car. (This was typically around once per second or thereabouts; sometimes quite a bit slower.)

This post https://www.lfs.net/forum/post/199832#post199832 says you can do it yourself if you buy some skin slots.
Edit: current rate seems to be 50 skins for £1. Bargain, really.

Does anyone know how the speedhack actually works?
A quick google (and search on here) didn't find much useful info - some people claimed (way back in 2008) that the master server was fixed to stop the hack from working.

Not sure how many cycles of hack and patch there have been since then, but the hack is working at present.
I've seen people speedhacking in the last few weeks, in a really unsubtle way which made it massively obvious that they were doing it. (This was mainly on the CG servers, which I believe are all 0.6H.)

I'm intrigued to know how it works, from a programming point of view.
However, I'm even more intrigued to know why it hasn't been permanently fixed - is there something impossible about it? That would be a real shame, though it's hard to believe we couldn't find a way.

My fear: if someone does it subtly enough they will go undetected...

Quote from cargame.nl :

Same reports about FPS but the "screen is lagging" so much its a pain for the eyes. (and yes I again configged LFS_H to thread 7 and other CPU consuming programs avoid this thread).

I'm certainly confused about your "lagging screen" problem - have never seen anything like it (the key bit being that the fps indicator doesn't drop). That DSLR vid (or even mobile phone vid! ) you thought about making would perhaps help.

Btw, your CPU affinity settings just might be making things worse... (If you want to confirm the thread is consuming the equivalent of a whole CPU there are other ways.) You may want to see how it compares without being pinned...

:Really:

Quote from MandulAA :

Yeah, quite surprising but it's real - it has a slot called "UltraBay" and it's possible to buy either a HDD, an additional fan or a graphics card (GT650M or GT750M) that works together with the primary graphics card in SLI - so I have a GT650M in it.

Mmmm, nice. I don't like burning my lap, but getting an extra fan would be... just tragic I love that you get to choose whether to make your lap hotter or colder!

Quote from Scawen :

The best SLI setup is where one card does one frame and the other card does the next frame. So there has to be good overlap, to get any benefit.

Ah hell, yes, I was thinking of the original meaning of SLI (scan line interleaving).
Thanks for those links. I see that the closest thing to interleaving is nowadays called SFR (split frame rendering), at least by nvidia.
I can totally understand why lag could be an issue with AFR (alternate frame rendering); in fact I can't see how you could possibly avoid it cos lag is basically built into the process when you are rendering two (or more!) frames in overlapping time periods.
I'm inferring that if two rigs with identical CPUs have the same frame rate, but one is using SLI-AFR and the other has a single GPU, then by definition the SLI-AFR rig has more lag between the physics calculation and the pixels hitting the screen. That seems kinda sucky, and I would've thought it only stops being noticeable at high enough frame rates that you could get by with just one of the SLI cards anyway... Edit: Better way to put that: an SLI-AFR rig has exactly the same input lag as with only one of the GPUs doing any work; the only benefit is more frames per second which is a totally cosmetic improvement and will not help to keep you on the road...

So yes, please don't waste your time on making SLI-AFR efficient with LFS [Caveat: your idea about off-loading work from the CPU to the GPU is a special case where you might indeed reduce lag. Complicated shiz...]

Quote from Scawen :

Not only could it take months, but due to a historical mistake, I have two separate versions of LFS, a development version and a public version. I have to manually merge in all the changes from one into the other.

Ohhhhhh..... I'll say nothing. (But Victor, if you're reading this, we need a smiley for sucking teeth )

Last edited by Neilser, Fri, 3 Jul 2015 19:52.

Quote from elpopu :

Solucioned!

Thanks

Excellent! You're welcome

Quote from Eclipsed :

Quote from Neilser :

Not sure why the panel at the bottom (e.g. fuel) is blank... Seems odd.

Same thing - database also needs some previous data for fuel calculations.

Ahhhh. It's sensible that the laps-remaining calculation can't be done, but the actual fuel level should really be displayed...

Btw, elpopu: I'm still using Aonio cos I'm lazy, but (pun intended!) the LFSLazy insim is probably a better thing to get started with now, mainly because Aonio isn't updated any more and if I remember correctly, it has issues with the new Westhill. I will get around to trying it soon, but it's taking me forever mainly cos when I have time to drive, I just want to drive

If you're worried about the lack of info in the panels at the top of the screen, then you might need to do a couple of laps first (so, for example, it has a PB time to compare with). Not sure why the panel at the bottom (e.g. fuel) is blank... Seems odd. Are there error messages in the Aonio window?