the question is, is this okay?
It's OK if you're able to do what you want to do without hearing dropouts, regardless of what the tool shows you. As long as the DPC latency is significantly less than the time it takes to fill your audio buffers, it probably won't interfere with your computer's ability to maintain a continuous audio data stream.
Example: your ASIO buffer size is 64 samples. If you're working at 44.1KHz, it takes 1.45ms to fill a buffer (0.0227ms per sample, times 64). (At a sample rate of 96Khz, it takes only 0.666ms to fill a buffer which reduces latency but also gives your CPU less time between buffer cycles to do its thing). If your DPC latency is really bad, say 4ms (which can happen) there is no way the CPU can do what it needs to do to the data. Not when it's getting handed a fresh set of data every 1.45ms!
But if, say, your buffer size is 2048 samples (which is what I use when mixing), at 44.1KHz the CPU has a whopping 46.5ms between buffer cycles, giving it plenty of time to process the data. (My DPC latency is typically under 20us.)
Your worst reading with DPC Latency Checker was 833us, or 0.833ms. That means the CPU would lose that much time out of the 1.45ms (1,455us) it's been allotted to process data in. The CPU therefore only has 0.722ms to get it all done (not only processing your audio but also managing all background tasks and driver overhead).
Whether or not that's
enough time depends on how many tasks the CPU has to perform in 722us. On a lean, optimized DAW it's probably more than adequate.
One other important note...running DPC Latency Checker while SONAR is open will not yield useful measurements, because you'll be seeing SONAR's own DPC overhead included in the results.