Initial look at the latency of all rebids

In conjunction with the transition to Five Minute Settlement (amongst other projects) we implemented a major enhancement to the ‘bids analysis’ function inside of ez2view with the release of version 9.1:

Already since the release of this version, it’s been garnering compliments from our clients.

As part of the verification work performed conducted in the upgrade process, one of our team members compiled the following stats that encapsulate the ‘latency of rebid’:

1)  Spanning roughly 21 recent months of NEM operations and

2)  Almost 10,000,000 rebids received at the AEMO over that period.

The x-axis in the chart measures the time (prior to the start of the dispatch interval) at which AEMO received the rebid, whilst the y-axis counts the number of rebids received in that particular second.  I have highlighted a few points on the chart, and would add these initial comments:

(1)  In this chart, the dispatch interval that first considered the rebid as part of dispatch started at 0 seconds.

(2)  However in order for NEMDE to ‘do all of its thing’ for the dispatch interval, we can clearly see that there’s a ‘Gate Closure’ at approximately -60 seconds (about 1 minute out from the start of the dispatch interval), beyond which rebids are too late and can’t be accepted.

(3)  As a result of this Gate Closure, there are a fair number of these rebids which:

(3a)  Reference what is going on in the market for D_I-2 and might have been intended, by the participant, for use in DI_-1, but are received too late by the AEMO;

(3b)  Hence instead have to wait 5 minutes for the next round of consideration, as part of the dispatch process for DI₀.

(3c)  In total, there are 544,023 bids in this group of bids prior to and including –300 seconds, which represents roughly 5.5% of the total…

(3d)  … however the calculation of ‘what percentage of bids were received too late for consideration’ would actually be more complex than that (and the percentage larger than 5.5%), because participants don’t see data for DI-1 from the AEMO until some time into the dispatch interval, which:

i.  Varies by data set (e.g. because of size, and what NEMDE does, etc)

ii.  In particular, has experienced its own latency issues for the P5 predispatch, as discussed with respect to Tripwire #4.

(4)  A little over 1 minute into the DI_–1 (i.e. at approx  -228 seconds) we see a sharp increase in the number of bids received … almost certainly the result of some automated bidding algorithm (with an interesting question being ‘which one(s)?’).

(5)  We’ve also highlighted a second spike almost 3 minutes into the DI_-1 (i.e. at approx -137 seconds) which is also of interest to us.

When our team member shared the above stats with us some weeks ago now, it generated a bit of internal discussion.

—

Now that we’re past the Five Minute Settlement deadline, and notwithstanding other work we need to do in relation to the Wholesale Demand Response Mechanism (including navigating Tripwire #3), we’ve started to return our focus to the completion of the GenInsights21 analytical assignment for a release in early December 2021.

Don’t forget you can pre-order your own copy of the upcoming release now and save on what the price will be when it is released.

So I dug these stats out, and we’ve polished them in a couple ways to make them more understandable, to share with you here today.

For people like us, going this far only raises more questions … which we hope to have time to delve into before the release of ‘Generator Insights 2021’!