Quote from Niels Heusinkveld :

I find it nearly impossible in sims to get smooth braking done while blipping the throttle. And looking at video's online from real cars, I just don't believe that their brake pedal force doesn't go up / down a bit when they heel and toe.

You're 100% correct in that assumption, how much the brakes fluctuate depends greatly on the brake system of the car though (like Shotglass said, tubing is one of the big keys).

Last edited by der_jackal, Mon, 15 Jan 2007 01:16. Reason : Someday spelling and I will get a long. Until then, there is an edit feature!

Quote from spankmeyer :

Probably not or they are in the threshold of just lighting up.

Actually they do in the case of the V8 Supercars. If I have any time this week I'll pull a chase camera shot and you can see where they just blip the brake lights for a second as they tap the brake pedal.

Quote from tristancliffe :

OMG, an American who knows correct driving techniques! Whatever next? *runs away*

*shakes fist*

WHY I OUGHTTA......

Last edited by der_jackal, Thu, 21 Dec 2006 19:37.

Quote from mikey_G :

Still dont really understand. Does this maneuver have a name, so I can google it or something?

Not really...it's just something they do, I wish I had tivo'd some of last year's American LeMans series. They showed a full lap of MidOhio with a Porsche driver doing the same thing, and they gave a really great explanation of why he was doing it in some areas where loading the suspension wasn't really required (which is why you would normally do it on a long straight. Big bump you tend to trail brake to load the suspension so you keep the car settled *g*).

Easiest way to think of it is; The pads and pistons are vibrated, shoved and pushed around while racing. The pads in those V8 Supercars "float" in the caliper so they can be changed on the fly (required in some races) and as such they can be pushed back farther from the rotor face or move around just ever so slightly to where they aren't "true" to the rotor face.

What that technique does is just pushes the pistons in the caliper lightly forward, seats the pads to give maximum coverage and ensures the whole braking system is primed to work as they need it.

Quote from mikey_G :

Nice vid, but why does he tap the brake on the straights? Is it to get the brakes warmed up a bit?
He has quite some thottle travel btw

Yup, there's a light tap just prior to entering the braking zone, but it is to make sure the pads are snug and close to the rotor surface.

Last edited by der_jackal, Wed, 20 Dec 2006 20:14.

When all else fails a little video will help guide you.

Sorry I don't have Mark Skaife doing it around Bathurst...so you have to settle for Todd Kelly
http://www.audiworld.members.w ... Panorama_lap_footwell.wmv

Last edited by der_jackal, Wed, 20 Dec 2006 04:55.

MCE + Transcode 360 + uTorrent + Racing-Underground = Streaming racing from around the world 24/7 on the 360.

There are a couple of good games for it too.

997 GT3 RSR around Bathurst (Mt. Panorma) while closed to the public.

- or -

DBR9 around Spa.

Quote from mrodgers :

Do you heel/toe using your heel on brake and toe on throttle or the other way around. I tried using my toe on the brake and had to completely rotate my chair around to hit the throttle with my heel. The other way, heel on brake, would completely mess up the braking feel.

How about we let Todd Kelly show you how.

Patience it's a hefty 26MB file.

Quote from Cue-Ball :

. Also, because of the way the stick has to be pushed down for reverse, it's easy to put too much pressure on the stick and get it stuck between gears.

Welcome to Volkswagen / Audi-Land, at least the Logi shifter reverse is off of 5th / 6th gear gate, try going down to first and fearing a reverse engagment....

But then again, the ease of pushing down during actual usage in the Audi isn't that light. :P

Quote from P5YcHoM4N :

There is a slight difference between what Forb is saying and what you're reading.

For software to make use of multiple cores, or even multiple cpu's, it has to be programmed to do so, otherwise it will continue to do what processors currently do. Trick the user into thinking it is multitasking. Each clock cycle happens so fast no human will never notice it, my typing this has just ran of a hell of a lot of them.

That's vague at best, what processors do is what they are instructed to do.

Again, any and all mutlithreaded applications inherit the usage of both cores from the OS. Again, any application (which is multithreaded, as you're hard pressed to find any commercially available software today that ISN'T) inherits the use of multiple hardware threads via the OS. Anytime an application calls CreateThread from within its execution space, the OS determines what hardware thread it goes to.

For an application to be OPTIMIZED for multiple hardware threads it has to determine and then set Affinity for the hardware thread executor it wants to use for that thread, and for it to really be optimized (ensure 100% CPU utilization on both cores) it has do more to guarantee those threads aren't stumbling over each other for shared resources (amongst other things)...but more on than that later.

