AW: [Verse-dev] Performance

Marcus Hoffmann Marcus.Hoffmann at igd.fraunhofer.de
Fri Jun 10 10:08:10 CEST 2005


I think you misunderstood my attempt of explanation... ;)
I didn’t mean that you are sending every verse command directly to the
network... that would not be very usable, I agree.
What I wanted to express is, that you have to different mechanisms for
sending and receiving. Callback_update gets the commands from the
network and routes it to the callback functions and the commands sent to
verse are handled by another function.
The result of this architecture for me using more then one thread for
sending and receiving the verse commands would be that I will try to
access one resource (the verse library) from (at least) two threads. In
worst case this will happen simultaneously what will cause verse or my
application to crash. 

Yesterday I started to write some kind of wrapper before verse, that
encapsulated all verse commands and the callback_update command a mutex
every time they are called. I did it just for very few commands and have
to test it but it seems to work that way. Probably not the most elegant
way and probably not the fastest but it will work for now and make verse
- if it's running as I suppose it to run - multithreaded accessible. 
The only thing I'm doing there is wrapping a mutex around the
verse_send... command and unlocking the mutex until the sending is done.
I don’t know how much time I can spend on this today but hopefully I
will finish this and test it a little bit...

So far

M



> -----Ursprüngliche Nachricht-----
> Von: verse-dev-bounces at projects.blender.org [mailto:verse-dev-
> bounces at projects.blender.org] Im Auftrag von Eskil Steenberg
> Gesendet: Donnerstag, 9. Juni 2005 22:13
> An: verse-dev at projects.blender.org
> Betreff: [Verse-dev] Performance
> 
> Hi
> 
> > As far as I understood the callback_update function is the
"downstream"
> > connection to verse, that gives me all my updates that are arriving
from
> > verse. Every send command is handled in a direct way and verse
directly
> > interprets and sends this command out, isn't it?
> 
> no its not. if you look at the function "v_noq_send_buf" (used to give
a
> command to the send queue) you will find v_con_network_listen(); in
it. So
> any send command can cause verse to listen (if only breafly). In the
same
> way if you look inside verse_callback_update you will find
> v_noq_send_queue being called (probably repeatadly) that will send
data.
> 
> this is not a bug its a feature:
> 
> If you for instance have this code:
> 
> verse_send_g_vertex_set_xyz_real32(...);
> 
> while(TRUE)
>     verse_callback_update(1);
> 
> verse will not send the data until it comes to
"verse_callback_update".
> the verse_send_g_vertex_set_xyz_real32 is just too small to send in
one
> packet so it gets stored untill ither enough data has been collected
to
> fill a packet or a user calls "verse_callback_update". if it did send
a
> vertex everytime you asked it to it would be bad if you had this code:
> 
> printf("A\n");
> for(i = 0; i < 100000; i++)
>     verse_send_g_vertex_set_xyz_real32(...);
> printf("B\n");
> while(TRUE)
>     verse_callback_update(1);
> 
> because now you would send out lots of packets with only one command
in
> each rather the fewer with many comands in each thus saving packet
> overhead. We would also run in to other problems with this code,
during
> the vertex loop the application would have to run acording to how fast
you
> network connetion is, so A and B may come far apart. So if you wanted
to
> do this in a interactive app, you would need to break up your loop in
> order for you to insert some UI code and stuff in order not to freeze
your
> app.
> 
> Instead during this loop verse sends as much as it can but buffers the
> rest and sends it out during the verse_callback_update loop. Also
during
> the verse_send_g_vertex_set_xyz_real32 loop verse will listen for
> incomming stuff, mainly poitive or negative agnolagements (ACK/NAK)
that
> the stuff beeing sent actiualy gets there. thees messages are used to
> clear history buffers and to determain how fast you can send data. if
> thees NAKs/ACKs arnt reseved the nerwork trafic james and runs slower
and
> slower. So obviusly it is important for this to run especialy in a
loop
> where you send lots of data.
> 
> An other feature is that if you have more then one session you only
need
> to update one of them to keep the others alive. as long as you call
> verse_callback_update for one of them the others wont time out.
Everything
> sent to the other sessions will be stored in verse, so it would make
sence
> to empty them now and then, but theroreticaly untill the run out of
memory
> from buffering in comming stuff they will be just fine even if you
never
> call verse_callback_update to keep them alive.
> 
> E
> 
> _______________________________________________
> Verse-dev mailing list
> Verse-dev at projects.blender.org
> http://projects.blender.org/mailman/listinfo/verse-dev



More information about the Verse-dev mailing list