[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[tlaplus] Re: 3 Random Questions



Hello, 

Regarding point 2 and in particular for the Raft spec.

The original spec is just hard to model check and get a sense of what is working there. Although you can manage something through some constraints (https://github.com/granular-storage/raft.tla/blob/master/raft.tla).

One exercise I designed for students is to add some instrumentation (eg, count messages being sent by leader and followers and check counts at successful commit entryCommitStats) on a simpler version of Raft that avoids leader election, timeouts. For this exercise, the spec simplifies (restricts) some actions a little bit so that we can obtain a trace faster. Check my example at:

https://github.com/granular-storage/raft.tla/blob/raftEntryCommits/raftSpec.tla

A fake invariant (LeaderCommitted) will show a trace from which students can learn what is going on.

For this exercise, MySpec uses MyInit (that starts with a leader) while a simplified MyNext action only allows AppendEntries messages to be processed (intentionally avoiding leader election in Raft).

AppendEntries (from https://github.com/granular-storage/raft.tla/blob/raftEntryCommits/raftActions.tla) was also modified to send exactly one entry. Without empty entries there are no hearbeats so we have to give more client requests into Values to have some progress.

To understand how Raft and its spec work, I find this way of isolating simple scenarios along with some fake invariants useful.

Let me know your thoughts.

Regards,
Ovidiu Marcu

On Wednesday, April 5, 2017 at 3:39:40 AM UTC+2 Leslie Lamport wrote:

1. I can't help you on that.


2.  The diameter isn't a particular important measure.  What you want
to do is limit the size of the state space.  To learn the mechanisms
for doing that, see the Model Checking section of the Help.  Of
special interest is the State Constraint section of Creating a Model >
Advanced Option Page.  The mistake beginners usually make is not to
start by checking very small models (ones with few enough states to
terminate quickly).


The most effective way to limit the number of states is to write a
better spec.  The art of specification is to find the simplest, most
abstract spec that captures the essence of your algorithm.  For an
example, you might want to look at my specification of Paxos that I
believe is in the examples on git.
 


When you've got the simplest abstraction that accurately describes the
algorithm, model checking reasonable sized models may still take a lot
of time.  One thing you can then do is to check a simpler, less
accurate model whose executions take fewer steps--that is, a spec with
larger atomic actions that describe multiple separate actions of the
original spec.  Any error in the simple spec reveals an error in the
original spec.  When you're convinced that the system with large steps
is correct, you can then start looking for errors in the more accurate
spec.


3.  There's no such thing as "normal".  Your experience with diameter
11 or 12 holds only for your particular example.  TLC slows down
dramatically when the set of states it's found so far no longer fits
in memory and has to be stored on disk.  The solution to this problem
is to find a machine with the largest memory you can.  Multiple cores
help too; TLC does multiprocessing on a single machine very
effectively for checking safety.  After running smaller models,
engineers will often run TLC for a couple of weeks on a very large
machine.


Leslie



On Tuesday, April 4, 2017 at 6:07:02 PM UTC-7, Eric Lee wrote:
I've been working with the TLA+ Toolbox for about a month, and I have a couple questions that I cannot find the answers to from browsing the old posts in this group or consulting the various manuals online. Please let me know if this is not the appropriate place to do this.

1. I use the TLA+ Toolbox on Ubuntu 16.04.2, and there is some weird visual artifacts that occur when I quickly scroll in the TLA module editor. If I scroll too fast, the editor seems to lag behind and repeat itself until I stop scrolling. I'm not sure how big of an issue this would be considered, but it would be nice to know if there is a fix for it.

2. I am currently working with the Raft TLA spec, and I was wondering if there is any way I can view the states that are being explored. I've seen something about Print or PrintT in the toolbox, but I was wondering what the best way to examine this is. Also, is there a way to limit the diameter of the state space exploration? I've managed to do this by adding variables myself into the spec, but does the toolbox have something built in?

3. Lastly, what kind of runtimes are normal for testing specifications? In my experience, after reaching diameter 11 or 12, progress slows to a halt. I read that the state exploration grows exponentially with the diameter, and I should test my spec for "as long as my patience would last". Does anyone have any tips for a better workflow? This is probably a dumb question.

--
You received this message because you are subscribed to the Google Groups "tlaplus" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tlaplus+unsubscribe@xxxxxxxxxxxxxxxx.
To view this discussion visit https://groups.google.com/d/msgid/tlaplus/1edca4fb-ce47-4803-a9a3-12c986872f58n%40googlegroups.com.