CPU clock cycles don't have much play other than they are the basis for the thread quantum (which is 2 clock cycles on Win2k and above, or 12 if you're running Server platforms btw). However a high priority (DPC - High / RealTime) thread will run until its completed regardless of the quantum.

Ever had your single core system "stall" or "hang" for a second or two while something was running? Generally you were the victim of a high priority thread running until it was done, which in turn stalled (on queue) all other lower priority threads (keyboard input, mouse input, etc).

Lower priority threads run on that quantum, they are scheduled, run until they are done, interrupted by a higher priority thread or their quantum is reached. If their quantum is reached or they are interrupted, the context is stored off, and the thread is placed back on queue until its turn comes up again. The vast majority of user mode software runs at < Dispacth Level (Levels go from 0-31, 0 being the lowest, 2 being Dispacth)

Quote from P5YcHoM4N :

By switching processes out from one to another it gives the impression that it is multitasking, but in reality it is only running one at a time. What windows does with two processors is the same thing but over two cores. It can run two tasks at once, but still does the same thing, swops out the process to give the impression of multitasking. If a process isn't a real multicore process in task manager it'll use a 50-50 split, a true multicore process will use 100-100.

Are you thinking only 1 thread can run at a time and that the OS is using parallel processing to split that thread across both cores? Actually not how it works.



Each core was processing a different thread at the time of death (each core is noted by the n: kd>). And actually core 0 was in an idle state when the BugCheck happened.

So, you have three threads on queue. All three w/ the same priority level. All three from one appplication. Thread Scheduler walks the queue, finds that thread1 is in a ready state, sees that processor 0 is running the idle thread, and submits thread1 to processor 0. Scheduler returns to the queue, sees thread2 is in a ready state, sees processor 0 is busy and the thread quantum hasn't been reached, looks at processor 1, sees it's idle and submits thread2 to processor 1. Scheduler walks the queue and sees thread3 is in it's ready state, looks at processor 0, sees that thread1 has reached its quantum, stores the context off for thread1, places it back on queue and starts thread3.

Scheduler walks the queue and sees that thread1 is in a ready state, looks on processor 0 and sees that thread3 hasn't reached it's quantum, looks on processor 1 and sees that thread2 has reached its quantum. Stores the context off for thread2, drops it back on queue and submits thread1 to processor 1. Meanwhile, thread3 completes and unloads, the Scheduler is notified, walks the queue, sees that thread2 is in a ready state, submits thread2 to processor 0.


Your perception about how it works based on processor utilization shown in task manager is kinda of skewed. Multiple processor utilization issues are generally bound by the threads stalling for synchronization objects. I.e. there is lock being held on one thread for a resource required on the other, anything causing contention will limit CPU utilization across two cores.

Thread[0] = CreateThread (NULL, 0, Foo1, &Param1, &Thread1Id);
Thread[1] = CreateThread (NULL, 0, Foo1, &Param2, &Thread2Id);

WaitForMultipleObjects (2, &Thread, TRUE, INFINITE);

Unless stalled by higher threads, Thread[0] will run on processor 0, Thread[1] on processor 1

If Foo1 calls or holds any synchronization objects for a chunk of memory, those two threads will be in constant contention and subsequently stalling until the contention is released.

There is one way you reach 50/50 processor utilization. An optimized MP/MC application will clear / reduce those contentions as well as define processor affinity for the threads which is where you will see closer to 100% utilization.

Quote from Forbin :

@der_jackal: That's beside the point. A single-threaded app (I suppose we could call it "a program NOT designed to run on multiple cores/CPUs") will run on 1 core at a time. There is no way such an app would be running on 2 cores at the same given point in time and the fact that the scheduler switches the program between both cores is irrelevent. I'd be appaled if such load balancing was not in place.

I notice I made the same exact point in the other thread...

And I believe I answered you in that thread, LFS is not a single threaded application, you'd be hard pressed to find any game today that is single threaded.

http://www.oreilly.com/catalog/multithread/excerpt/ch01.html

From
Win32 Multithreaded Programming

By Aaron Cohen & Mike Woodring
1st Edition December 1997

So what is multithreaded programming? Basically, multithreaded programming is implementing software so that two or more activities can be performed in parallel within the same application. This is accomplished by having each activity performed by its own thread. A thread is a path of execution through the software that has its own call stack and CPU state. Threads run within the context of a process, which defines an address space within which code and data exist, and threads execute. This is what most people think of when they refer to "multithreaded programming," but there really is a lot more to programming in a multithreaded environment.


But if I understand you right, you're telling me because LFS's main thread is on processor 1, so any subsequent threads are also launched on processor 1? Or that LFS runs all its threads in a synchronous order and they are all run on the same hardware thread as the main LFS thread?

