It’s Friday afternoon, and this short article returns to the theme of this ‘NEMDE under stain? Escalation in File Creation times for P5MIN’ article written 10 days ago (Tuesday 15th February 2022) … which followed from earlier articles on 15th August 2021, and 16th November 2021 and 4th December 2021.
I’m posting today because:
1) Last Sunday 20th February we had another client let us know that they were experiencing problems with their auto-bidder because of slow receipt of P5MIN data (Case 5770 for our reference, and that of our client); and
2) It’s the day before this coming weekend, so this article has being written to let people know we’ve not forgotten the keen interest in data latency.
(A) Stats over the past 7 days
Indeed, as noted in the earlier examples, our interest has increased in recent months (in line with the growth of that side of our business), to the point where we have upgraded our dashboarding to allow our whole team to easily keep an eye on how the service is performing in real time. As at 14:35 (NEM time) on Friday afternoon, here’s how File Creation Times at AEMO (for both P5MIN and DISPATCHIS files) looking back 7 days:
I have highlighted three things in particular:
1) There’s a spike for P5MIN (and also a significant spike for DISPATCHIS, on a relative basis) on Sunday afternoon last week 20th February 2022 (i.e. relating to the client query at that time – Case 5770); and
2) Around 19:00 on that Sunday evening, there was a definite step change reduction in latency of a couple of seconds (from ~45 seconds down to ~40 seconds), which …
(a) Might have been due to some automated process at the AEMO; or
(b) Might have been the result of some (manual) correction action taken at the AEMO … either triggered by some internal system, or by some external report?
3) For context, understand that my last article was published at 11:30 NEM time on Tuesday 15th February (and notified to AEMO at that time) … so several days before the 7-day window above starts.
With another weekend about to start, this article might be useful context to those clients also keenly watching file delivery latency into our various solutions!
(B) Stats over 3.5 years
After writing that last article, I reflected on why we were devoting a lot more attention in monitoring file creation latency than we were 18 months ago, say:
1) Part of the reason is that we’ve been serving an increasing number of clients with data feeds of various forms … including access to a Hosted MMS in Azure (either with their Private data or just with Public data).
2) With this service has come an increased number of questions from their clients about when data has been available more slowly than expected…
3) … with one of the factors, on occasions, being slower file creation at the AEMO.
4) However I reflect that the only reason why we started off and wrote this first article on 15th August 2021 was that what we’d been experiencing in the recent weeks leading into this had been significantly slower than what we had been conditioned to expect in the months leading into the July-August period.
I wondered how the performance stats would look if we scanned back further in history (i.e. many months) …
Scenario 1) would I see a similar pattern of ‘fast’ file creation over a longer time range and only see this jump in July-August 2021, which is what we’d implicitly assumed in posting that first article…
Scenario 2) or would I see something a bit more complex over a longer time range.
So on 15th February (i.e. immediately after posting that most recent article), one of our team crunched the numbers on the range of data we had easily at hand, which only extends back to 2018, and this is what we found:
So you can see that the more recent concerns began in July 2021 … hence triggering these 5 articles progressively since that time.
1) There is certainly a pronounced (and sustained) jump in maximums compared to the earlier part of 2021 and late 2020…
2) But it’s not been the only time in this historical range when file creation latency has been ‘bad’.
Excluding the monthly maximum points of this trend makes the situation a little clearer, in terms of how the performance since July 2021 has been ‘worst’ since December 2018.
The situation seems to be more complex than a simple cause … as it almost always is in the real world.
We’ll continue to monitor the situation … and know our clients are keenly following as well!
Has AEMO made any comment?
AEMO don’t seem very interested in fixing problems with their data and data systems that are public facing. I have raised several issues with errors in archive files and received no response, nor has the situation been rectified.
Due to the nature of AEMO, there doesn’t appear to be anyone to make an official complaint to regarding these issues.