jack: I have some new questions

Have been reading and I have some clues why the FSB problem is hard to find. I know that there are a lot here that believes this problem doesn't exists, my "problem" is that I have tested it with code and found problems. It is easy to create one application that will run much faster on AMD but those who use games to test CPU are sometimes saying that Intel is better all over. The problem could be that FPS is a very bad test to check how the game behaves even if you get exact time spans between frames. And if one think that fps is exact then it could be problematic to understand differences in how processors behave.

Situation 1:
There is a demanding scene for the video card (GPU) but the CPU is able to handle it well (the game is running at 30 FPS). Frames are triple buffered and that means that the video card is three frames behind the cpu. Responsiveness for the mouse is vital and if you press the mouse button for shooting the picture will render this three frames after the cpu got information about fire button pressed.
Will this make the game feel unresponsive?

Situation 2:
This again is a demanding scene for gpu and the cpu handles it well. Image is triple buffered (three frames are cued because cpu is much faster) and suddenly there is a need to reload some information from memory. This will stall the CPU but you can't see it on the frame rate because the GPU has three images to render. When the CPU is ready the GPU has only one frame cued (two frames was rendered during the CPU work) and the CPU starts to feed the gpu with data again. This could be a small stop in the game even if frames are produced.
This would mean that it isn't (it is inexact measurement) possible to check latency issues for the FSB (and other latency issues) in game checking frame rates because the video card will hide it?

Situation 3:
Two different CPU's are used. One is very good at synchronization between threads and one is bad.
This is a very demanding frame for the CPU that doesn't synchronize well, the scene is easy but something happens that makes the cpu to be delayed (synchronization of memory for a quad using the FSB while data is sent to the video card or thread is moved from one core to another). The CPU is delayed for just one frame. The video card this time has only one frame that it is able to cue and this is being rendered while the CPU does this synchronization (multiple threads are used).
The fast synchronize CPU is ready when half of the frame is ready in the video card and starts to produce new images.
The slow synchronize CPU is ready one half frame after the frame that is rendered is ready.
Let's say that this frame took 1/20 ( 0.05 seconds ) seconds to render if no cpu delay. On the fast synchronize cpu the new image was started to being produced 0.05 - 0.05/2 = 0.025 seconds after the frame before. On the slow cpu it was produced 0.05 + 0.05/2 = 0.075 seconds after.
The real delay between these frames comparing both processors would be 0.05 seconds. But when frames are checked it will show a difference for 0.025 seconds. The GPU is masking 0.025 seconds delay.

Situation 4:
Two different CPU's are used. One is C2D with extremely high clock. and fast big cache. The other is AMD Phenom. Better at more threads.
Testing a game that first is walking on a road for 100 seconds and suddenly you are attacked with lots of bombs using physics for 10 seconds.
First test is on 800x600: C2D produces a lot of frames walking on the road, GPU handles all frames and only two threads are used. C2D gets about 200 FPS on the road and AMD gets 100 FPS. When you are attacked two new threads are activated, one for physics and one AI thread for enemies. Here AMD gets 50 FPS and C2D gets 30 FPS. First test average will be higher on C2D.
Calculation:
C2D = (100 * 200 + 10 * 30) / 110 = 184
Phenom =( 100 * 100 + 10 * 50) / 110 = 94

Second test is on 1680x1050: Now the game has difficulties to render more than 50 FPS. So when walking on the road C2D and Phenom needs to wait, C2D waits more. On the attack scene though the GPU and Phenom will be exactly the same. But the C2D slows the GPU
Calculation:
C2D =( 100 * 50 + 10 * 30) / 110 = 48
Phenom = (100 * 50 + 10 * 50) / 110 = 50

Third test is on 1920x1200: The video card now has problems to render more than 30 FPS
C2D =( 100 * 30 + 10 * 30) / 110 = 30
Phenom = (100 * 30 + 10 * 30) / 110 = 30


Conclusions (if above conclusions is right) :
1: If the video card is buffering images and the video card is slower than the processor it is very hard (impossible) to find latency problems in the FSB checking frame rates.
2: It is very difficult to find the exact difference in the low FPS values (GPU slows it) if the game is suddenly is stalled by the processor because the video card hides some of it. If the image is buffered (two or more) it is even harder.
3: The CPU needs to be "close" to the current frame if you are on low FPS values if the game should be responsive and smooth.
4: It is difficult to find advantages in games for more cores and better synchronizations if you don't know exactly how the game is done and what's tested at that exact time.
5: FPS isn't one good measurement to find out how the game feels. It is possible to get high FPS values but the game could feel strange anyway.