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

Adding plugins insreases transmission time. #9

Closed
mayankmclaren opened this issue Jun 22, 2020 · 5 comments
Closed

Adding plugins insreases transmission time. #9

mayankmclaren opened this issue Jun 22, 2020 · 5 comments

Comments

@mayankmclaren
Copy link

Hi,
I ran picoquicdemo with different plugins. But I observed that the plugins which should have decreased the transmission time of the data actually end up increasing time taken.

picoquicdemo with no plugin took 8755.857 ms for around 100MB of data.
Screenshot from 2020-06-23 04-28-39

picoquicdemo with datagram plugin took 9469.609 ms for around 100MB of data.
Screenshot from 2020-06-23 04-28-42

picoquicdemo with datagram, fec and multipath plugins took 14611.648 ms for around 100MB of data.
Screenshot from 2020-06-23 04-28-47

Is it supposed to happen like this or there is something that I'm doing wrong?
Am I missing out anything important regarding the plugins?

@mpiraux
Copy link
Member

mpiraux commented Jun 23, 2020

I guess those tests are running on the loopback interface.
In the original PQUIC paper (available at pquic.org) we also report on performance benchmarks and provide explanation on the performance degradations. In short, plugins are eBPF bytecodes and thus are slower than native machine code. Also, injecting plugins add new functions and code paths to PQUIC, so the execution time increases.

That said, injecting plugins can be beneficial. FEC helps in lossy networks, such as SATCOM environments, but can be detrimental in good networks and Multipath can leverage several network paths. When running a test on the loopback, you are first likely to be CPU blocked rather than network blocked, and second losses are absent.

Regarding the injection of the datagram plugin. I am surprised to see a performance degradation as picoquicdemo does not use datagrams in any forms. I would expect that if you run the tests several time, you will not find a statistically meaningful difference. If you find one, it would be interesting to understand its origin.

@mayankmclaren
Copy link
Author

I ran picoquicdemo with and without datagram plugin sending 100MB of data on loopback condition for 50 times. The average transmission time without the plugin injected was 9.223 seconds and with the plugin injected was 10.095 seconds.
I also observed that a few times the datagram plugin took time all the way up to 14.5 seconds.
I'm attaching the test data here: https://docs.google.com/spreadsheets/d/1vvfdTFZ0OX7mpczngmCTzWVM5NIoHRWBbzo1sjjm3wc/edit?usp=sharing

@mayankmclaren
Copy link
Author

there's one more question that I want to ask.
On the server side at the end, it shows "Retrans= (some numeric value)". What does that signify? The number of times retransmission happened?

Screenshot from 2020-06-23 04-28-39
like here it's Retrans= 543

@mpiraux
Copy link
Member

mpiraux commented Aug 27, 2020

I think there is something odd with your test setup. I can transfer 1Gb in about a second on my machine loopback (disabling the logs with -l /dev/null), and the transfer does not report any retransmitted packet. Injecting the datagram plugin adds a fixed cost of reading a bunch of files and recompiling their code, but it does not add any instructions in the data path when using the picoquicdemo client and server.
I ran 20 tests side by side with and without the plugin and I did not find a meaningful difference. There is theoretically one, but a small one.

@mpiraux
Copy link
Member

mpiraux commented Oct 13, 2020

I am closing this as it seems that no further assistance is required.

@mpiraux mpiraux closed this as completed Oct 13, 2020
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

2 participants