Linux Ethernet Stack Limiting Performance

Jeff,

Using the DM365 developing on the TI EVM and running DVSDK 4.00 GA, we find that the out-of-the-box encode application (upon which our application is based) exhibits periodic, significant frame rate drops that, at least at first, seemed to be related to NFS file I/O using Ethernet.  Please see my recent post on this subject for details: http://e2e.ti.com/support/embedded/f/354/t/83671.aspx

We first believed that the problem was related directly to the file writer routine but we now suspect that the issue is more subtle in that the root cause(s) may be related to improper buffer alloc and free in the DMAI layer, a simple memory leak, or possibly something in the IP stack effecting the low-latency expected by the application's file I/O thread.

Could you please elaborate a bit on your development configuration and how the problem you are experiencing is manifest?

--Chuck

Chuck, what data rates were you experiencing frame drop?  I'm streaming up to 4Mbps with no problems.  Haven't really tried going higher yet.

John A

John,

As I indicate at my previous post on this subject i.e., at http://e2e.ti.com/support/embedded/f/354/t/83671.aspx, the sudden frame rate drop occurs at low encoding bit rates (e.g., 1.5 Mb/s) as well as at moderately high encoding bit rates (e.g., 3 Mb/s or 5 Mb/s) although at higher bit rates the sudden, periodic frame rate drops happen sooner from the start of encoding, at a higher periodic rate, and the frame rate drop is more severe.

Recall that we are using the DVSDK 4.00 encode application unmodified on the DM365 EVM: I'm not sure whether this problem is related to something in the encoding engine interface, something in the DMAI layer, in the application itself, e.g., something about the way buffers are allocated and freed, or something in the kernel IP stack.  We do not recall seeing this when using DVSDK 2.10 but I plan to verify that that is the case.

--Chuck

Chuck,

I'm using dvsdk 4_00_00_22 and streaming H.264 to the network.  I'm using VLC as a decoder and have found in the past with MPEG-4 that VLC will fail if the timing information in the frames is not consistant.  So far I've had no problems and can get VLC to decode continuously for long periods without stopping.  The timestamp information I put in the RTP packet is a simple increment of the inter-frame interval.  If I was dropping frames then I would expect VLC to fail in a short period of time.

My code is a simple derivation of the encode example with a SPS/PPS parser and a RTP writer replacing the file writer.  I'm also using NFS for my file system, but not much file activity is going on while streaming.

John A

John,

   Thank you for describing your application configuration: it's interesting that your streaming application has successfully avoided the problem that I'm experiencing. In addition to your experience, this reply that I received from Vincent at http://e2e.ti.com/support/embedded/f/354/p/83671/290289.aspx#290289 seems to indicate that there are known issues with the encode application writer thread to the NFS.

   As Vincent suggests, I plan to set up an SD card file system so that the encode application writer thread can write to the SD card instead of the NFS - I'll keep you posted as to how this works out.

Thanks again,

Chuck