Need some information on network models used in Sniper

[Krishnaiah]

Hi All,

Please, could anyone provide some information on the network models in Sniper or a pointer where I can find detailed information on this? 

I just started looking at the Sniper source and have these specific questions:

• What are these different types on network in sniper?  Why do we have so many networks and what does each one cater to?
  

user_model_1 = emesh_hop_counter 

user_model_2 = emesh_hop_counter 

memory_model_1 = emesh_hop_counter 

memory_model_2 = emesh_hop_counter 

system_model = magic

•  I am interested in writing my own network which supports the messages between private (coherent) caches and a shared memory (say DRAM). Could someone suggest a right place to start from, and which one of the above network(s) that I should be using?
  

Thanks,

Krishnaiah

[Wim Heirman]

Hi Krishnaiah,

In Sniper, only the memory_model_1 model is used, which transports
coherency traffic and requests to DRAM. The other models were used in
Graphite but not in Sniper, we'll remove them in a future version.

To create your own network model, you'll have to implement a new class
that derives from NetworkModel, and adapt NetworkModel::createModel
(in sniper/common/network/network_model.cc) to return an instance of
it when the configuration requests it. Your new NetworkModel class
will have to implement the routePacket() and processReceivedPacket()
functions. routePacket() is called for each hop a packet traverses, it
should update the packet's current timestamp and update nextHops with
the next hop (it's a list so you can do multicast, unicast packets
just have one next hop). processReceivedPacket() is called once the
packet reaches its destination and allows you to update statistics
such as average latency.

For a really simple example, take a look at the bus network which is
implemented in sniper/common/network/network_model_bus.cc. All it does
is return the destination as the next hop, and update a contention
model that represents shared bandwidth. The EMeshHopByHop network (in
sniper/common/network/network_model_emesh_hop_by_hop) is a bit more
complex but may be a good starting point for your own network.

Hope this helps, and let us know if you have any problems!

Regards,
Wim

> --
> --
> You received this message because you are subscribed to the Google
> Groups "Sniper simulator" group.
> To post to this group, send email to snip...@googlegroups.com
> To unsubscribe from this group, send email to
> snipersim+...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/snipersim?hl=en

[Daniel Hofman]

Regarding tho NoC and emesh_hop_by_hop.

I tried using 16 cores, 4x4 mesh and I'm getting some weird data when using cores 0,1,2,3 which are just threads reading from one file and reading and writing to some memory locations.

1) topology is like in the attached picture - only little traffic going from right to left in the first row but not in reverse :)?

network.shmem-1.mesh.link-up.num-requests = 6393, 0, 0, 0, 4248, 0, 0, 0, 2134, 0, 0, 0, 0, 0, 0, 0

network.shmem-1.mesh.link-down.num-requests = 0, 0, 0, 0, 6393, 0, 0, 0, 4248, 0, 0, 0, 2134, 0, 0, 0

network.shmem-1.mesh.link-left.num-requests = 0, 446, 400, 314, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0

network.shmem-1.mesh.link-right.num-requests = 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0

2) logs from app_0.log, app_1.log, app_2.log, app_3.log had some data which is ok. 

but sim_0.log, sim_4.log, sim_8.log, sim_12.log also had similar data (instead of sim 0,1,2,3)

3) also there were lines like this in the log files

314907397  [ 1788]  [ 3]  [network.cc          : 164]  Send packet : type 1, from 0, to 4, next_hop 2, core_id 3, time 759059380621

...

314983113  [ 1788]  [ 3]  [network.cc          : 164]  Send packet : type 1, from 0, to 12, next_hop 2, core_id 3, time 759289637385

I used newest version of sniper (5.2.)

./run-sniper -n 16 -c gainestown -c noc --viz -- application

With changed noc.cfg and logging enabled:

[network]

memory_model_1 = emesh_hop_by_hop

memory_model_2 = emesh_hop_by_hop

[network/emesh_hop_by_hop]

hop_latency = 2            # Per-hop latency in core cycles

link_bandwidth = 64        # Per-link, per-direction bandwidth in bits/cycle

