Announcement

Collapse
No announcement yet.

FR24feed on Raspberry Pi - Frequent DNS requests for NTP

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • MrMac
    replied
    Originally posted by Strix technica View Post
    Correct, sorry about that.

    I think we agree on the rest, now that most of your incorrect assumptions are cleared up... ;-)

    /M

    Leave a comment:


  • Strix technica
    replied
    Originally posted by MrMac View Post
    If you refer to a post 2 pages and 4 months back, it's probably a good idea to quote it.
    I did. I suggest that you read what others write more carefully before chastising them for perceived faults.

    Originally posted by MrMac View Post
    There are 2 versions of AVR format, with or without timestamp.
    Right, now we're getting somewhere and I've made the necessary changes to my station. Thanks for the heads-up on that.

    However, this raises the point that you can configure fr24feed for MLAT without configuring dump1090 to feed timestamps and nothing in fr24feed seems to complain, either in the log or in the status web page, that MLAT is enabled but is getting no timestamps from the message source so there's no obvious way of knowing whether your station is configured correctly for MLAT.

    This is an ecosystem problem: At least in some cases (many, if my installation is representative of non-fr24-supplied images), AVR is the format automatically chosen by the fr24feed config script and you can't expect the majority of operators to know the difference between AVR and Beast, or that default AVR doesn't have timestamps needed by fr24feed.

    If there are a lot of radars operators out there believing that they are contributing to MLAT but are in fact not, then the number usable MLAT sources is much probably rather lower than it might be. That's in nobody's interests.

    Originally posted by MrMac View Post
    But, to reduce possible misconfiguration, just use beast format on 30005 instead, it always has the timestamp enabled.
    That would require knowing the difference and that there's a benefit to Beast binary feed, which is not really any different from knowing that dump1090 needs the --mlat flag.

    Again, this is an ecosystem problem. The utility of a crowd-sourced data project like FR24 depends on as many feeders providing the best possible data and, because of that, it's not good enough to require or assume prior knowledge. The default install has to be sane and, at the very least, fr24feed (even better, the FR24 personal stats page) must be smart enough to alert the operator that there is a problem that requires their attention.

    Leave a comment:


  • MrMac
    replied
    Originally posted by Strix technica View Post
    F-EGLF1 kind of implied that here (emphasis mine):
    If you refer to a post 2 pages and 4 months back, it's probably a good idea to quote it.

    Which is pretty much what I later said (counting I/Q samples).
    After your elaboration about Basestation timestamps, I had no idea what else you have misunderstood so I started from scratch...

    Are you sure about that for AVR? I haven't seen a specification for the AVR format and the presence of a timestamp is not evident in struct modesMessage in dump1090.h. Besides, AVR messages seem too short (112 and 224 bits of which 24 are the ICAO address) to contain a decent ts.
    There are 2 versions of AVR format, with or without timestamp.

    Without:
    *8D3C5EE69901BD9540078D37335F;

    With:

    @016CE3671AA8A800199A8BB80030A8000628F400;

    http://wiki.modesbeast.com/Mode-S_Be...Output_Formats


    To enable AVR-mlat timestamp you need the --mlat option on dump1090.

    My local output on 30002 looks like this:

    @00001D5A25CD8D47BB0A58C90542C20BB846FCB1;
    @00001D5E0E308D47875D58BF01998E01FF058D94;
    @00001D5E21DF8D47875D99101E3800040241C520;
    @00001D64F569A00019978F79DB31201C005017B9;
    @00001D6674A95D47C071B7FC86;
    @00001D67A1078D3444599944F5AE48048348E4FC;
    @00001D6819265D4CA6FBAEA9E1;



    But, to reduce possible misconfiguration, just use beast format on 30005 instead, it always has the timestamp enabled.


    Well, AVR is what fr24feed selected in its autoconfiguration in my instance. Perhaps you didn't notice that I was confining my remarks to TCP-based feeds. What FR24 does in their stand-alone image, I don't know because I didn't use it. I assume/would hope that they use their own decoder, but they, too, might use dump1090. I could find out by downloading their image but there doesn't seem much point at this point.
    TCP-based or USB, RS232 or UDP, doesn't matter. The timestamp is done in the first device and how you then transport that data doesn't change anything. Fr24 also uses a fork of dump1090.

    I realise that, but my point was that the calculated relative timestamps are only as good as the quality of the original timestamp, and that that timestamp source is likely to be the system clock unless the timestamping code has access to the I/Q sample stream.
    Of course the timestamping must be done with access to the I/Q stream, that is why it's done in dump1090. Like I said, You made some incorrect assumptions and then the rest didn't make any sense either, like the bold part above.


    The only question is under what circumstances fr24feed either does, or has access to timestamps generated by something that does.
    When it decodes from I/Q using dump1090, or uses AVR with timestamp, or binary (Beast) format. If the incoming TCP data does not already contain a timestamp, there is nothing that can be done, no mlat will be possible with the data.


    Please read my earlier posts in this thread, and if you want to see how the code works in an open-source mlat solution you can check

    https://github.com/mutability/mlat-server
    https://github.com/mutability/mlat-client

    /M

    Leave a comment:


  • Strix technica
    replied
    Originally posted by MrMac View Post
    No one has claimed that there is a timestamp transmitted in the ADSB data emitted from an aircraft, so I don't know why you feel the need to argue against that point, it's moot.
    F-EGLF1 kind of implied that here (emphasis mine):

    Originally posted by F-EGLF1 View Post
    each receiver used for MLAT calculations must be able to see 1 or more aircraft with full mode-s giving time and location, this is then used as the reference and
    All I was saying was that, strictly speaking, the a/c doesn't give time, only location. Quite likely, he meant the locally generated ts for a given ADS-B position message.

    Originally posted by MrMac View Post
    Irrelevant. The timestamp used for MLAT calculations (in all different implementations) is the 12MHz rolling-counter sample count
    Which is pretty much what I later said (counting I/Q samples).

    Originally posted by MrMac View Post
    which is available in the Beast and AVR output formats.
    Are you sure about that for AVR? I haven't seen a specification for the AVR format and the presence of a timestamp is not evident in struct modesMessage in dump1090.h. Besides, AVR messages seem too short (112 and 224 bits of which 24 are the ICAO address) to contain a decent ts.



    Originally posted by MrMac View Post
    Originally posted by strix
    I'm going to guess that dump1090 + fr24feed is the most common of the TCP scenarios, and it seems to prefer AVR which (so far as I know) doesn't include timestamp information.
    Wrong. See above.
    Well, AVR is what fr24feed selected in its autoconfiguration in my instance. Perhaps you didn't notice that I was confining my remarks to TCP-based feeds. What FR24 does in their stand-alone image, I don't know because I didn't use it.

    I assume/would hope that they use their own decoder, but they, too, might use dump1090. I could find out by downloading their image but there doesn't seem much point at this point.

    Originally posted by MrMac View Post
    The "timestamps" used for mlat is completely relative
    I also wrote of differential timestamp calculations. Perhaps you missed that, too.

    Originally posted by MrMac View Post
    The trick is to synchronize these free-running counters to each other, and that is done by calculating the time-of-travel from an ADSB aircraft's emitted position to several receivers.
    I realise that, but my point was that the calculated relative timestamps are only as good as the quality of the original timestamp, and that that timestamp source is likely to be the system clock unless the timestamping code has access to the I/Q sample stream.

    Originally posted by MrMac View Post
    That is why NTP, or the accuracy of the local real-time clock has no influence on the mlat process.
    Once again, I acknowledged that to be the case provided the timestamp generator has access to the I/Q stream. The only question is under what circumstances fr24feed either does, or has access to timestamps generated by something that does.

    Originally posted by MrMac View Post
    a receiver with hardware timestamping like the FR24 box or Radarcape. Even with these receivers, it's still a rolling counter which is the actual timestamp, and it can be locked or unlocked to GPS epoch depending on the state of the receiver, if it has GPS sync or not.
    Sounds very similar to the hardware timestamping systems I worked on. In that case, absolute time did matter. It doesn't here because short term drift of a local oscillator isn't enough to be a problem.

    Leave a comment:


  • MrMac
    replied
    No one has claimed that there is a timestamp transmitted in the ADSB data emitted from an aircraft, so I don't know why you feel the need to argue against that point, it's moot.

    Originally posted by Strix technica View Post
    As far as I know, dump1090 only emits timestamps in the SBS output feed, and those are sourced from clock_gettime() ie, system time which will be jittery due to the way NTP works). All other output sources just emit only ADS-B message in one form or another.
    Irrelevant. The timestamp used for MLAT calculations (in all different implementations) is the 12MHz rolling-counter sample count which is available in the Beast and AVR output formats.

    Originally posted by Strix technica View Post
    I'm going to guess that dump1090 + fr24feed is the most common of the TCP scenarios, and it seems to prefer AVR which (so far as I know) doesn't include timestamp information.
    Wrong. See above. The rest of your assumptions are also wrong, as a consequence.


    The "timestamps" used for mlat is completely relative and has nothing to do with absolute time, it's just a counter. The trick is to synchronize these free-running counters to each other, and that is done by calculating the time-of-travel from an ADSB aircraft's emitted position to several receivers. The same signal, emitted from a known location and compensated for time of travel, synchronizes the free-running clocks to each other.

    That is why NTP, or the accuracy of the local real-time clock has no influence on the mlat process. There must be an ADSB-derived signal to sync the counters to, OR a receiver with hardware timestamping like the FR24 box or Radarcape. Even with these receivers, it's still a rolling counter which is the actual timestamp, and it can be locked or unlocked to GPS epoch depending on the state of the receiver, if it has GPS sync or not.

    The only use for NTP is to make sure that all receivers are more or less on the same page to start with, and so the server can discard messages that are obviously too late to be of any use. Sub-second accuracy is enough.

    /M
    Last edited by MrMac; 2017-05-06, 16:33.

    Leave a comment:


  • Strix technica
    replied
    I realise this thread is somewhat stale, but I can elaborate a bit on a subject that turns out to be surprisingly complex.

    Originally posted by F-EGLF1 View Post
    The main competitor uses NTP only to get a rough time stamp for the packets, each receiver used for MLAT calculations must be able to see 1 or more aircraft with full mode-s giving time and location, this is then used as the reference and the difference in the reception times of the position less aircraft from all the stations is compared to this known time and position
    So far as I know, ADS-B doesn't have any means to transmit time information (and it has no particular reason or need to do so). Even if it did, you'd have to trust the aircraft's time, which you can't reliably do. Some might use time from their own GPS receivers, but since it's known that some ADS-B position messages are derived from IRS rather than GPS, there's no particular reason to trust such timestamps even if they existed.

    So timestamps must be generated locally — and in software. You can still use the difference between the timestamp of a positional message as a reference against which to do MLAT on a/c that don't transmit positional messages however, there are a few wrinkles.

    I've got quite a lot of experience in passive measurement of data networks and designing accurate timestamping hardware, so I can say a few things about timestamping packets/messages with some authority.

    In all SDR-based ADS-B receivers, timestamps are generated in user-space after demodulation (by dump1090 in my case). It cannot be anywhere else because even if the hardware had timestamping capability, the hardware only streams I/Q samples and so doesn't know when a new ADS-B message begins.

    In general, software timestamping sucks because there's an awful lot of variable and unquantifiable latency between the actual receiver and the software sampling timestamps (USB latency has a lot of jitter because of its polling architecture, then you've got the kernel drivers and user space libraries amongst other considerations). Even kernel-based timestamping is pretty awful, partly because it's limited to Ás resolution, but mostly because of the way packets are delivered by the hardware to the kernel. User-space timestamping is usually even worse because of the way the kernel process scheduler works (typical accuracy ▒ 10 ms).

    rtl_sdr has one important advantage: because it receives a constant stream of I/Q samples, it can use the sample count as a timebase (which dump1090 does, indeed, do), but that's only as good as the local oscillator in the SDR receiver. All oscillators drift with both temperature and age, so you can't rely on sample count alone for absolute time but most oscillators are stable enough second-to-second that differential timestamps will cancel out most of the error.

    If you only need short-term differential time, counting samples is good enough however, if you need absolute time, you must integrate sample count with system time (as corrected by NTP) using some sort of minimal jitter, continuous convergence algorithm. I can describe how that works, but it won't be relevant to this discussion because dump1090 doesn't appear to do this.

    As far as I know, dump1090 only emits timestamps in the SBS output feed, and those are sourced from clock_gettime() ie, system time which will be jittery due to the way NTP works). All other output sources just emit only ADS-B message in one form or another.

    fr24feed has native support for several ADS-B sources but since the source isn't open, I have no idea what it does when doing its own decoding.

    The rest of the time, fr24feed reads ADS-B messages via a TCP socket. I'm going to guess that dump1090 + fr24feed is the most common of the TCP scenarios, and it seems to prefer AVR which (so far as I know) doesn't include timestamp information.

    That means fr24feed must be doing its own timestamping at the end of a very long chain of software. In the dump1090 scenario, that chain goes something like this: kernel USB host interface → user space USB library → dump1090 where decoding takes place → kernel TCP stack → fr24feed where timestamping and final upload takes place. Note that there is multiple kernel/user space switching going on. Each user space process probably doesn't run for its full 10ms timeslice because it will sleep when blocking on I/O, but the latency of all that user/kernel switching is non-trivial.

    This jittery, uncompensated chain is unlikely to be appreciably better than NTP jitter (which my pi reports to be 2 ms ▒ 1 ms, which is comparable with ntp.org's estimates).

    The only thing I can say for sure is that fr24feed can't count I/Q samples when it's not doing the decoding, so it is limited to jittery NTP-derived system time. It'd be interesting to know whether fr24feed can do better when it is doing its own sample decoding and whether FR24 prefer radars that use FR24's internal decoder over an external decoder.

    TL;DR-

    1. using your own stratum 0 clock is probably not significant in terms of MLAT, not least because the mean NTP error is about 0, as opposed to the RMS error from the official NTP pool, which is probably in the order of up to 5 ms, possibly more depending on the stratum of server you get.

    2. MLAT referenced to ADS-B position message timestamps is a fine thing, but it's more complex than that because everything depends on the quality of those position message timestamps which, as I hope I've demonstrated, probably isn't that great.
    Last edited by Strix technica; 2017-05-06, 13:09.

    Leave a comment:


  • pete318
    replied
    Originally posted by elljay View Post
    I had a reply from FR24 support - they confirm the client does make the NTP Pool lookups but are going to review - I've pointed them them in the direction of the Pool Vendor page and copied in Ask.
    I think it would be nice if yes 1: They did get a vendor zone. But 2: It's possible to disable if you do have ntpd running already. Since an established NTP server that is syncing even with pool servers will usually have a pretty stable +/- 5-10ms accurate clock and will account for local drift.

    Regardless of how much an accurate clock matters for MLAT, some people will have better solutions operating already.

    Leave a comment:


  • elljay
    replied
    I had a reply from FR24 support - they confirm the client does make the NTP Pool lookups but are going to review - I've pointed them them in the direction of the Pool Vendor page and copied in Ask.

    Leave a comment:


  • pete318
    replied
    Originally posted by MrMac View Post
    No, there will be absolutely no difference.
    If you mean there will be no difference for the use in MLAT calculations, then I'll agree. As I say later, I suspect they use other received known references to work out an accurate time for position calculation.

    If you mean there will be no difference between a stratum 1 NTP server running from GPS or PPS sources and a stratum 2+ NTP pool server, then I disagree wholeheartedly.

    Leave a comment:


  • SpaxmoidJAm
    replied
    I agree that the use of NTP is just to get everyone in the same ball park.

    due to the coarseness of MLAT positions, i very much doubt that the few ms difference will make any difference.

    I'm reasonably sure that FR24 use of NTP is just so the time is set rather than just whatever the pi happens to be at so when data is sent in it can be instantly tossed away if its to old (due latency on the internet etc.. i iamge were talking seconds here)

    It does make most sense if they did use time stamp's from known positions and then referenced that to the local clock (on data sent in) to create a time offset (for that client) so MLAT calculations can be done. So the local accuracy could a little out but not appearing to old when sent to FA
    Last edited by SpaxmoidJAm; 2017-01-07, 10:46.

    Leave a comment:


  • elljay
    replied
    Getting back to the question of FR24 doing multiple DNS lookups to the NTP Pool, I've sent a support request asking if it's still the case. If it is then it would be a rather rude use of the volunteer servers in the NTP Pool.

    I send data to both FR24 and the NTP Pool so I know the NTP Pool recently almost had a meltdown due to misconfigured software (https://community.ntppool.org/t/rece...ic-increase/18).

    If anyone has a server or two they could help the NTP Pool with they would be very welcome! http://www.pool.ntp.org/en/join.html

    Leave a comment:


  • Anmer
    replied
    Originally posted by MrMac View Post
    TIMESTAMP. NTP plays NO part in the MLAT TIMESTAMP, which is crucial part of the accuracy of the position.
    I still beg to differ.

    NTP is used to set the real-time clock, but it would do just as fine if set by the user to a reasonably, sub-second accuracy.
    Left to the "user" to set a "reasonably, sub-second accuracy", I suspect 95% of those helping make MLAT plots with non-GPS solutions would fail.

    Let's leave it at that. I know when I'm urinating in the wind.

    Leave a comment:


  • MrMac
    replied
    Originally posted by Anmer View Post
    Maybe I'm totally missing the point, it has been known, but this seems to suggest that an NTP time stamp does play a part in MLAT calculations?
    You are.

    NTP is used to set the real-time clock, but it would do just as fine if set by the user to a reasonably, sub-second accuracy. NTP is just a way to ensure that this is automated, and that the user doesn't input the wrong time. That is why an automated process is required in many networks, not that it needs the accuracy of NTP.

    NTP accuracy is completely irrelevant, and that was the question at hand here.

    And, read what I actually said again:

    NTP is far to crude to have any use for the MLAT timestamp

    TIMESTAMP. NTP plays NO part in the MLAT TIMESTAMP, which is crucial part of the accuracy of the position.

    /M

    Leave a comment:


  • Anmer
    replied
    Originally posted by MrMac View Post
    Receivers and feeder softwares all use some kind of real time, NTP-derived timestamps for all their data, but this is just to help the server decide what data is reasonably recent and what is outdated.
    Maybe I'm totally missing the point, it has been known, but this seems to suggest that an NTP time stamp does play a part in MLAT calculations?

    Leave a comment:


  • MrMac
    replied
    Originally posted by F-EGLF1 View Post
    The main competitor uses NTP only to get a rough time stamp for the packets,
    Exactly.

    This was posted while I was writing, but we say precisely the same thing.

    /M

    Leave a comment:

Working...
X