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

Slow reliable peer #183

Open
ksubox opened this issue Dec 26, 2021 · 3 comments
Open

Slow reliable peer #183

ksubox opened this issue Dec 26, 2021 · 3 comments

Comments

@ksubox
Copy link

ksubox commented Dec 26, 2021

I tested ENet library with 2 clients located far from each other: TTL 53, Ping 280 and got maximum bandwidth of reliable packets about 2Mbps
With the same conditions I got about 9MBps with LiteNetLib (C#). And TCP gives about 9-10MBps between same clients.
Local tests (localhost<->localhost) give about 300MBps.
I guess something wrong with buffering or window processing.

@Calinou
Copy link

Calinou commented Dec 26, 2021

Sending large data with UDP will always be much slower than with TCP, especially in less-than-ideal situations. I don't think ENet is designed to provide fast UDP file downloads.

@lsalzman
Copy link
Owner

It's likely you are not calling enet_host_service/enet_host_check_events often enough or in an optimal pattern.

@ksubox
Copy link
Author

ksubox commented Jan 10, 2022

I tested different patterns and last one is:
while(true) {
int evres = enet_host_service(host, &evt, 0);
while (evres > 0) {
// do some input processing - very light, just count incoming traffic
evres = enet_host_check_events(host, &evt);
}

if (peer->reliableDataInTransit > 512 * 500)
continue;
auto res = enet_peer_send(peer, 0, packet);
}

And anyway speed almost the same (increased up to 2.5MBps from 2MBps).

So I believe problem is different from pattern usage. Could you hint where I should check in source code ?

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

3 participants