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) <j...@apache.org> 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)