dimensions = 2             # Mesh dimensions (1 for line/ring, 2 for mesh/torus)

wrap_around = false         # Has wrap-around links? (false for line/mesh, true for ring/torus)

concentration = 1          # Number of cores per network interface (must be >= last-level-cache/shared_cores)

if you need some more info please let me know.

[Wim Heirman]

Daniel,

The gainestown default configuration models a LLC shared by four cores. Note the comment "must be >= last-level-cache/shared_cores" for the concentration parameter, you cannot legally define a configuration where a shared cache spans multiple network tiles. This is breaking all kinds of assumptions, leading to the weird network traffic, and also causes the warnings you mentioned in (3).

You'll probably want to remove the LLC by setting perf_model/cache/levels=2, or have a private L3 for each core with perf_model/l3_cache/shared_cores=1

Regards,

Wim

--

--
--
You received this message because you are subscribed to the Google
Groups "Sniper simulator" group.
To post to this group, send email to snip...@googlegroups.com
To unsubscribe from this group, send email to
snipersim+...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/snipersim?hl=en
 

---

You received this message because you are subscribed to the Google Groups "Sniper simulator" group.

To unsubscribe from this group and stop receiving emails from it, send an email to snipersim+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Daniel Hofman]

Hi Wim,

thank you for your answer. One more thing, is the up and down link name mixed in the topology image? Left and right seems ok but as I see the one that is called up is actually going from the tile to the south and not to the north :)

Regards,

   Daniel

[Wim Heirman]

Daniel,

You might be right. Up probably goes to higher-numbered cores, while the topology graphic plots core 0 on the top left...

-Wim

[Daniel Hofman]

Seems reasonable to me. I have changed it in my version to represent the right direction.

thnx,

  Daniel

[T]

Hello,

For version 6.0 in simper there is still the network has config file has the following option:

[network]

collect_traffic_matrix = "false"

memory_model_1 = "bus"

memory_model_2 = "bus"

system_model = "magic"

I'm not sure what the differences are in these models as it relates to the system level model. Is the memory model the network between the core and LLC and the system is the network between the DRAM and the system cores.

I'm really looking to use the sniper tool as is, since I don't have time to make program changes I am trying to have a clear understanding (Conceptually) how the network is model in Sniper and what options are available. The file noc.cfg is meant to change the network model from cache to DRAM correct? 

[network]

memory_model_1 = emesh_hop_by_hop

 

[network/emesh_hop_by_hop]

hop_latency = 2            # Per-hop latency in core cycles

link_bandwidth = 64        # Per-link, per-direction bandwidth in bits/cycle

dimensions = 1             # Mesh dimensions (1 for line/ring, 2 for mesh/torus)

wrap_around = true         # Has wrap-around links? (false for line/mesh, true for ring/torus)

concentration = 1          # Number of cores per network interface (must be >= last-level-cache/shared_cores)

Thanks,

T

[Wim Heirman]

T,

The only network used in Sniper is the "memory_model_1" one. The others are used by the Graphite simulator, of which Sniper is derived, but we no longer use them.

The network is conceptually between the different LLCs and DRAM. You can use it in two ways: either as a multi-socket system where each socket has a shared LLC and locally connected DRAM, in this case the network models the QPI interface -- this mode is used in the gainestown configuration which models an Intel Nehalem-like system.

The second use case is where you have a single processor chip with multiple LLCs connected through an on-chip network, such as an Intel Knights Corner. An example for this type of system is kingscross.cfg which simulates a KNC-inspired architecture.

Regards,

Wim

--

--
--
You received this message because you are subscribed to the Google
Groups "Sniper simulator" group.
To post to this group, send email to snip...@googlegroups.com
To unsubscribe from this group, send email to
snipersim+...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/snipersim?hl=en

---

You received this message because you are subscribed to the Google Groups "Sniper simulator" group.

To unsubscribe from this group and stop receiving emails from it, send an email to snipersim+...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[T]

Thanks Wim,

This information was very helpful, I will review the material you have provided below.

Thank you again for the insight,

T