test show that for small content the Advanced Monitors are actually worse.
Limited testing showed
for very small data (under 100 bytes) Advance Monitors where very poor
for very large data (over 100,000 bytes advance monitors where much faster)
12800 bytes 50 packets appears a reasonable toggle point
There is a cfg disable_advanced_monitor_usage_for_data_in
But that is an all or nothing approach
This PR automatically switches between the 2 strategies.
If No ds regiond's content is larger than the cutoff
EDIT: Fixed routes are still created, loaded and reported. But the report now has a cfg flag False by default
Python
Router timeouts are not changed
Simple load is used everywhere
Java
called as if disable_advanced_monitor_usage_for_data_in was true
No Java code change needed
If one or more content is larger
Python
Router timeouts are created
For each content the choice is made which to use
Java
For each content the choice is made which to use
See:
test show that for small content the Advanced Monitors are actually worse.
Limited testing showed for very small data (under 100 bytes) Advance Monitors where very poor for very large data (over 100,000 bytes advance monitors where much faster) 12800 bytes 50 packets appears a reasonable toggle point
There is a cfg disable_advanced_monitor_usage_for_data_in But that is an all or nothing approach
This PR automatically switches between the 2 strategies.
If No ds regiond's content is larger than the cutoff EDIT: Fixed routes are still created, loaded and reported. But the report now has a cfg flag False by default
Python
If one or more content is larger Python Router timeouts are created For each content the choice is made which to use Java For each content the choice is made which to use See:
Must be done at the same time as: https://github.com/SpiNNakerManchester/sPyNNaker/pull/1472
Tested by: https://github.com/SpiNNakerManchester/sPyNNaker/pull/1472 https://github.com/SpiNNakerManchester/IntegrationTests/pull/281