spike saturation

[Alfonso Yamamoto]

Hi spinnaker team,

I am trying to understand the mapping of population to cores and the spike processing and related problems.

Currently I have a population of neurons (own model but similar to LIF), I use a FromListConnector since I am setting specific weights for each connection, and as an input I use an i_offset to have a constant input. So a singles population with just connection between its neurons.

Now the problem arises when the size of the network increases, even for say 100 neurons I start to get this errors (image)

I guess that the buffer that holds the synaptic inputs gets saturated from the number of incoming synapses. I tried decreasing the time step and increasing the time_scale_factor, but that only helped for small network sizes.

So I have the following questions:

What is the effect of time_scale_factor ? 

What strategies would you recommend for solving this issue of saturation?

How are populations mapped to cores and how does the synapses relate to this 

Thanks,

Alfonso 

[Christian Brenninkmeijer]

The main problem here is the use of a single Population .

This means that every singe spike must be sent to every single core and only after it is received can  the FromListCommenction / Synapses be checked to see if the core is actually interesting and if so to which neurons.

It also has to check (highly optimised but still work) which of the neurons on that core are interested in the spike so the more neurons per core the more work.

So if you are able to break the network into logical smaller population this will help.

The Population are placed onto cores in blocks of neurons.

There is never more than 1 Population on a core so the split inti logical smaller Populations helps here.

For most model types we place up to 256 neurons on a single core.

So in your example it is likely to place the whole model on a single core with every single spike processed on that 1 core.

A command like 

sim.set_number_of_neurons_per_core(sim.IF_curr_exp, 25)

Will tell the network to split that model type onto more cores which also will help.

---

The FromListConnector while by far the most flexible connector is also the slowest to load and one where the least optimization can happen in deciding which spikes to send to which cores.

Once you have split your network into smaller logical Population change to using OneToOne or AllToAll connectors where possible.
 
--

The TimeStep determines how fast in real time the network will run. So decreasing the timestep will make this a lot worse..

--
The TimeScaleFactor allows the network to run faster (or more typically) slower
So increasing your timescale factor to say 10 will give the network a lot longer to process each spike and will help here.
This is the easiest fix and will help with your single Population network for a while.

--
However as the network gets larger especially when it gets into the tens of thousands and beyond into the millions the only way is to describe your network better with logical sub populations and where possible avoiding the FromListConnector.

regards
Christian
University Of Manchester

---

From: spinnak...@googlegroups.com <spinnak...@googlegroups.com> on behalf of Alfonso Yamamoto <alfyama...@gmail.com>
Sent: 16 August 2024 13:19
To: SpiNNaker Users Group <spinnak...@googlegroups.com>
Subject: [SpiNNaker Mailing List] spike saturation

 

--
You received this message because you are subscribed to the Google Groups "SpiNNaker Users Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to spinnakeruser...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/spinnakerusers/19b5e151-a270-475b-a25f-51456975c5ccn%40googlegroups.com [groups.google.com].

[Alfonso Yamamoto]

Hi Christian,
Thanks for the reply it was really helpful.

Alfonso