The latest version of the test application can be found from DrJukka/P2PChatTest will be updating it until I’m happy with it, or until I make new app to do tests with.

The timing is based on test with the application doing the loop described in Initial investigation post here, and the measured points are as follows:

  1. FoundService
    • Actually, found peers. The time between issuing requestPeers(), and adding service request for service discovery
  2. StartServiceDiscovery
    • Time between adding service request, and success() callback called for starting the service discovery (1 s delay removed)
  3. GotService
    • Time between starting the service discovery and finding suitable service.
  4. Connecting
    • Time between finding the service, and onSuccess() for connect being called.
  5. Connected
    • Time between starting the connection, and actually getting event for being connected.
  6. GotConnectionInfo
    • Time between requestConnectionInfo() call and getting the information.
  7. GotData
    • Time between having the connection information, and receiving first data.
  8. GotBigData
    • On group owner side, time to receive1 Mb of data, on client side the time to write that data to a socket.
  9. FromDcToSd
    • Time between the last data retrieval, and the event informing that we are disconnected.

Note that the data only has values for loops that went through from beginning all the way to getting the big data, any loops that did not result receiving/sending the megabyte data are not logged. Also some logs did not have values for all connections steps. In those cases the reason fro missing data, is that the connection was initiated by the other party, and we just got information that we are now connected.

I also divided data between Group owner and client, since they are doing a bit different functions. All data is in milliseconds, and disconnection method used here, was to turn off the device after the full cycle was completed.

Here’s Group owner data:


Most of the time there is spend on waiting the disconnection event, this is party effected by user not disconnecting the device immediately, but in main parts of it are really caused by the API being slow on determining that the connection was lost.

Then we can also see that the Service discovery is taking on average 4 seconds, and in worst case it took nearly 20 seconds.  And for creating the connection took 6 seconds on average, and worst case it took over 12 seconds. From the data we could determine that in worst case, it could take over 40 seconds between the device was discovered, and before we are getting first data

For Client the data looks rather same:


Though service discovery looks loads better and the worst case is only taking a bit over 3 seconds and also the average is taking over 60 % less time than when we were group owners. Connecting them takes about the same time. All and all, with Client with worst case we get first data through in half time when compared to the group owner side

Here’s quick pie charts to illustrate the differences in graphical form for the average times measured:

WD_AverageGroup WD_AverageClient

This does indeed give nice overview on the timings, though I have to admit that the sample size should be bigger, as well as different scenarios should also be taken account to see how the API behaves is them.