Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make dose_main treat different data types fairly when sending to communication #419

Open
DonOregano opened this issue Mar 2, 2023 · 0 comments
Milestone

Comments

@DonOregano
Copy link
Member

In Core 6.x and 7.0 dose_main has a function CanSend, that attempts to make it so that pool distribution does not starve "normal" traffic. This function actually has the reverse result, in that it makes it very easy to starve the pool distribution if there is a fair amount of normal traffic while the pool distribution is going.

It is also quite easy to starve out different types of traffic in dose_main by for example having one app create lots of entity updates, and another send requests slowly. In this case the slow requests may never get through at all.

dose_main (or communication) needs a mechanism to treat all types of data reasonably fairly. Some kind of round-robin between different data type identifiers and also pd and normal traffic (which I think currently use the same data type identifier).

Pd and normal traffic may need to have different data type identifiers, if the data type identifiers is the basis of how we solve this issue.

It is also not completely clear whether this mechanism belongs in communication or in dose_main. We want to avoid adding latency to the data transmission.

@DonOregano DonOregano added this to the 7.2 milestone Mar 2, 2023
DonOregano added a commit that referenced this issue Mar 2, 2023
@DonOregano DonOregano modified the milestones: 7.2, 7.3 Aug 14, 2023
@DonOregano DonOregano modified the milestones: 7.3, 7.4 Dec 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant