We developed a small tool to calculate the goodput of different basket2 padding methods. The goodput is calculated by parsing the basket2proxy.log and looking for the following line:

basket2proxy: 2016/12/19 01:54:40 [DEBUG]: [scrubbed]:46456: Receive: Total: 349800 Overhead: 24000 Payload: 18634 Padding: 307166 Goodput: 0.05327044025157233 Transmit: Total: 1752000 Overhead: 48000 Payload: 20105 Padding: 1683895 Goodput: 0.011475456621004566 PaddingMethod: Tamaraw

Please note that the format is modified from the original basket2 output by including the padding method. The goodput tool goes over the log and aggregates the data per padding method. From 1,000 connections per method, the output is:

$ goodput basket2proxy.log
Null, receive 0.9497±0.0064 0.9489, transmit 0.9765±0.0218 0.9894
Obfs4BurstIAT, receive 0.4771±0.0358 0.4732, transmit 0.7331±0.1839 0.8227
Obfs4Burst, receive 0.4632±0.0339 0.4631, transmit 0.7286±0.1786 0.8128
Obfs4PacketIAT, receive 0.6060±0.0270 0.6028, transmit 0.7940±0.1447 0.8771
Tamaraw, receive 0.1528±0.0915 0.1409, transmit 0.2418±0.2220 0.2073
TamarawBulk, receive 0.0257±0.0112 0.0261, transmit 0.2939±0.2512 0.2492
APE, receive 0.2745±0.0947 0.2701, transmit 0.4783±0.2041 0.5477

The output format per method is mean±stddev median and breaks it into receive and transmit metrics from the perspective of the basket2 instance that generated the log (client or server). For example, we see here that even for Null padding receiving (for a server) has goodput 95% while transmit has 97% goodput. Further, we see that all methods (that should be used) have significant impact on goodput. The APE method is a new padding method and the subject of the next update.