Meaning Thread1 is launched, LFS waits until it's completed and then Thread2 is launched...

Or...?

And the misconceptions abound...

Whether you like it or not, every piece of sotware will make use of both cores, the Windows thread scheduler / man ... ts management conditions.

Quote from TiJay :

Jackal: Looks expensive

It was JUST over the expensive line..which brought it right in the Wife asked twice, "You paid HOW MUCH FOR THAT?" area....

F'eh, if you're going to do it, do it right.

Quote from Hyperactive :

After seeing that vid I can perfectly understand the point that LFS tracks are too flat. Though that track seems very bumpy.

Sebring's pretty bad, but yes, LFS tracks are a little too smooth.

I'm sending out a meeting request...

the subject of the meeting; I told you so.

Quote from Aquilifer :

Yes, heh heh. I realized it too when studying it more after i wrote the message but was too lazy to do any editing

Figured, it's just a pet peeve I'm suffering lately.

Quote from Aquilifer :

Targeting? You mean processors? Nothing. It lets OS choose them as it sees best. Actually i don't know how this is understood in HT CPU

Ahh, see you're not really doing anything different than what LFS (or any other normal application) is doing currently. Just spawning threads and waiting for them to complete. There you will see an increase in performance gains, but you would probably see even more in an optimized environment (this really depends on the "weight" of the threads in your app).

Targeting specific processors would probably yield some different results, both bad and good depending on how you did this.

HyperThreading is really more of a product of the processor, programmatically you'd access both thread executors the same way (GetProcessorAffinity, SetThreadAffinity, etc.).

Quote from Aquilifer :

And the idea in the data was just to show what kind of improvement you can expect in this kind of machine. So that people don't think it is 2x (100% improvement).

Good point.

Quote from Aquilifer :

Splitting a screen calculation is actually quite simple, but some jobs can be really hard to split.

Yup yup! Part of design is determining what you can and can't split off and how best to load balance between the hardware thread executors.

Quote from Aquilifer :

Yes. And using the highest is not really recommended.

Oh lord no, running at level 31 ("real time") is a huge system blocker, but running at 2 (DISPATCH in kernel land) would prevent you from being interrupted as frequently by threads with lower priorities, but you also block any of your other threads which you have affinity for that processor from running on that processor until your thread is done.

Quote from Aquilifer :

Actually this conversation makes wanting to try little bit more testing

But maybe this conversations is not for this forum

Maybe we should spawn a thread in the programming forum (pun intended).

Quote from Aquilifer :

The only sensible way to make it 'multi processor friendly' is to use multiple threads. That's my opinion. That has the best changes to work correctly in most situations and with least amount of work.

How much you benefit from multithreading depends on the 'job' you are trying to split. Some jobs are are really not so easy to split into multiple threads (or that they would benefit from it). I've made few multithreaded apps. If you are really interested i got these results for my fractal program calculating a picture:

threads time relative
--------------------------
1 8.032 100%
2 6.625 82%
3 6.281 78%
4 6.110 76%
5 6.265 78%
6 6.266 78%
7 6.141 76%
8 6.172 77%
...
After 3 threads it is not getting any better, so it seems. (if the difference is significant between 2 and 3 threads is in doubt, even though the times are averages over multiple runs).

I have Hyperthreaded P4 2.8GHz(Northwood) (1 core). I haven't had change to test on 2 core system.

The only processor aware thing i would try to do is like, HT CPU ->2 threads, dual core->4 threads etc...

I hate to nitpick here, but LFS is a multi-threaded application already. What LFS is not, is optimized for multiple hardware thread environments.

Interesting data...

How were you targeting your threads? I'm assuming you were using SetThreadAffinity, but what priority levels did you have your threads set at?

You have to remember the Windows scheduler works on a quantum, if your threads are set at lowest level they will be interrupted more frequently by not only higher priority threads, but all other threads running at the same level as you.

Quote from Blackout :

Those were the good days of Montoya, they are gone now.

He was good when he actually cared about racing. Too bad F1 (and McLaren) have taken all the fun out of it.

/Said the thread; "I'm not dead yet...I feel happpyyyyyyy"

Quote from Christofire :

Have any of you chaps done any multithreaded programming?

I have (and do), and I don't get to choose which cpu/core/etc the thread runs on - you create the thread and leave it to the operating system (in Windows, at least).

...<snip>...

Nope;
SetThreadAffinityMask

