Whilst there are many aspects to this, there are 2 things for you to consider first.
The fact you are using 2 separate Pi’s and 2 separate emonhub’s isn’t helping much. both buffer and deliver to emoncms.org in batches, these batches may or may not be simultaneous, but they will never be as reliable as coming via a single emonhub, where are they physically installed? could you use just the one? even with 2 bluetooth dongles if needed?
Assuming they can’t, you could alleviate the issue a little by setting the http interfacer update interval to 0s or 1s ( it’s been a long time since I played with this so I can’t be sure 0 works) to remove any “batch sending” thus the inputs should be sent immediately to emoncms.org. This isn’t anything to do with buffering (for network outages etc, although that too can be an issue) it is purely where the sends to emoncms.org are limited to one every 30s (by default) to ease traffic at emoncms.org.
The problem you are seeing could be due to (say) one emonhub posting 30s of data (3x sets of 10s data) and then 3s later the other emonhub sends the corresponding 30s of data (3x 10s sets) but it’s too late the total has been written in the first emonhub input updates OR if the totalling in in the second emonhub’s input processing it will use the very latest values from the first emonhub to calculate the totals for each of the second set of 3 updates. Because of the “batched” sending the inputs are not being updated entirely in chronological order.
The second is the start times of all the feeds in question. use can query that info via the feed api with https://emoncms.org/feed/getmeta.json?id=1. Even if you sort the inputs, if the feeds are misaligned, the results will still be skewed. I would try to make sure all feeds are using a start time that aligns the slots, I tend to only use timestamps that are a multiple of 10 (I have written about “harmonised” intervals and timestamps else where on the forum but it isn’t something that draws much interest). You cannot edit feed start times, but you can create feeds with an exact controlled timestamp by purposefully ensuring the first recorded data uses the timestamp of your choosing before starting to log data too it, the first data determines the start time, not the time of creation.
Knowing all your feeds are aligned means that you will get consistent data when graphing because it will always report the corresponding values for that same timeslot not the sometimes the adjacent slot, depending on the exact second the query is run each time.