diff options
Diffstat (limited to 'src/DEVELOPMENT')
| -rw-r--r-- | src/DEVELOPMENT | 10 |
1 files changed, 9 insertions, 1 deletions
diff --git a/src/DEVELOPMENT b/src/DEVELOPMENT index a40e2bb..18a8011 100644 --- a/src/DEVELOPMENT +++ b/src/DEVELOPMENT @@ -25,7 +25,15 @@ Problems speeding up (that was always like that). And during this period a significant desynchronization happens. To compensate it, we need about 400 buffers with libvma as compared to only 10 required if standard Linux networking is utilized. - - Can we pre-heat to avoid this speeding-up problem? Or it will be also not a problem with hardware? + - In any case (LibVMA or not), some packets will be lost in the beginning if high-speed communication is tested. + * Usually, first packets are transferred OK, but, then, a few packets will be lost occasionally here and there + (resulting in broken frames). This basically breaks grabbing a few packets and exitig. Unclear if server- or + client-side problem (makes sense to see how real-hardware will behave). + * Can we pre-heat to avoid this speeding-up problem (increase pre-allocated buffers, disable power-saving + mode, ??) Or it will be also not a problem with hardware? We can send UDP packets (should be send from another + host), but packets are still lost: + for i in $(seq 4000 4015); do echo "data" > /dev/udp/192.168.34.84/$i; done + * The following doesn't help: new version of libvma, tunning of the options. - Communication breaks with small MTU sizes (bellow 1500), but this is probably not important (Packets are delivered but with extreme latencies. Probably some tunning of network stack is required). - Technically, everything should work if we start UFO server when data is already streamed. However, the first |