First, some background: the DispatchTimer does not create another thread to run its stuff on, it is periodically checked from the WPF UI thread. This is why you can access UI elements directly and not get an exception. Now, the UI thread itself, (and here is where I start assuming stuff without any real base) is running once per rendered frame (running multiple time would be wasteful). Now, the rendering frame, my guess, is vsync ... umm... synchronized. So, no matter how small you'll set the interval of a DispatcherTimer, it won't be checked faster than your refresh rate (which, coincidentally, is almost always 60 hertz).
Now, what I would do: I would start a BackgroundWorker (which creates a different thread) and run an infinite loop in which I do my work and then sleep a bit (5 ms minus the_time_it_got_to_do_my_work_this_frame ). Now all would be nice and well if I wanted to check stuff that is "external" to WPF (like stream some stuff from the HDD, check for a network message, etc).
And from here, trouble: if you would want to access and, heaven forbid, modify UI elements from the secondary thread (our BackgroundWorker), you would have to use Dispatcher.Invoke or Dispatcher.BeginInvoke, and this is where things get messy: Dispatcher.Invoke or Dispatcher.BeginInvoke (msdn it to see the difference or PM me) do their work on the , yes, you guessed it, the Dispatcher thread (in our case the WPF UI one). And, as with everything dispatcher-driven, it is the WPF UI that checks the Invoke or BeginInvoke work queues, yep, you've guessed it, ONCE PER RENDERED FRAME.
So, if you go the BackgroundWorker route BUT you NEED to access or modify at least one UI element EVERY loop, then your update rate will slow down to 60 times per second (if you use beginInvoke this won't happen, but the UI changes will be the same - 60 hertz - in both cases).
My recommendation is (and this is a general WPF recommendation): split the UI logic from the application logic and UPDATE THE UI ONLY WHEN YOU REALLY NEED IT. So you should do your update cycle once every 5 ms, if you have to, but don't touch the UI unless when and if you really need to (and never once per update cycle).
And the real answer: i am unaware of any way to SPEED UP the WPF update cycle (but I guess it's definitely not recommended either way).