ACassimiro / TSNsched

Automated Schedule Generation for Time-Sensitive Networks (TSN).
GNU General Public License v3.0
82 stars 37 forks source link

about cycle start time #8

Closed spzhan closed 3 years ago

spzhan commented 3 years ago

Hello, I used this tool to run a simple test case, and I have a question: the result shows that the cycle start time of the switches are different, which brings inconvenience to the manual verification results later. Can we fix the cycle start time of all switches to be the same? For example, both are 0.

thank you!

INFORMATION OF SWITCH: switch0 <<<< Port list - => Port name: switch0Port1 Connects to: switch2 Cycle start: 0.0 Cycle duration: 1000.0 Fragments: flow1Fragment1, Slots per prt: 1 Priority number: 5 Index 0 Slot start: 0.5 Index 0 Slot duration: 52.5

INFORMATION OF SWITCH: switch2 <<<< Port list - => Port name: switch2Port2 Connects to: switch3 Cycle start: 1.0 Cycle duration: 1000.0 Fragments: flow1Fragment2, flow2Fragment2, flow3Fragment2, Slots per prt: 1 Priority number: 5 Index 0 Slot start: 0.5 Index 0 Slot duration: 52.5

INFORMATION OF SWITCH: switch3 <<<< Port list - => Port name: switch3Port9 Connects to: dev15 Cycle start: 28.0 Cycle duration: 1000.0 Fragments: flow1Fragment3, flow2Fragment3, flow3Fragment3, flow4Fragment2, Slots per prt: 1 Priority number: 5 Index 0 Slot start: 0.5 Index 0 Slot duration: 52.5

INFORMATION OF SWITCH: switch4 <<<< Port list - => Port name: switch4Port2 Connects to: switch2 Cycle start: 0.0 Cycle duration: 1000.0 Fragments: flow2Fragment1, flow3Fragment1, Slots per prt: 1 Priority number: 5 Index 0 Slot start: 0.5 Index 0 Slot duration: 52.5

INFORMATION OF SWITCH: switch5 <<<< Port list - => Port name: switch5Port3 Connects to: switch3 Cycle start: 14.0 Cycle duration: 1000.0 Fragments: flow4Fragment1, Slots per prt: 1 Priority number: 5 Index 0 Slot start: 0.5 Index 0 Slot duration: 52.5

ACassimiro commented 3 years ago

Hello,

Yes, it is possible, but I don't think that currently there is a way of doing so in the parameters of the input file. You would need to change the code of TSNsched, but it would be really easy as you would only need to remove a few comments on the TSNSwitch class:

  1. Comment on line 201, so that every cycle in every port of that switch has the same starting point.

  2. (Optional) Comment on line 193, so that every cycle in every port of that switch has the same duration.

  3. Comment on line 210, so that all the cycles start at a desired moment in time, which you give as a parameter to the ctx.mkInt() method. As it is, its value is 0. This will only work if you do the step 1.

I believe you will have the schedules that you need once you uncomment these comment blocks, but be mindful that you are creating more restrictions to the solver, hence, depending on how you configure your network, it might take more time to solve. Also, after performing these changes you can generate a new .jar file of the project, so you can use it on command line.

I hope this helps, and feel free to add a comment/contact me/open more issues if you need.

spzhan commented 3 years ago

Hello, I removed the comments on line 201 and lines 210~213 according to your suggestion, but it looks doesn't work, and the result is the same as before. Can you help me check again? solver.add(ctx.mkEq( // Equal cycle constraints this.cycleStart, port.getCycle().getFirstCycleStartZ3() )); /**/

}

solver.add(ctx.mkEq( this.cycleStart, ctx.mkInt(0) ));

one more question:) dt is defined as the packet departure time from the previous node, More precisely, it is the first bit leave time or the last bit leave time? Same as dt, at(arrival time) is the first bit arrival time or the last bit arrival time?

Thank you!

piuMoreira commented 3 years ago

Hello, To make the cycle start time of every switch have the same start (as 0 for example), yours lines 201~214 in the TSNSwitch class should look like this:

// The cycle of every port must have the same starting point solver.add(ctx.mkEq( // Equal cycle constraints this.cycleStart, port.getCycle().getFirstCycleStartZ3() )); } solver.add(ctx.mkEq( this.cycleStart, ctx.mkInt(0) ));

Currently, that's the default configuration in the TSNSwitch class.

And about the departure time, it is equal to the time where the last bit of the packet has left the node. Likewise, the arrival time is equal to the time where the last bit of the packet has arrived.

I hope this help.

ACassimiro commented 3 years ago

Hello @spzhan,

Sorry for the late reply. I was focused on managing other projects while fixing some bugs and adjusting improvements on TSNsched. Please update your project.

Considering the changes to enable the same cycle start, are you running TSNsched on a command prompt? If so, you will have to make the changes in the code and generate a new JAR file from the project. After this, you can remove the files in the libraries folder inside the script folder (except the z3 library) and put the new generated JAR file there (and finally run the script).

If you have exported this project to an IDE and you're running the TSNsched project instead of running the script (and consequently using TSNsched as a library), you would only need to change the pieces of code that I've referred before. This allows you to modify and configure TSNsched more quickly, as you don't have to generate JAR files for every change in the code that you wish to perform. Lastly, your input file becomes the "GeneratedCode.java" file on the project.

As for the departure time, @piuMoreira is correct.

Please let me know if my answer wasn't clear or if you're having any issues with the tool. I'm glad to help you with any questions about TSNsched.

spzhan commented 3 years ago

Thank you! @ACassimiro @piuMoreira

I took a long vacation last two weeks, sorry for the late reply. I will try it again as your suggestion :)