Thank you for the response. I believe I have resolved the issue. Just to give
an idea of what I am trying to do. I am trying to have a distribution of
traffic lights that communicate with each other over a network., with pairs of
lights providing access to what should be a single bidirectional lane. Upon the
presence of a vehicle on either end, each pair of lights negotiates the
priority of access based on a class of vehicle, heavy, light etc.
I was using an external library to simulate the networking medium and having
each node/tl have a separate thread as a message receive loop. Presumably
issues with the Python GIL, or just servicing the various other loops was
causing erroneous readings.
I was measuring time delays with the following code:
whiletraci.simulation.getMinExpectedNumber()>0:
sim_step_start=getMillis()
traci.simulationStep()
sim_step_end=getMillis()
foriintrafficLightList:
i.lightState.run()
i.setLightUpdate()
step+=1
state_process_end=getMillis()
print(Fore.GREEN+"##########################################################")
print(f"[[{getMillis():.1f}] ] total
sim:{(state_process_end-sim_step_start):.1f}")
print(f"[[{getMillis():.1f}] ] sumo sim:{(sim_step_end-sim_step_start):.1f}")
print(f"[[{getMillis():.1f}] ] state
sim:{(state_process_end-sim_step_end):.1f}"+Style.RESET_ALL)
presumably some other thread(s) were being processed between sim_step_start and
sim_step_end as well as simulationStep(). Having switched to using internal
python structures to simulate the medium the problem disappeared. However as a
note, I am using 1.19 and removing external control of TLS did make timing more
consistent. I still don't quite understand how the loop timings above could be
shorter than the configured delay, regardless of whatever extra processing
delay happens in the runner.py.
On 9 November 2023 at 09:12:41 -00:00, Mirko Barthauer
<[email protected]> wrote:
> Hi Thiago,
>
>
> I cannot reproduce the problem with my simple example scenario. Is the timing
> more or less consistent if you do not call traci.trafficlight.setPhase? Do
> you use the most recent SUMO release? If you can confirm both, it would be
> great to have a minimal example scenario to reproduce.
>
>
> Best regards
> Mirko
>
>
>
>
>
> -----Original-Nachricht-----
> Betreff: [sumo-user] Traci and sumo gui inconsistent simulation speed
> Datum: 2023-11-08T19:03:05+0100
> Von: "Tiago Furtado via sumo-user" <[email protected]>
> An: "[email protected]" <[email protected]>
>
>
>
>
>
>
>
>
>
> Hi Everyone,
>
>
>
> I am having an issue when using sumo-gui and a Traci with the simulation
> speed. Basically no matter what I set as the delay in the GUI I am getting a
> lot of cycle times that are both longer (acceptable for certain instantaneous
> steps where more processing is necessary), but I'm also getting cycle times
> that are much shorter than the delay. For example I'm measuring this in the
> runner.py , In the GUI I'm setting a delay of 200ms , and not only is the
> timing extremely inconsistent, it is not honoring the value I set. the value
> in sumo sim is measured in ms around "traci.simulationStep()".
>
>
> ##########################################################
> [[24559.2] ] total sim:58.1
> [[24559.2] ] sumo sim: 5.8
> [[24559.2] ] state sim: 52.3
> ##########################################################
> [[25248.3] ] total sim:231.8
> [[25248.4] ] sumo sim: 102.8
> [[25248.4] ] state sim: 129.0
> ##########################################################
> [[25569.6] ] total sim:53.1
> [[25569.6] ] sumo sim: 36.5
> [[25569.6] ] state sim: 16.6
> ##########################################################
> [[26019.1] ] total sim:2.6
> [[26019.1] ] sumo sim: 1.0
> [[26019.2] ] state sim: 1.6
> ##########################################################
> [[26695.4] ] total sim:160.3
> [[26695.5] ] sumo sim: 102.8
> [[26695.5] ] state sim: 57.5
> ##########################################################
> [[27190.4] ] total sim:134.8
> [[27190.4] ] sumo sim: 77.4
> [[27190.5] ] state sim: 57.4
> ##########################################################
> [[27949.4] ] total sim:377.8
> [[27949.4] ] sumo sim: 103.0
> [[27949.4] ] state sim: 274.8
> ##########################################################
> [[28124.0] ] total sim:22.7
> [[28124.0] ] sumo sim: 21.5
> [[28124.0] ] state sim: 1.2
> ##########################################################
> [[28770.6] ] total sim:159.8
> [[28770.6] ] sumo sim: 158.7
> [[28770.6] ] state sim: 1.1
> ##########################################################
>
>
>
> My script is subscribing to events from 13 different traffic lights and is
> controlling the phase of each of them via traci.trafficlight.setPhase(). Is
> there a way to make each step a more consistent time? Is it the number of
> lights I'm controlling? As far as I can tell the subscriptions aren't causing
> the variablility, but setPhase() seems to.
>
> I would appreciate any insight, or suggestions of things to try.
>
> Regards,
>
> Tiago Furtado
>
>
_______________________________________________
sumo-user mailing list
[email protected]
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/sumo-user
