Metadata indicates 7+ seconds image latency

Please provide the following info (tick the boxes after creating this topic):
Software Version
DRIVE OS 6.0.8.1

Target Operating System
Linux

Hardware Platform
DRIVE AGX Orin Developer Kit (not sure its number)

I read current the TSC clock value in ticks as described here and compare it with the image buffer metadata INvSIPLClient::ImageMetaData::frameCaptureStartTSC and INvSIPLClient::ImageMetaData::frameCaptureTSC values in the moment I receive the buffer.

This is what we see:

frameCaptureStartTSC: 3181374267758 ticks
frameCaptureTSC: 3181375729268 ticks
TSCnow: 3181610295295 ticks

The difference of frameCaptureStartTSC to frameCaptureTSC is 1,461,510 which converts 1461510 ticks *32ns/tick = 46,768,320ns = 46ms which is little less than a frame period

The difference of tscnow to frameCaptureStartTSC yes is 236,027,537 ticks which is 7,552,881,184ns or 7.5 seconds!

In other words the SIPLCamera Latency according to the TSC timestamps is 7.5 seconds. That would be unusable for any self driving use case. Given the fact we just retrieve the RAW frame we are not using any ISP. How can we reduce the latency?

Where are you obtaining the ‘TSCnow’ value? You might try correlating the TSC and the PTP in the RecordCaptureDoneEventTime() function found in /drive/drive-linux/samples/nvmedia/nvsipl/test/camera/CNvSIPLMasterNvSci.hpp using the NVPPS_GETEVENT ioctl.

I read the physical memory address

devmem2 0x0c6a0010 —> A
devmem2 0x0c6a0014----> B
Current TSC tick is A + (B << 32)

I verified the values I am reading and it is definitely a clock at 31,25 Mhz (32ns period).
We are not using PTP or PPS yet. PTP_TSC offset is always 0.

We tested on another AGX drive and that showed even a 44 second offset. So it seems the TSC clock values are shifted by a random number. An uninitialised offset would explain the behavior.

Ok, it is getting pretty obvious. This is the log of another system

frameCaptureStartTSC, frameCaptureTSC, TSCNow, TSCNow - frameCaptureTSC
650782250, 652243753, 2040222771, 1387979018
652518862, 653980366, 2041959412, 1387979046
654255471, 655716975, 2043696053, 1387979078
655992084, 657453587, 2045432694, 1387979107
657728696, 659190200, 2047170289, 1387980089

So the distance between TSCNow and frameCaptureTSC almost remains constant. What this strongly indicates is that all timestamps use in fact the same clock, while frameCaptureTSC frameCaptureStartTSC get adjusted by an uninitialised constant

Please try calling NvpGetTimeMark() to get the TSCNow.

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.