From: Alex B. <a.b...@ac...> - 2008-02-25 11:30:09
|
> >> [...] > >> ? 153-157 If timestamps are the overwhelming concern, shouldn't now() be > >> called inside getDataFromSerial(), after bytesAvailableWait() returns > >> (line 210), or ideally whenever select() returns? > > > > Yes, but I figured the difference would be negligible. I'd be amazed if > > you'd notice the difference, do you disagree? And it still wouldn't be > > correct anyway: by the time you're reading from the serial port you're > > already too late. I think you're never going to get this sort of extreme > > accuracy without hardware triggering. > > Don't know, yes and yes ;-). It's just that getting timing right is hard > work, and the more levels you have to look at the more tedious it becomes. > Also, the delay between data arrival and return of a blocking call is > roughly constant (with preemptive kernel patch). So if all your data > goes through the same kind of interface, chances are the delays are the > same and it's consistent. Timing stuff in general: I don't have a good enough feel for whether these small improvements will make a significant difference. If I was gonna do it, I'd want to analyse how much of a difference it actually makes. Can we agree to leave it on the list of nice-to-haves? > The approach insgps takes, is to read byte by byte and take timestamps > till it finds a start-of-message-sequence. That timestamp is is kept, > till the whole message is parsed. > > Obviously I've got no idea whether this could be applied to the sick > protocol and your parser. Yes, something like this could be done. Alex |