Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

a tTime & date 

12:00 noon 7/9/2018 at SLAC

...

  • If each new snapshot is to be complete then this could get huge, e.g. if we keep the snapshots going back only for the most recent 24 months each snapshot is ~24 (months) * 0.4GBytes = ~10 GBytes  and there are 2 * 365 (days in a  year) of them, i.e. ~ 7TBytes/participating MA.  
  • If on the other hand, each snapshot is just the daily measurement from all the MAs, then each snapshot is ~0.012Gbytes. 
    • In this case,  the analysis will need to add all these snapshots together.  Some thought will be needed to figure out how to save and access the data.
  • Another alternative would be for each MA (or maybe just a subset of MAs) to save just its data each 30 minutes into the blockchain. I.e. a transaction is a set of measurements made each 30 minutes by each MA. The amount of data to be saved varies depending on the number of targets. For each target, for each day, there are 96  measurements (each 30 minutes for 100 and 1000 Byte pings) of each target and each target measurement is ~200Bytes, or ~ 100*200Bytes / target/day or ~400Bytes/target/30 min measurement
    • SLAC MA (~900 targets): 18MBytes/day or ~ 400KBytes/target/30 minute measurement
    • Typical MA (just monitoring ~ 100 Beacons):  2MBytes or ~40KBytes/target/30 minute measurement
      • There are currently about 40 active MAs or about 80MBytes/day or 1.8MBytes/all targets/all typical MAs/30 minutes.
  • Another alternative would be to save each set of ~10 pings to the ledger.   I.e. a transaction is a set of roughly 10 nByte pings where n is 100 or 1000.
    • Each addition would be ~ 200Bytes
    • Since pinger2.pl make the measurements by multiple threads, it is possible for multiple measurement results being added to the blockchain simultaneously.
    • This would provide give real-time results but would require changes to the guts of pinger2.pl

...