The timing interfaces from bug 576006 need to be implemented for e10s as well.

So I started working on this, but... anyone have suggestions for how to serialize a TimeStamp? :(

Looks like it's just a PRUint64 ultimately (see TimeStamp.h). Should be easy ParamTraits logic. See for instance how we serialize RequestHeaderTuple in http//PHttpChannelParams.h (but you'll want to put the TimeStamp paramtraits logic in necko/ipc/NeckoMessageUtils.h, I assume).

It's not clear that the PRUint64 value from one process makes any sense in another process. Chris, thoughts?

Not at all. bz is right. What value in what units are we trying to serialize from what process type on what platform to what process type on that platform?

We're trying to expose timing information about in-page events (content process) and network events (chrome process) with respect to a single monotonic clock, however we go about doing that.

We can rely on CLOCK_MONOTONIC being calibrated the same across processes. No issue there. The easiest/best fix for other platforms is probably just to implement high-resolution timing for them with platform interfaces. It looks like mach_absolute_time() is the way on mac, and QPC seems to be what folks use on windows. See bug 539093 and deps. It would be moderately tricky to have PR_IntervalNow()-backed TimeStamp values that make sense across processes, and it probably isn't worth the investment. For the time being, falling back on real-time clocks for this would probably be easier.

is this still outstanding? probly should do if so

HttpChannelChild extends HttpBaseChannel which implements nsITimedChannel (done in bug 822480) However, DataChannelChild/WebsocketChannelChild/etc don't implement the timing interface. Should they?

if their parent's do it so should the children in this case..

HttpBaseChannel seems to be the only one implementing this interface, so I think this is fixed.