From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-cys01nam02on0084.outbound.protection.outlook.com ([104.47.37.84]:31136 "EHLO NAM02-CY1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751713AbeC0Irj (ORCPT ); Tue, 27 Mar 2018 04:47:39 -0400 From: Jean-Baptiste Maneyrol To: Martin Kelly , Jonathan Cameron CC: "linux-iio@vger.kernel.org" Subject: Re: How to handle missing timestamps? (was Re: [PATCH] iio: imu: inv_mpu6050: improve missing timestamp handling) Date: Tue, 27 Mar 2018 08:47:37 +0000 Message-ID: References: <20180324000240.19519-1-mkelly@xevo.com> <20180324123519.0acba88e@archlinux> <7c1718f2fc324eb6b959257a80e136cdCY4PR1201MB0184E4503B2B1EEA7F24C41DC4AD0@CY4PR1201MB0184.namprd12.prod.outlook.com>, In-Reply-To: Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Sender: linux-iio-owner@vger.kernel.org List-Id: linux-iio@vger.kernel.org Hello, this raises a good question of which interrupts we are missing (the oldest = ones or the newest ones). My bet would be that we are loosing interrupts from the newest data (the ir= q thread can take too much time and we loose interrupt). In this case manua= l timestamping would rather be: sample 0 (oldest timestamp): interrupt timestamp sample 1: interrupt timestamp + 0.1 seconds sample 2: interrupt timestamp + 0.2 seconds sample 3 (newest timestamp): interrupt timestamp + 0.3 seconds Can you check with your setup that this is really what is happening? Thanks for your feedback. Best regards, JB From: Martin Kelly Sent: Monday, March 26, 2018 19:43 To: Jean-Baptiste Maneyrol; Jonathan Cameron Cc: linux-iio@vger.kernel.org Subject: Re: How to handle missing timestamps? (was Re: [PATCH] iio: imu: i= nv_mpu6050: improve missing timestamp handling) =A0=20 On 03/26/2018 07:20 AM, Jean-Baptiste Maneyrol wrote: > Hello, >=20 > we should have 1 interrupt every time a sensor data has been acquired. So= in theory this is not something that should happen. But real world is alwa= ys a different story. >=20 Agreed. > Do you have a case where you saw that happen? >=20 Yes, I'm seeing this on a board I'm working with. I'm also seeing I2C=20 bus lockups at high frequencies, so my best guess (though speculation)=20 is that the interrupts are being generated by the bus is dropping some=20 of the messages. I'm seeing that, when the data ready interrupt fires,=20 there are multiple messages in the FIFO, so all but the first get filled=20 in with 0 timestamps. I plan to investigate why I'm getting bus lockups,=20 but since this is exposed a bug, I wanted to first work on improving the=20 resilience to such conditions. > The best way if this happens would be to create the timestamp based on th= e sampling rate since we know it (last timestamp + sampling interval). That= would be very similar to the real value since the only difference is=A0 th= e clock drift between the chip and the system. >=20 That sounds reasonable. Let me make sure I understand what you're=20 proposing. Let's say we have set the sample rate to 10 Hz. Every time we=20 get an interrupt, we already take a timestamp, which should be the=20 correct timestamp for the most recent sample. Imagine that after an=20 interrupt, we see there are 4 samples in the FIFO instead of just 1. In=20 that case, we mark the samples with timestamps: sample 0 (oldest timestamp): interrupt timestamp - 0.3 seconds sample 1: interrupt timestamp - 0.2 seconds sample 2: interrupt timestamp - 0.1 seconds sample 3 (newest timestamp): interrupt timestamp Does that sound right to you? If so, I will revise my patch to do it. =