test performance worsens dramatically after about 2300 sent packets

[mdonahoe]

While running ./tester, I noticed the receive rate suddenly plummets from 99% to below 60% after 2300 sent packets.

2275 of 2290 : 0.99345
2276 of 2291 : 0.993453
2277 of 2292 : 0.993455
2278 of 2293 : 0.993458
2279 of 2294 : 0.993461
2280 of 2295 : 0.993464
2282 of 2296 : 0.993902
2283 of 2297 : 0.993905
2284 of 2298 : 0.993908
2285 of 2299 : 0.99391
2286 of 2300 : 0.993913
2287 of 2301 : 0.993916
2288 of 2302 : 0.993918
2289 of 2303 : 0.993921
2290 of 2304 : 0.993924
2291 of 2305 : 0.993926
2291 of 2306 : 0.993495
2292 of 2307 : 0.993498
2293 of 2308 : 0.993501
2294 of 2309 : 0.993504
2294 of 2310 : 0.993074
2295 of 2311 : 0.993077
2296 of 2312 : 0.99308
2296 of 2313 : 0.99265
2296 of 2314 : 0.992221
2296 of 2315 : 0.991793
2298 of 2316 : 0.992228
2298 of 2317 : 0.9918
2298 of 2318 : 0.991372
2298 of 2319 : 0.990944
2298 of 2320 : 0.990517
2298 of 2321 : 0.99009  <--- 5 unreceived packets in-a-row
2299 of 2322 : 0.990095
2299 of 2323 : 0.989669
2299 of 2324 : 0.989243
2299 of 2325 : 0.988817
2299 of 2326 : 0.988392
2299 of 2327 : 0.987967
2299 of 2328 : 0.987543
2299 of 2329 : 0.987119
2299 of 2330 : 0.986695 <--- another 8
... snip ...
5101 of 8511 : 0.599342
5101 of 8512 : 0.599272
5101 of 8513 : 0.599201
5101 of 8514 : 0.599131
5101 of 8515 : 0.59906
5101 of 8516 : 0.59899
5101 of 8517 : 0.59892
5101 of 8518 : 0.598849
5101 of 8519 : 0.598779
5102 of 8520 : 0.598826
5102 of 8521 : 0.598756
5102 of 8522 : 0.598686
5102 of 8523 : 0.598616
5102 of 8524 : 0.598545
5102 of 8525 : 0.598475
5102 of 8526 : 0.598405
5102 of 8527 : 0.598335

What is especially concerning is that this happens even if I remove the simulated packet loss.

2299 of 2299 : 1
2300 of 2300 : 1
2301 of 2301 : 1
2302 of 2302 : 1
2303 of 2303 : 1
2304 of 2304 : 1
2305 of 2305 : 1
2306 of 2306 : 1
2307 of 2307 : 1
2308 of 2308 : 1
2309 of 2309 : 1
2309 of 2310 : 0.999567
2309 of 2311 : 0.999135
2309 of 2312 : 0.998702
2309 of 2313 : 0.998271
2309 of 2314 : 0.997839
2309 of 2315 : 0.997408
2309 of 2316 : 0.996978
2309 of 2317 : 0.996547
2310 of 2318 : 0.996549
2310 of 2319 : 0.996119
2310 of 2320 : 0.99569
2310 of 2321 : 0.995261
2310 of 2322 : 0.994832
2310 of 2323 : 0.994404
2310 of 2324 : 0.993976
2310 of 2325 : 0.993548
2310 of 2326 : 0.993121
2311 of 2327 : 0.993124

After further experimentation, the drop point appears to happen sooner with a larger TICK_RATE, unless TICK_RATE >= settings.max_delay, at which point it doesn't seem to drop at all.

I've tested this on Mac OSX El Capitan and Ubuntu 14.04 (with gcc).

Any ideas what is going on here? Am I missing something fundamental about the nature of this library?

[mdonahoe]

Looks like this is the result of group reuse before they have been cleaned out. The packets start disappearing after the group number loops back around.

If I checkout the commit before 24c143a (Add more robust group closing system), the test works

[catid]

Oh sorry for ignoring you. I haven't looked at this project in ages. It would be a good idea to fix this problem so will add it to my TODO list.

The Siamese project is a much better project for speeding up reliable in-order data like streaming lossless media or data.

I don't have a good codec for doing what Shorthair was for yet. The closest one is trevi:
https://github.com/catid/trevi

I'm thinking about writing my own version of that type of codec...

[catid]

Found the bug: GROUP_TIMEOUT was set too high

[catid]

This old code is really hard to incorporate into anything with submodules and stuff. Going to refactor the hell out of this in a minute