Bug 82973

Summary: Terrible PseudoTCP performance with bi-directional traffic
Product: nice Reporter: Olivier Crête <olivier.crete>
Component: GeneralAssignee: Olivier Crête <olivier.crete>
Status: RESOLVED MOVED QA Contact:
Severity: normal    
Priority: medium    
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:

Description Olivier Crête 2014-08-22 21:42:26 UTC
From email from Radosław Kołodziejczyk <radek.kolodziejczyk@gmail.com> on the mailing list:

 Our test programs are made of our libraries wrapped around libnice so it would
not be easy to send this for you to test. We did, however, discover something
new that should make it easier to investigate. As we were preparing a
test that we could send you to verify the problem we noticed that when the program
consists only of client and server, when client's only job is to send data which
server receives and dumps, the transfer is actually really good. Comparable with
TCP even (on some machines, some still have speed issue, but not that
great). However, when you add a case where server behaves as a echo machine
(not even that - it suffices for server to respond with even small 4B packets)
the transfer goes down by great amount. These are our observations on our most
problematic machine:

Program specs:
CLIENT    - sends 32 kB in loop
SERVER - receives the message, ignores it.

Average transfer: ~1MB

Program specs:
CLIENT - sends 32 kB in loop
            - waits for 4B response.

SERVER - receives 32 kB message
              - sends 4B response.

Average transfer: 10-70 KB/s

All of this is done on localhost so even the first transfer is not that spectacular, but
it's much, much better than what we have with the two-side sending. So maybe that
could be some clue.
Comment 1 Philip Withnall 2015-06-26 13:55:39 UTC
Migrated to Phabricator: http://phabricator.freedesktop.org/T105

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.