menu
Downloads Servers Forums Support
Home› Support

Affinity

SScratchMonkey
in Support
Any idea why the engine is so sensitive to affinity? (I haven't seen a problem on my E8500, though.) It's my understanding that the engine is single-threaded, so there shouldn't be any issues with improper locking between threads that presume a single core. Is this a problem with threads being spawned behind the scenes by Windows APIs?

Comments

  • TurkehTurkeh
    short and not fully informative answer: Because Tribes 2 uses a register to determine timing, and said register is different between different cores (if my memory serves me properly).
    I'm sure Thyth will have a much more enlightened answer, if/when he gets to this post. :)
  • SScratchMonkey
    Aha! That makes perfect sense.

    So the fact that it's working for me is perhaps credit to the game sticking to one core strongly in spite of no explicit affinity setting. Perhaps Vista 64 with lots of memory is good at keeping the thread on the same core across task switches.
  • ThythThyth
    My technical explanation is somewhere on the forum. To save you the time of searching for it, here it is:

    Jitter is a result of a programming defect in Tribes 2, where it used the RDTSC instruction to count CPU ticks as a form of high precision timer. Problem is... each CPU and core on a system has its own tick counter, and they aren't designed to be kept in sync (or to be used as a timer). If your cores do not have the same tick count, as the game is scheduled by the OS between the separate cores, the game thinks it is moving forward and backwards in time.
  • SScratchMonkey
    Makes sense. It sounds like Intel took a shortcut in designing the cores to not use a common timer register, probably to save the complication of routing the signals between the cores. Or are the cores independently clocked and asynchronous? I know digital logic gets pretty tricky to design at those speeds. It was bad enough back when I did it in the 100 Mbps domain 20 years ago.

    Is there a Windows API that will return a comparable high-resolution time value? I'm looking for something to measure communications protocol times to profile/debug communications timing issues.
  • ThythThyth
    RDTSC was never designed to be used as a high precision timer. You'll want to use HPET if your system supports it.
  • SScratchMonkey
    Fortunately, I've been using QueryPeformanceCounter, so it looks like I'm safe:

    http://msdn.microsoft.com/en-us/library/bb173458(VS.85).aspx

    But I know I've seen raw assembly language in the Torque engine reading the RDTSC.
Sign In or Register to comment.