SST-Macro calculation delay when switch is of type pisces

[sunsirui]

Dear All,

I have a question about SST-Macro calculation delay when switch is of type pisces

When the switch is of type pisces

switch { router { name = table } name = pisces arbitrator = cut_through mtu = 512 link { bandwidth = 200Gb/s latency = 130ns credits = 64KB } xbar { bandwidth = 16Tb/s } logp { bandwidth = 200Gb/s hop_latency = 116ns out_in_latency = 60ns } }

1. There must be a logp namespace, why is there a logp channel under pisces? a) For example, the following code is the content when switch.name=pisces, but it will judge port=logp multiple times.

void
PiscesNIC::connectOutput(int src_outport, int dst_inport, EventLink::ptr&& link)
{
  if (src_outport == Injection){
    inj_buffer_->setOutput(src_outport, dst_inport, std::move(link), inj_credits_);
  } else if (**src_outport == LogP**) {
    logp_link_ = std::move(link);
  } else {
    spkt_abort_printf("Invalid port %d in PiscesNIC::connectOutput", src_outport);
  }
}

b)And, even if switch.name=pisces, logp.switch will be called to calculate the delay in the bottom layer. (Why calculate switch time in pisces, call logp.switch)

2. When updating the time on the link, it seems that the situation between switches (irrelevant to the path) is not considered, and the results are the same no matter whether it is sent by the internal node of the switch or between the switches. (There are two or four paths that can actually be passed)

Thanks to anyone who may shed some light into this. -sirui

[jpkenny]

Hi, In macro simulations there is always a logp network set up to send messages that are considered negligible in size. You can control this cutoff using e.g.

node {
  nic {
    negligible_size = 0
  }
}

does this clarify the configuration and the behavior that you are observing?

[sunsirui]

Thank you for your answer, I have one more question. About sstmac_send(blocking) and sstmac_isend(non-blocking):

1. I test sstmac_isend(64 times) + sstmac_waitall(one time) = Latency_Isend; and sstmac_send(64 times) = Latency_Send. Find that Latency_Isend ~= Latency_Send. Is sstmac_isend (non-blocking) in sstmacro unimplemented?
2. And it is found in the test that the start time of the second transmission of MPI_Isend is the end time of the first message transmission.

Thanks to anyone who may shed some light into this. -sirui

[jpkenny]

A non-blocking send can’t make your network link have higher bandwidth, so I would expect the transfers in your example to take approximately the same amount of time. With a non-blocking send the application can do other useful work prior to the wait as opposed to the blocking send.

--Joe

From: sunsirui @.> Reply-To: sstsimulator/sst-macro @.> Date: Monday, November 29, 2021 at 11:13 PM To: sstsimulator/sst-macro @.> Cc: "Kenny, Joseph P" @.>, Comment @.***> Subject: [EXTERNAL] Re: [sstsimulator/sst-macro] SST-Macro calculation delay when switch is of type pisces (Issue #656)

Thank you for your answer, I have one more question. About sstmac_send(blocking) and sstmac_isend(non-blocking):

1. I test sstmac_isend(64 times) + sstmac_waitall(one time) = Latency_Isend; and sstmac_send(64 times) = Latency_Send. Find that Latency_Isend ~= Latency_Send. Is sstmac_isend (non-blocking) in sstmacro unimplemented?
2. And it is found in the test that the start time of the second transmission of MPI_Isend is the end time of the first message transmission.

Thanks to anyone who may shed some light into this. -sirui

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/sstsimulator/sst-macro/issues/656#issuecomment-982348510, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADSKZVUBGNQU5D5JFL33GWLUOR2Q7ANCNFSM5IXPGN4Q. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[sunsirui]

Very thank you for your answer!