-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Simulating USCarrier.nv may not converge #68
Comments
Uncommenting lines 129-131 and then running
|
I didn't work on this example -- is it possible it just doesn't converge? Even if stable solutions exist, I don't think the simulator is guaranteed to find one. BGP length increasing is suspicious as well. |
I believe the NV file was generated using NetComplete configs per @nickgian. Unlike the fattree benchmarks, its |
Add benchmarks for maintenance in fatXPol networks, and allow them to be benchmarked by kiribench.py. Add code to generate hMETIS-cut networks with gen_part_nv, although our current examples for USCarrier.nv don't appear to be useful since its simulation diverges (see issue #68). Do some minor reformatting in Simulator.ml and Srp.ml
I am sorry about that, weird that this problem went under the radar for so long. Perhaps we were trying a different prefix. You are right the problem appears to be the local-pref. This converges normally. The question that may concern you the most is whether the SMT solver is finding the right solution. By verifying you mean you get unsat? In this case unsat might mean that there is no solution that converges. I'd be impressed if there is a stable state and the simulator just cannot find it because of the order it follows (do we know of any such examples?) |
Yeah, my guess is that there is no solution so SMT just returns unsat anyway. |
Sure, get rid of it, and maybe drop in the replacement I posted here? |
I've been trying to get results from simulating
benchmarks/SinglePrefix/TopologyZoo/USCarrier.nv
, but while I can verify it in SMT in about a minute, simulation appears to hang.Uncommenting the print statement at
Srp.ml#L141
(which shows the currently-processed node in simulating state) leads to a very, very long sequence of nodes being output.I can't confirm that this sequence repeats yet, but it does look fishy in comparison to other benchmarks where this process typically finishes very quickly. Does anyone know what's going on with this benchmark?
The text was updated successfully, but these errors were encountered: