...
See also Feasability of a Blockchain model for the collection and distribution of PingER data, and https://blockgeeks.com/guides/what-is-blockchain-technology/ for an introduction.
The idea is to reduce/eliminate the dependence on 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. 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.
- 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
...