CAD/3d, Photo editing, auido and video editing tools have been targeting specific processors for years. Some games have as well; Quake 3, Quake 4 (with a patch), Tribes2, Serious Sam, and Serious Sam 2 are multi-core/proc "aware" (there are a quite a few more, but some require command line args eg; start /jediknight.exe +set r_smp 1).

But quite a few game engines being created now are going to be multi-core/proc aware (CryENGINE2, etc.).

Quake 3 had limited support for SMP, meaning it would do some work to queue threads on to specific processors, but it did not really take full advantage of the power of the system (I have feeling he was still seeing a bottleneck from the AGP / GPU side). Serious Sam 2 on the other hand is a great example of a multi-core/proc utilization game engine.

You're right though, one big problem with specifying thread affinity is load balancing. If you're throwing threads down to CPU1 and overloading it compared to CPU0 you're going to find yourself in a world of performance hurt. You can generally uncover such a hit during testing, make a small tweak in the threading model and voila. Either that or create a dynamic load balancing engine...*shudder*

Quote from Forbin :

I suppose it may be possible that LFS could switch between the cores

If you walk away with anything from this, it is that LFS has zero say in the matter of what processors execute any given thread at this time.

Quote from Forbin :

...but it won't run on both at the same time. Like most games, it's a single-threaded app.

It is?*








*hint: no, it isn't. The terms single and multithreaded have no direct relationship to the number of processors the application was written for.
A quick primer http://www.oreilly.com/catalog/multithread/excerpt/ch01.html

Quote from DEVIL 007 :

This might work if you were running in background aplication which takes a a lot of CPU time and it will work also with running virus scanning in background.

LFS cant utilize 2 cores because it isnt programmed for that.Simple as that.Give me a proof.

I am not running any *shit* in background so I have more then high doubts that dual core would give me more FPS.

So I tell you what, prove to me that 100% of LFS threads are only running on ONE processor / core.

REread the post. I never said LFS was the one utilizing both thread executors did I?

LFS is no doubt a multi-threaded application, the OS schedules those threads out to processors as they become available. Sometimes they go to CPU1 sometimes they go to CPU0, sometimes...*shudder* two threads can go out at the same time to CPU1 and CPU0!

If you want to deny the usage of an executor to an application, establish processor affinity for that application. Or go ahead deny that processor to pretty much everybody and create an app that runs an infinite thread at DISPATCH_LEVEL on one processor thus locking out any thing running at < DISPATCH_LEVEL from being executed on that processor.

The Windows kernel (NT, 2k, XP and beyond) schedules thread objects based on a multi-level feedback queue algorithm using the thread states 0-31 (31 being the highest priority).

The dispatcher traverses the priority queues searching for any thread that is in its standby state. When one is found, the dispatcher must determine whether there is a CPU available that the thread has an affinity for. If there is, then the thread is allocated that processor. If no CPU is currently available, but the thread has a higher priority than any of the currently running threads, it will preempt the lowest priority thread and begin execution on that CPU. If it is unable to preempt a thread it will be skipped, and the dispatcher will continue its traversal. If no thread can be found to execute, the dispatcher will execute a special thread called the idle thread.

It's been this way since NT.

Whether you want to believe it or not, Windows uses all available cores for you. Unless you have an AV monitor that runs all its threads at > DISPATCH_LEVEL (btw, that's only level 2 on the aforementioned scale), other threads which are running will get executed on that processor. And btw, you always have *shit* running in the background; networking, system services, etc.

Some of this may actually increase CPU intensive game performance because all those other threads aren't as readily stuck waiting on queue! *gasp*

Quote from DEVIL 007 :

but not due to dual core m8

*bbzzzttt*

The OS thread scheduler will toss threads out to both "CPUs" during execution, you will see an increase in performance over a single core or HyperThreaded machine.

If the application was optimized for SMP you'd see even more of a perf increase as the app could / would target threads to processors rather than letting Windows just pick a free proc to shove a thread on to.

Quote from Nick_ll :

HAHAHAHA!!! He can't get #2. That's already filled with Fisi! It's the #1 seat at Renault that is left empty.

Somebody better tell the boys at Renault that.

If Renault lands Kimi (not going to happen, he's Ferrari bound, and I hope they have fun w/ him) then Fisi'll be #2, otherwise any other driver they can poach will sit #2 to Fisi.

Sad, but true.

There are only 3 drivers with seats currently that are worth a top seat at a top team, one is leaving for McLaren, one will never leave Ferrari, and the last is on his way out of McLaren.

There is no spare Renault seat guys...the only spare seat is the test seat.

Heikki Kovalainen will be #2 driver a Renault unless Kimi jumps to Renault. (Btw, buh-bye Kimi...your brain fart this weekend pretty much sealed your McLaren fate).