We had a client computer that recorded vinyl 12 hours per day. (Artist 2017.02 - ASIO: RME Fireface 800).
For a few months we had replaced this computer with a laptop DELL Latitude.   (Artist, 2017.02) (the same RME Fireface 800)
Now we notice "holes" in the recording:
That means: Every 1 - 3 minutes, suddenly 500ms to 2000ms are missing. The recording jumps seamless without a pause. It sounds like the band has forgotten to play half a measure. During Recording I listened to the OUTPUT of the RME Fireface - all OK. When I play this recording, then it "jumps" all few minutes.
 
I know this is up to a driver for the firewire connection or its up to the firewire hardware from the DELL laptop. The solution is to replace this computer. Very easy. (I don't want to check with other versions of SONAR)
 
My question is: Why does SONAR not notice !!! that the firewire driver delivers nonsense? I would expect that SONAR stops !! immeditately !! when the driver has issues during recording? 
Is there any parameter where I can tell SONAR to stop recording when a driver delivers nonsense?
I ask - because I need a safety precaution to prevent such issues. We have 7 client computers to record audio - I cann't check all recordings.
 

How you think Sonar should detect the skip?
 
For the problem itself: are you sure that you have switched off ALL powersaving features (in BIOS and Windows) on DELL?
 
For RME output during recording: you probably has "direct monitoring", so you get on the output what you have on the input, bypassing Sonar. Turn that off and enable "Echo" on recorded track, then you should hear what it coming into Sonar.

Does gap occur during recording, or during playback? IOW, if you examine the audio clip closely, can you identify where the gap is?
 
If so, that would suggest the audio interface is flushing its own internal buffer for some reason. SONAR would only know this had occurred if the data stream was interrupted. SONAR would detect this as a dropout and, if it was more than 250 ms in duration, halt the audio engine. You wouldn't miss such an event.
 
However, if the interface were to keep sending data despite the internal loss, the driver would happily continue to fill its buffers, SONAR would see an uninterrupted stream of data from the driver, and neither the driver nor SONAR would know there'd been any data lost.
 
I wouldn't be looking to replace the computer, I'd be considering replacing the audio interface.

Probably the DELL builtin firewire is overloaded - throws data out - and SONAR can not notice.
I'm just disappointed that there is no exchange between "firewire hardware" and SONAR.
The firewire should "cry", that it throws data out - and SONAR should stop recording.
I think DELL has built a very bad firewire connection in the budget range and this is the problem. I think Dell has not been building new ones with firewire.
  
There is no gap - not for one bit. Its absolut seamlessly.
And its up to two seconds skipped audio (!! seamlessly without gap !!). I also noticed a repeat from 1,2 seconds.
I think its up to the DELL laptop E6520, because SONAR very often crashed when closing the project (shut down the connection to the interface). SONAR also crashed sometimes by choosing an other input channel from the fireface. And Sonar crashes every second time by exporting a file.
 
I have replaced the DELL with the old computer. And until now it seems to work without "jumps".  In this old computer is a very good firewire card. And thats why it works. (We only wanted to save energy as we took a laptop.)

DPC Latency checker.

I can think of a few reasons why not.
 
If the problem was an intermittent connector or cable, there is no way for the FW adapter to know that. How do you distinguish between no data sent versus no data received? Even if there was a way, SONAR and the FW adapter don't talk to one another - that's a private conversation between the adapter and the audio driver, so SONAR isn't in the loop. All SONAR knows is that either there is some data in the input buffer or there isn't.
 
 
 

Sonar can't notice a problem if there is a continuous stream of data coming into it - even if some of that data describes silence. So the issue must be outside Sonar. If drop outs are being described as data then they must be happening before or maybe during the A/D conversion stage. If this is the case there may be a fault in the analogue stage on the way into the audio interface. Either way, it's likely to be hardware rather than software, assuming you are monitoring from tape (from the DAW) and you are sure the drop outs are on the way in and not the way out.

If I understood OP correctly there is no silence but it seems as if a section of 2sec. has been "cut out" of the recording and the wave to the right of the cut has been shifted forward to close the gap. (Whoa a ripple-editing hardware device)

The question is which part of the chain starting from A/D has a 2*2second buffer which allows for a whole section of 2seconds to get lost/flushed without any "silence" being sent as "data".

What about monitoring through Sonar (not direct) Do you get a huge (+2second) delay?

What Firewire driver are you using. (Dell?/Microsoft Win10 version) Maybe try using the older "Legacy Firewire Driver" from Microsoft.
I know on my Motherboard it shows much lower spikes on Latency checker than the newer Microsoft driver. It might "communicate" better.

Don't give up without a fight :)

There is a checksum of posted and received data trough firewire. So if the connection (for example cable) fails, the checksum is wrong.This would end in connection lost.
And the RME 800 doesnt tell SONAR where to position the data - Sonar only records the stream.
And it's not up to the RME 800, because it works with an other computer.
 
The question is: who kills up to 2 seconds of data without a gap in the streaming.
As we can now say:
An Original with 3:17 has after recording 3:15. 
Therefore SONAR is suspected - who shortens the recording?
Who kills the 2 seconds??
It's as if a ghost has cut holes in the recording then joined the ends.
(sync & caching is Trigger & Freewheel on all our devices - so only the stream is recorded without a clock)
   
I will make another test, to see if the recording is stretched, if there is a delay ....
Now I'm interessted in whats going on.

Yes, yes! 👍 Let's find out who stole 2seconds of vintage vinyl sound. The Bastards. Whoever it was I guess they knew it's priceless.....

* maybe Sonar noticed that your record player was turning slightly faster than 33 1/3 RPM and tried to compensate?