Instrumenting bitstream ? : Instrumented
by Orion Elenzil · in Torque Game Engine · 04/03/2007 (9:26 am) · 9 replies
Hey all -
what do you think of the notion of putting some
instrumenting around the packUpdate() stuff.
something which could be used like:
and that would yield some debugs in the console along the lines of:
hopefully actually counting the bits could be done in fairly few places.
potentially just in BitStream::writeBits() ?
i wonder if something like this has already been done.
i haven't used DEBUG_NET,
but it looks like not this.
ooo
PS clint just suggesting wrapping it up in a class instance which automatically gets deleted when it goes out of scope, so you don't have to worry about balancing the PUSH and POPs.
what do you think of the notion of putting some
instrumenting around the packUpdate() stuff.
something which could be used like:
ShapeBase::packUpdate()
{
PUSH_BITSTREAM_SECTION("shapeBase");
...
if (writeFlag(MyNetMask))
{
PUSH_BITSTREAM_SECTION("MyNetMask blah blah");
...
POP_BITSTREAM_SECTION(); // MyNetMask
}
...
POP_BITSTREAM_SECTION(); // shapeBase
}
Player::packUpdate()
{
PUSH_BITSTREAM_SECTION("player");
Parent::packUpdate()
...
POP_BITSTREAM_SECTION(); // player
}and that would yield some debugs in the console along the lines of:
player - 123 bits shapeBase - 91 bits MyNetMask blah blah - 13 bits
hopefully actually counting the bits could be done in fairly few places.
potentially just in BitStream::writeBits() ?
i wonder if something like this has already been done.
i haven't used DEBUG_NET,
but it looks like not this.
ooo
PS clint just suggesting wrapping it up in a class instance which automatically gets deleted when it goes out of scope, so you don't have to worry about balancing the PUSH and POPs.
About the author
#2
04/03/2007 (6:00 pm)
Thats unsurpassedly awesome man. I'm very interested in this, as network traffic is a very large interest of mine. Can't wait to see the resource. Thanks!
#3
The other thing I found is that it gets REALLY ANNOYING once you have a few things using it. I limited it to debug build only, and only added it to a handfull of objects. Any more then that and the console would have been useless ;) What would be significantly better is a way to turn it on/off at will. Even better turn it on/off for various objects and anything they depend on at run time, preferably in a debug build.
I guess that quite a lot depends on what the info is used for. I was using it for packet optimization for RPC functions, so I could control when things were happening to get the most out of the data and things remained relatively readable despite being kinda irritating when I didnt need the info anymore.
However, for GameBase derived object updates, it will probably need a different method of visualizing the data. Just dumping it to the console in the way you suggest in the first post is not going to be particularly useful since you will generate a solar system sized amount of data extremely quickly and the console will be rendered useless. Perhaps something along the lines of how the profiler dumps data would be better in that case.
T.
04/04/2007 (5:54 am)
I implemented something similar a while back, but it was only for the pack/unpack ... no stack. I found it really useful for tracking down a few network issues that would have been tricky otherwise.The other thing I found is that it gets REALLY ANNOYING once you have a few things using it. I limited it to debug build only, and only added it to a handfull of objects. Any more then that and the console would have been useless ;) What would be significantly better is a way to turn it on/off at will. Even better turn it on/off for various objects and anything they depend on at run time, preferably in a debug build.
I guess that quite a lot depends on what the info is used for. I was using it for packet optimization for RPC functions, so I could control when things were happening to get the most out of the data and things remained relatively readable despite being kinda irritating when I didnt need the info anymore.
However, for GameBase derived object updates, it will probably need a different method of visualizing the data. Just dumping it to the console in the way you suggest in the first post is not going to be particularly useful since you will generate a solar system sized amount of data extremely quickly and the console will be rendered useless. Perhaps something along the lines of how the profiler dumps data would be better in that case.
T.
#4
yes, what i've implemented is filtered first by a #define which removes it entirely from the code if not used,
and second by a setting a runtime console variable. our thought for using it is that we'll have some other instrumentation on the amount of data going over the wire which is silent until the amount passes some threshhold, then it gives a low-frequency alarm, and then we turn on this guy to pick apart the problem. this definitely isn't something you would want to be on all the time.
being able to turn it on and off per-object at runtime would be cool.
04/04/2007 (9:51 am)
Hey Tom -yes, what i've implemented is filtered first by a #define which removes it entirely from the code if not used,
and second by a setting a runtime console variable. our thought for using it is that we'll have some other instrumentation on the amount of data going over the wire which is silent until the amount passes some threshhold, then it gives a low-frequency alarm, and then we turn on this guy to pick apart the problem. this definitely isn't something you would want to be on all the time.
being able to turn it on and off per-object at runtime would be cool.
#5
The threshold thing sounds like a good idea too. That gives you the data when you want it without having to realize that things are hosed and restarting the build to get the data.
I would suggest looking at the profiler code. It seems to me that it would be simpler to just make it support this as an alternate mode or subclass/separate instance or something rather then re-implementing it all.
T.
04/04/2007 (9:58 am)
Hmm, the more I think about this the more I think it should be like the profiler. For example, you turn it on, it gathers a bunch of data, then you turn it off and can analyze the data. Visualization of the data is again similar to the profiler, it's just number of bits instead of CPU time.The threshold thing sounds like a good idea too. That gives you the data when you want it without having to realize that things are hosed and restarting the build to get the data.
I would suggest looking at the profiler code. It seems to me that it would be simpler to just make it support this as an alternate mode or subclass/separate instance or something rather then re-implementing it all.
T.
#7
I don't say this often...but I am really glad you are using our stuff.
It's really easy for me to put improvements that I make into our latest code, but not as much for our community. Thank you for taking the time to give code/suggestions/resources back.
04/04/2007 (2:07 pm)
Orion,I don't say this often...but I am really glad you are using our stuff.
It's really easy for me to put improvements that I make into our latest code, but not as much for our community. Thank you for taking the time to give code/suggestions/resources back.
#8
My pleasure, Pat.
It's a great engine and i think the technology flow between GG and the community is part of that.
04/04/2007 (2:40 pm)
!My pleasure, Pat.
It's a great engine and i think the technology flow between GG and the community is part of that.
#9
04/05/2007 (5:50 pm)
HUGE Thanks Orion!! This is very useful :) 
Associate Orion Elenzil
Real Life Plus
v. interesting.
i plan to make it a resource, hopefully this week,
but if anyone is particularly interested, let me know and i'll hustle it a bit.