You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi,
I tried to used Flow-level ECMP in fat-tree topology, but I found the total throughput of the receiver was not as much as the maximum. I think you use the original source codes about flow-level ECMP of ns-3, and I ran the same topology using TCP in ns-3 and visualized it. Surprisingly, only some core switches were used, so I thought that flow-level ECMP might not work properly and it is the main cause for low throughput. Have you ever noticed this? or I used it wrongly?
thanks.
The text was updated successfully, but these errors were encountered:
I have got it.
Flow-level ecmp is based on five-tuple, so the flows that have the same hash value will have the same next hop, denoted as SW_A. If SW_A still has more than one next hops, for example, SW_B and SW_C, these flows that have the same hash value will choose the same next hop, SW_B or SW_C.
I have fixed it by dividing tuple value into the switch id. tupleValue /= (m_ipv4->GetObject<Node>()->GetId() + 1);
Hi,
I tried to used Flow-level ECMP in fat-tree topology, but I found the total throughput of the receiver was not as much as the maximum. I think you use the original source codes about flow-level ECMP of ns-3, and I ran the same topology using TCP in ns-3 and visualized it. Surprisingly, only some core switches were used, so I thought that flow-level ECMP might not work properly and it is the main cause for low throughput. Have you ever noticed this? or I used it wrongly?
thanks.
The text was updated successfully, but these errors were encountered: