Skip to main content
Participant
December 21, 2009
Question

Billing from FMS access logs

  • December 21, 2009
  • 1 reply
  • 713 views

I'm trying to compute the bytes delivered using the sc-bytes field of the access logs with FMS 3.5 and its seems completely wrong.   I'm taking the value of sc-bytes for the "stop" event and subtracting the sc-bytes for the "play" event.   At the same time, I'm using tcpdump to capture all the bytes being delivered to the client in this stream.   My numbers are looking something like this: For a 100 MB video file, my machine receives roughly 150 MB, but FMS sc-bytes is reporting about 400 MB.   Am I doing something wrong or is this a known issue with FMS?

    This topic has been closed for replies.

    1 reply

    Asa_-_FMS
    Adobe Employee
    Adobe Employee
    December 22, 2009

    No known issue here as those are some of the more scrutinized area of FMS.  Most major FMS partners do just what you're doing there to bill, so those numbers have been vetted more than a few times.  Some things to consider

    1.  sc-stream-bytes is really what you want if you're billing on content, because that's what the customer is seeing.  sc-bytes is that plus control traffic, rtmp overhead, etc - consequently it's your choice but if we're talking pure content most use this as they may/may not consider the RTMP overhead part of their load here

    2.  TCP dump is going to have even more overhead because you're accounting for TCP/IP overhead on stream and that's something that FMS doesn't account for in either sc-stream-bytes or sc-bytes.  Realistically it can't as it's obfuscated from that TCP/IP does at that layer (for example how does it want to track a TCP retransmit)

    3.  Simple play-through vs seek/buffering.  Since FMS can seek, or buffer play for some space of data unviewed for baseline billing tests you'll want to make sure it's a simple play from beginning to end as well to set your metrics.  If the customer is seeking, pausing and then closing, etc then this number will also be inaccurate.

    Hope that helps,

    Asa

    vgattoAuthor
    Participant
    December 22, 2009

    Can you elaborate on your third point?   Are they inaccurate in the sense that if I measured the bytes being delivered vs. those reported that the numbers would be off?