Public TODO list (3 matches)
Status: accepted (1 match)
| Ticket | Priority | Owner | Created | Summary | Modified |
|---|---|---|---|---|---|
| #23 | minor | 14 years ago | Integrate code security analysis tools into Buildbot | 16 months ago | |
| Description |
In the IRC meeting on 22nd Apr 2010 it was agreed that all patches should be checked with (security) auditing tools such as Valgrind and Coverity. These tools need to be integrated into our Continuous integration server app, Buildbot.
|
||||
Status: assigned (1 match) |
|||||
| Ticket | Priority | Owner | Created | Summary | Modified |
| #269 | major | 11 years ago | Port SVN r8219 ("Minor fix to process_ipv4_header") to Git master | 16 months ago | |
Status: new (1 match) |
|||||
| Ticket | Priority | Owner | Created | Summary | Modified |
| #949 | major | 7 years ago | Forward Error Correction for OpenVPN | 2 years ago | |
| Description |
As discussed in this thread,FEC can improve the connection quality on a lossy link: https://forums.openvpn.net/viewtopic.php?f=10&t=14395 I have implemented the feature and did some test.The algorithm for FEC is Reed-Solomon. Test Resultenvironmentopenvpn client running inside a single core VPS in Tokyo,with 512mb ram openvpn server running inside a single core VPS in Los Angeles,with 128mb ram. The network roundtrip between two machines is about 110~120ms.A simulated packet loss of 10% is introduced at both direction. The parameter for FEC is 20:10,that means sending 10 redundant packets for every 20 original packets.It costs about 1.5 times of bandwidth when compared with original data stream.(A packet loss of 10% is actually very high. For lower packet loss,sure,you can reduce the FEC parameter and use less bandwidth) SCP TCP single thread copy testOpenVPN without FEC $ scp 0.test.file 10.222.2.1:~ root@10.222.2.1's password: 0.test.file 0% 3600KB 29.5KB/s 3:25:38 ETA OpenVPN with FEC $ scp 0.test.file 10.222.2.1:~ root@10.222.2.1's password: 0.test.file 45% 162MB 3.6MB/s 00:55 ETA ping packet loss testOpenVPN without FEC $ ping 10.222.2.1 -O PING 10.222.2.1 (10.222.2.1) 56(84) bytes of data. 64 bytes from 10.222.2.1: icmp_seq=1 ttl=64 time=118 ms 64 bytes from 10.222.2.1: icmp_seq=2 ttl=64 time=118 ms 64 bytes from 10.222.2.1: icmp_seq=3 ttl=64 time=118 ms 64 bytes from 10.222.2.1: icmp_seq=4 ttl=64 time=118 ms no answer yet for icmp_seq=5 64 bytes from 10.222.2.1: icmp_seq=6 ttl=64 time=118 ms 64 bytes from 10.222.2.1: icmp_seq=7 ttl=64 time=118 ms 64 bytes from 10.222.2.1: icmp_seq=8 ttl=64 time=118 ms no answer yet for icmp_seq=9 64 bytes from 10.222.2.1: icmp_seq=10 ttl=64 time=118 ms 64 bytes from 10.222.2.1: icmp_seq=11 ttl=64 time=118 ms no answer yet for icmp_seq=12 64 bytes from 10.222.2.1: icmp_seq=13 ttl=64 time=118 ms 64 bytes from 10.222.2.1: icmp_seq=14 ttl=64 time=118 ms no answer yet for icmp_seq=15 64 bytes from 10.222.2.1: icmp_seq=16 ttl=64 time=118 ms 64 bytes from 10.222.2.1: icmp_seq=17 ttl=64 time=118 ms 64 bytes from 10.222.2.1: icmp_seq=18 ttl=64 time=118 ms 64 bytes from 10.222.2.1: icmp_seq=19 ttl=64 time=118 ms 64 bytes from 10.222.2.1: icmp_seq=20 ttl=64 time=118 ms no answer yet for icmp_seq=21 64 bytes from 10.222.2.1: icmp_seq=22 ttl=64 time=118 ms 64 bytes from 10.222.2.1: icmp_seq=23 ttl=64 time=118 ms no answer yet for icmp_seq=24 64 bytes from 10.222.2.1: icmp_seq=25 ttl=64 time=119 ms 64 bytes from 10.222.2.1: icmp_seq=26 ttl=64 time=118 ms no answer yet for icmp_seq=27 64 bytes from 10.222.2.1: icmp_seq=28 ttl=64 time=118 ms 64 bytes from 10.222.2.1: icmp_seq=29 ttl=64 time=118 ms 64 bytes from 10.222.2.1: icmp_seq=30 ttl=64 time=119 ms 64 bytes from 10.222.2.1: icmp_seq=31 ttl=64 time=118 ms no answer yet for icmp_seq=32 64 bytes from 10.222.2.1: icmp_seq=33 ttl=64 time=118 ms 64 bytes from 10.222.2.1: icmp_seq=34 ttl=64 time=118 ms 64 bytes from 10.222.2.1: icmp_seq=35 ttl=64 time=118 ms 64 bytes from 10.222.2.1: icmp_seq=36 ttl=64 time=118 ms 64 bytes from 10.222.2.1: icmp_seq=37 ttl=64 time=118 ms 64 bytes from 10.222.2.1: icmp_seq=38 ttl=64 time=118 ms 64 bytes from 10.222.2.1: icmp_seq=39 ttl=64 time=118 ms 64 bytes from 10.222.2.1: icmp_seq=40 ttl=64 time=118 ms 64 bytes from 10.222.2.1: icmp_seq=41 ttl=64 time=118 ms no answer yet for icmp_seq=42 no answer yet for icmp_seq=43 64 bytes from 10.222.2.1: icmp_seq=44 ttl=64 time=118 ms ^C --- 10.222.2.1 ping statistics --- 44 packets transmitted, 34 received, 22% packet loss, time 43038ms rtt min/avg/max/mdev = 118.289/118.712/119.959/0.530 ms OpenVPN with FEC $ ping 10.222.2.1 -O PING 10.222.2.1 (10.222.2.1) 56(84) bytes of data. 64 bytes from 10.222.2.1: icmp_seq=1 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=2 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=3 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=4 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=5 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=6 ttl=64 time=129 ms 64 bytes from 10.222.2.1: icmp_seq=7 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=8 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=9 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=10 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=11 ttl=64 time=122 ms 64 bytes from 10.222.2.1: icmp_seq=12 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=13 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=14 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=15 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=16 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=17 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=18 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=19 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=20 ttl=64 time=129 ms 64 bytes from 10.222.2.1: icmp_seq=21 ttl=64 time=120 ms 64 bytes from 10.222.2.1: icmp_seq=22 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=23 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=24 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=25 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=26 ttl=64 time=137 ms 64 bytes from 10.222.2.1: icmp_seq=27 ttl=64 time=120 ms 64 bytes from 10.222.2.1: icmp_seq=28 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=29 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=30 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=31 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=32 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=33 ttl=64 time=120 ms 64 bytes from 10.222.2.1: icmp_seq=34 ttl=64 time=122 ms 64 bytes from 10.222.2.1: icmp_seq=35 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=36 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=37 ttl=64 time=121 ms 64 bytes from 10.222.2.1: icmp_seq=38 ttl=64 time=129 ms 64 bytes from 10.222.2.1: icmp_seq=39 ttl=64 time=120 ms 64 bytes from 10.222.2.1: icmp_seq=40 ttl=64 time=129 ms 64 bytes from 10.222.2.1: icmp_seq=41 ttl=64 time=129 ms ^C --- 10.222.2.1 ping statistics --- 41 packets transmitted, 41 received, 0% packet loss, time 40046ms rtt min/avg/max/mdev = 120.908/122.719/137.724/3.535 ms summaryLooks like it does have improved the connection quality on a lossy link. I hope this feature can be integrated into OpenVPN.I want to know how the developer team think about it. If the feature is acceptable,I can try to make patch. |
||||
Note: See TracQuery
for help on using queries.
