Discussion: Community Data Analytics

Hello everyone!

My name is Payton and I am one of the orchestrators on the Livepeer network.

Several orchestrators in the community have shown interest in building out a community data analytics platform. This topic is being created to discuss those ideas before a formal RFC is created.

Problem Statement: The community does not know what sort of usage the Livepeer network gets (and we don’t want to depend on a corporation to give these metrics).

Motivating Questions

  • How many broadcasters utilize the network?
  • At any given moment, how many sessions are active?
  • Which profiles are most popular across the network?
  • Where does traffic originate?
  • How does traffic volume correlate with time?
  • How does a session of profile X impact memory usage of GPU Y?

There is a LOT more that we can strive to answer, but those are good starter questions to motivate the conversation.

Goals

  • Understand how individual orchestrators can make better use of their data
  • Explore the idea of facilitating a community data analytics visualization

Some questions I’d like to pose to the orchestrator community are as follows:

  • Which metrics do you think are valuable? (CPU utilization, session origin, session profile, packet throughput data, etc) This question should be answered in a hypothetical sense. If you can have access to ANY metric, what would it be?
  • How can these metrics be compiled to display answers to the motivation questions? (or similar questions)
  • Which metrics make good candidates for pooling publicly in a community-facilitated analytics visualization?

There may be some initial concerns of privacy when it comes to publicizing analytics. I personally will not support a platform that publicizes broadcaster IP’s. I think this is crucial to develop network trust. If there is any aggregation on IP data, it should be a) hashed or b) generalized to max(region, country). If there are other privacy concerns, please state them. The goal of this project is, again, for orchestrators to make better use of our data. As a result, we’ll be able to provide a better product to broadcasters looking to utilize the decentralized community.

1 Like

This was caught in the spam bot. Please refer to this post: Some thoughts on Orchestrator's collating metrics - #9 by payton