I agree, and Ray and I just discussed this too. I’ll delete the code that resets the index and we’ll monitor to see if that causes any issues.
- peter > On Sep 1, 2016, at 2:45 PM, Sterling Hughes > <[email protected]> wrote: > > In the 16-bit case I don't understand why you would ever reset the index to > 0. So long as the value is increasing, you will always have 32k entries > prior to wrap. I don't see why you'd care that it starts at a given number. > > > Sterling > >> On Sep 1, 2016, at 2:28 PM, Ray Suorsa (JIRA) <[email protected]> wrote: >> >> >> [ >> https://issues.apache.org/jira/browse/MYNEWT-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15456671#comment-15456671 >> ] >> >> Ray Suorsa commented on MYNEWT-368: >> ----------------------------------- >> >> Ah yes, the index is doing double duty. The first one is to try to maintain >> order when the device logs a lot of lines in a short period of time. The >> other, which we trying to use it for also is to deal with a lot of clock >> drift. It seems to me that we should not reset the index in that way. >> >> I am sure we will have to experiment a bit and figure out what sort of >> bounds we are trying to operate in. >> >> >> >> >>> Change logging format >>> --------------------- >>> >>> Key: MYNEWT-368 >>> URL: https://issues.apache.org/jira/browse/MYNEWT-368 >>> Project: Mynewt >>> Issue Type: Bug >>> Components: Newtmgr >>> Reporter: Sterling Hughes >>> Assignee: Peter Snyder >>> Fix For: v1_0_0_beta1 >>> >>> >>> Right now newtmgr has an 8-bit index which goes along with a 64-bit >>> timestamp. We are having trouble querying logs when time moves forward, >>> because of the misordering of log entries. >>> We should change this such that we have a 16-bit log index, which can be >>> used to query logs remotely. A result of this will be to make the module >>> an 8-bit value, which it is already assumed to be. >>> While doing this change, on the FCB implementation, we should also add a >>> short log entry header (4-bytes), that at least contains the version of the >>> log format that we are writing, that way when we make changes in the future >>> to the log format, the code can automatically wipe this sector and reformat >>> it. >> >> >> >> -- >> This message was sent by Atlassian JIRA >> (v6.3.4#6332)
