Use a queue to speed up packet processing

[mundya]

Rather than immediately routing packets to filters add them to a queue for later processing. This reduces the time taken to remove packets from the network, consequently it reduces the number of dropped packets.

---

• [ ] Add a more informative commit message
• [x] Do better than defaulting to a fixed queue size?
• [x] More thorough testing
• [ ] How to report "dropped" [unqueued] packets?

[mundya]

How to report "dropped" [unqueued] packets?

Could report the count in SDRAM (possibly the SV struct?). This probably should be combined with the simulator recording the number of dropped packets as well.

[neworderofjamie]

PyNN SpiNNaker has a region where we just shove various counters like this (spin1 API task queue overruns and various application-specific counters) - it just requires the c++ code to enumerate the counters and the python to give them some labels and do something sensible with them. Another area of commonality?

On 2 November 2016 at 08:29, Andrew Mundy notifications@github.com wrote:

How to report "dropped" [unqueued] packets?

Could report the count in SDRAM (possibly the SV struct?). This probably should be combined with the simulator recording the number of dropped packets as well.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/project-rig/nengo_spinnaker/pull/143#issuecomment-257801563, or mute the thread https://github.com/notifications/unsubscribe-auth/AGeoGhyGmjYHZY6qF0gKX9fSGct6yYNtks5q6EoCgaJpZM4KmD_A .

[mundya]

• [x] Update the DTCM constraints in the operators which are partitioned to account for the amount used to store the queue.

[neworderofjamie]

Looks good to me

[mundya]

Reporting dropped/unqueued packets should be a later PR. @neworderofjamie we should discuss what commonality there is.