[Simgrid-user] Ordering of flows

Arnaud Legrand arnaud.legrand at imag.fr
Wed Jul 2 09:52:45 CEST 2008


Hi,

Kurt Vanmechelen wrote:

> First of all thanks for the prompt feedback on GTNetS and the action delays.
> We will keep the model in which we call back to SURF on each reported delay.
> I will retry the GTNetS compilation this week and let you know if everything 
> works fine.

OK. Keep us posted.

> I have a new question though. As our tests show, there is no flow "ordering" 
> in SURF. Suppose we have two hosts A and B,  and A starts two communication 
> flows X and Y to B. Flow X is started at time U and flow Y at time V with U < 
> V. Now it appears that Y can finish before X, i.e. there is no (packet/flow) 
> ordering to ensure that X finishes before Y. 

Well in the setting you describe, flow Y can finish before X only if it 
conveys less data than X. If you send 10 Gb in X and 1Kb in Y, Y may 
obviously finish earlier (depending on U and V). Otherwise, if X and Y 
convey the same amount of data and both are from A to B, X has to finish 
earlier than Y. I would be very surprised if you experimented otherwise. 
But if you did, it is a huge bug and I would be happy to look at it.

> If I am not mistaken the TCP protocol prevents such reorderings from happening 
> by using sequence numbers. I also know that SURF is not supposed to do packet 
> level simulation. 
> 
> I was wondering however whether you came across this issue before and how you 
> deal with this in message-based programs (i.e. programs that used your MPI 
> layer for example). In such programs it is important for this ordering to be 
> correct in order to assure a semantically sound execution of an RPC based 
> program.

You are directly on top of SURF. So any action entered in SURF starts as 
soon as it is created: all flows run in parallel. If you want to express 
some sequential dependencies between these flows (actually it comes from 
the dependency between your messages), then you have to queue them and 
delay their creation. This is how MSG, GRAS and SMPI work. Each process 
has a queue of pending communication and the corresponding action is 
created when needed (e.g. the sender and the receiver are ready). Thus 
many flows can run in parallel but we respect the message orders for 
each process... I hope this is more clear now.

Cheers,

     Arnaud





More information about the Simgrid-user mailing list