Tried doing some searches here but I couldn't actually find and answer to this. Let's say I'm putting in a 1-byte rolling sequence number in each of my packets. On the receiving end, what's the cheapest way to calculate packet loss purely for statistics reporting (don't care about reliability, etc.)?

unsigned char lastSeq;

int packetLossPercent(unsigned char newSeq) {
  if (newSeq == lastSeq || (unsigned char)(newSeq - lastSeq) >= 128) {
    // out-of-order packet
    return 0;
  }
  unsigned char ret = 100 - 100 / (newSeq - lastSeq);
  lastSeq = newSeq;
  return ret;
}

Call this for each packet you receive, and set the estimate to the value returned.

The one problem I'm having with that is that I'm using a dejitter buffer, so an out of order packet actually isn't necessarily bad and could still be safely processed at a higher level. Is there an alternative that takes this into account? In that snippet a newSeq of 132 vs. a lastSeq of 134 would return 0 but both could safely be passed to the dejitter buffer and processed in time.

I basically just want this as a way of reporting to the player why things might be behaving poorly if they're playing on a Starbucks wifi next to a microwave. Doesn't have to be very precise, but I'd like it to be as accurate as possible.

* It depends on what kind of protocol are you using.

You may use something in the header of the packet for checking. Maybe some kind of id that is usually sequential.

* A reverse approach would be pinging back the server/client.

One thing I've seen is a little meter of bars marching right-to-left, with a bar for number of packets received per second, and a red dot for each second that shows up if at least one packet X wasn't available by the time X was needed (after dejitter.)
Each bar is like 4 pixels wide and the entire thing is perhaps 100 pixels wide, showing the last 20 seconds of quality.

That works. I could bin by the second and record the number of packets recorded in that second in the appropriate bin using a cyclic buffer. Then a smooth, more or less level graph would indicate good connection quality, while a fluctuating graph would indicate poor connection quality. I could also easily get an average ping per second using more or less the same bins.

Unfortunately, "wasn't available by the time X was needed" is actually complicated in my system. I do a per-entity dejitter, with different send rates for each entity, so knowing whether an arbitrary packet arrived with data just in time is actually a per-entity decision and not really something I could express in a quality meter.

EDIT: I'm actually going to try another approach. Will try to update once that's done.

Just wanted to post an update on what I decided to do.

My packet header is now 8 bytes containing the following:

private NetPacketType packetType; // 4 bits
private ushort processTime;       // 12 bits
private byte sequence;            // 8 bits
private ushort pingStamp;         // 16 bits
private ushort pongStamp;         // 16 bits
private float loss;               // 8 bits