planning of experiments #31

Closed
opened 2020-06-03 00:09:43 +02:00 by schmittlauch · 0 comments
Owner

What metrics to measure?

  • only measure relay node performance/ load, ignore storage node load in the scope of this project
  • key metric: number of posts to be relayed by node per time = |subscribers| * |incoming posts|
  • resolution of 1 day might be good enough
  • effectivity of load balancing:
    • distribution of load among homogenous nodes
    • match of load to load target for inhomogenous nodes

How to measure them?

  • relay nodes report numer of relayed posts per time slice

Parameters to examine

  • number of hashtags
    • k-choices doesn't protect against overload at a single hashtag
  • assumed distribution of subscribers
    • assume power law distribution of users over instance https://dl.acm.org/doi/pdf/10.1145/3355369.3355572
    • assume that each poster also makes their instance subscribe to that tag
    • but multiple subscriberst can be on the same instance => only one subscription for all tof them
  • node resources: homogenous or non-homogenous
    • start with homogenous nodes fo non-kchoices simulation
  • node IPs and domains => node IDs
    • can be taken from instances.social data set (Großer Beleg)

scenarios to simulate

## What metrics to measure? - only measure relay node performance/ load, ignore storage node load in the scope of this project - key metric: **number of posts to be relayed by node per time** = |subscribers| * |incoming posts| - resolution of 1 day might be good enough - effectivity of load balancing: - distribution of load among homogenous nodes - match of load to load target for inhomogenous nodes ## How to measure them? - relay nodes report numer of relayed posts per time slice ## Parameters to examine - number of hashtags - *k-choices* doesn't protect against overload at a single hashtag - assumed distribution of subscribers - assume power law distribution of users over instance https://dl.acm.org/doi/pdf/10.1145/3355369.3355572 - assume that each poster also makes their instance subscribe to that tag - but multiple subscriberst can be on the same instance => only one subscription for all tof them - node resources: homogenous or non-homogenous - start with homogenous nodes fo non-kchoices simulation - node IPs and domains => node IDs - can be taken from *instances.social* data set (Großer Beleg) ## scenarios to simulate
schmittlauch added this to the 1st round of experiments milestone 2020-06-03 00:09:51 +02:00
schmittlauch added the
evaluation
label 2020-06-03 00:09:59 +02:00
Sign in to join this conversation.
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: schmittlauch/Hash2Pub#31
No description provided.