From: Hedayat V. <hed...@ai...> - 2008-08-01 20:42:54
|
Hi all, /*Joschka Boedecker <jos...@am...>*/ wrote on 07/31/2008 06:53:43 AM: > Hi Mahdi, > > ... > To be honest, I think we first should make sure this is really the > case. I mean, I suspect it, too, but we should do some profiling under > competition conditions (i.e. in a network setting with external > monitor and realistic agent binaries). > ... > We also should try to determine how well the server runs with the > multi-threaded timer and also using Hesham's ODE improvements which > weren't used in Suzhou (as far as I know). These two things have > potential to speed up the server considerably. > In past, I did some profiling (on my system with internal monitor) in which ODE was a bottleneck. But we had not tested ODE improvements and also we had no profiling under competitions conditions. Can anybody do the latter? Maybe we can ask the teams to do so! >> I had a brief discussion with carlos and hedayat, and we agreed that >> 40 ms won't do much harm to the simulations. How do you think of >> changing the simulator's cycle rate to 25? I only mean the >> simulators, not the monitor's frame rate. >> >> > > I can't really predict what the effects will be, but let's try ;-) > If I remember correctly, there was some discussions about having different time steps for control and sensors. What do you think about that? Small time step for control commands and a bigger one for sensors? Or even some of the sensors such as the visual sensor?! (while it won't affect ODE processing much!) Anyway, it seems that we should do something about network messages first! We might just compress the current messages using a compression algorithm (such as zip), or (as Carlos told me about) changing the format of the messages completely (serializing the current data objects as a binary stream (which might be compressed too)). Or there might be other solutions. What do you think about it? Have a nice time, Hedayat > Thanks a lot for the input! > > Best regards, > Joschka > > |