Overhaul of delay node handling in the mapper.
So, we have two basic issues. The first is the mixed 1Gb/10Gb problem I
mentioned yesterday, where without the ethernet-speed types, we might mix
1/10 in lan, with no ability to step down the 10g to 1g since that appears
to be uncommon for 10g interfaces. This problem is partly solved by turning
on the ethernet-speed stuff for all sites not just the
The second problem sorta encompasses the first problem; not being able to set interfaces to lower speeds. Not just 10G, but I guess some 1G interfaces are doing this? And this is important for deciding if we need a delay node. If we have nodes that do both 1G and 10G and the user wants 1G, we do not insert a delay node, cause we assume that we can just step the 10G down (if one of the those is choosen).
But since the decision to insert a delay node happens before assign runs, we have always had this hacky check, since if we didn’t do it, we would end up inserting delay nodes a lot more often, which consumes more real nodes, which is bad (and even worse back in the early days when we didn’t have many nodes).
Aside; if our delay nodes could delay vlan encapsulated links, we would not be so restricted; a 10G delay node could handle lots of pipes. As it is, we have to use end node shaping
In addition, @ricci says: And we would have an explicit difference between exactly this bandwdith and 'at least this bandwidth'
@hibler from day one we have "best effort" specifications for bandwidth and avoid the whole low-bandwidth-spec-plus-noshaping-hack. Then I never would have noticed this problem yesterday :simple_smile:
@hibler: For actual link shaping, we default to end-node shaping. We assume shaping for any speed that is not the native (primary) speed. Maybe post-assign we figure out, based on the chosen nodes, whether we can dial-down the bandwidth in hardware and thus remove link shaping.
@hibler: If you want a delay node, you have to place them in the topology explicitly. We figure out in assign if delay nodes can be multiplexed on physical nodes based on available link bandwidth and not number of interfaces. This is of course a non-backward-compatible change and completely antithetical to our original "no artifacts" position.