Yes, you have clearly gained something here with a larger log buffer,
and in a batch environment that is more important than the commit
response time. Anyway, a 560K log buffer is not exactly huge. It is just
towards the upper end of the "normal" range, and the negative impact on
commit response time from needing to do bigger syncs would be no more
than 20ms. If your redo generation is intensive, then you may also be
doing better in terms of reduced contention for the 'redo allocation'
latch. So what you've done seems right.

However, for future reference, the 'redo buffer allocation retries'
statistic is not as helpful here as 'log buffer space' waits, because it
includes retries after log switches as well as those related to buffer
space.

Also, your suggestion that you have 8192 byte log buffer blocks
surprises me. I am not aware of any platform on which Oracle uses an 8K
log block size. Could you please check using my log_block_size.sql
script.

I ask this because I've been upping log_buffers on an at times very
batch intensive database from
20 8192 byte buffers and 8,700 redo buffer allocation retries per day to
current 70 8192 byte buffers,
and 261 redo buffer allocation retries per day.