I just built 0.9.6 on my FC5 box with no problems. Stability is much better since 0.9.4 and I am enjoying the software greatly.
My only real problem is that over time the performance gets very chunky and I have to kill the process and bring it back. I have the node timeout set to 5000ms and the refresh rate to 50ms (does not go any lower). It starts ouy great but after about 15 minutes the screen only refreshes itself every 1-2 seconds.
Anyone know any tricks here? Is it a memory issue? My laptop only has 384mb of ram but it should be sufficient for something like this since etherape is the only thing this laptop does.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
50 ms is very low, too low, unless you have a very fast pc.
For example, on my ancient 128MB Pentium II, I have 800ms.
Personally I see refresh rates under 500ms useful only for "eye candy", since what really matters is the averaging period.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Do you think it is my processor speed then that is at issue? Why does it seem to run so well and slowly degrade?
Eye candy is a factor I suppose. My boss wants me to set up multiple instances of etherape on some flatscreens so he can get that real "on the bridge" star trek feel. That is fair enough. I am not complaining. Etherape has helped me solves some bottlenecks already (and it does look cool!).
I will tinker with the refresh. Mostly I am just trying to understand *why* I get a change in performance over time and what will ultimately solve the problem (memory, processor, etc).
Thanks!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Every node, link and protocol, has a list of packets seen (not the complete packet, only addresses, names and payload size).
When the traffic timeout expires, the packet is removed from the list of the relevant node/link.
When the "protocol info" timeout expires the packet is removed from the node/link protocol list (the one you get by double-clicking on a node/link).
Diagram timeout control node/link display only.
At diagram refresh time etherape does many display related time-consuming tasks, so lowering "diagram refresh" will use more cpu (much more if you have many nodes).
If you want to limit those lists and speed up etherape you need to lower the traffic and protocol info timeouts (the averaging time is a lower bound here, so eventually you will lower this also).
My advice is to lower diagram refresh time only after tuning other timeouts.
Even then, half a second (500ms) should be really enough to "keep an eye" on traffic behaviour.
As I said, I use 800 ms and find this setting rather effective.
If your pc and/or videocard is still slow, you could disable node anti-aliasing.
You could also use the capture filter to restrict the traffic processed by etherape, but then you will risk missing some hotspots.
Note that internally etherape could be much more efficent, esp. handling captured packets. For example, it decodes names on the fly, instead of waiting for display time.
Name resolution is asynch, but still etherape does unnedeed resolutions.
Changing this behaviour is complex and related to a client/server evolution, though, so unlikely to happen soon.
BTW, I like to hear how people use etherape, this feedback is useful to better shape future releases.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK tinkering with timeouts seems to be having the desired affect. By timing out the nodes more quickly it keeps better performance.
I suppose my major problem now is that things are moving around on my screen very fast now! This because the nodes are timing out more quickly. This is not as complaint at all - but maybe a feature request:
I think it would be very cool of the nodes slid around the interface rather than jumping around in order to maintain the best position. Now I don't know squat about programming but it sounds like this would not be an easy thing to do, but in many ways it would increase the value of etherape greatly. I find my eyes having to trace around to find nodes when activity gets fairly hectic. When I filter things down it actually increases the jumping affect because the distance between fewer nodes in the interface is greater.
It's almost impossible to double click on things at that speed when they jump, so I end up having to get very good at pausing the diagram.
Just a thought!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To slow down node movement you can increase the diagram refresh time ;-)
You can also try the "stationary" command line option (-s), wich should disable node movement.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
FYI - I use Etherape to watch my windows PC making Torrent Connections ........ 100's literally, but as stated after a few min. the interface quites responding .......
Dell Latitude PII 400, 256Mb Ram, - Auditor Install probably a yr old build ...... from a live cd
really nice to watch all the connections .......
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Etherape essentially maintains a list of all connections seen (it's more complicated than this, but is still an useful simplification). Even after a connection is no longer visible, is still on the list for some time, to maintain the traffic statistics.
If you create new connections faster than the list expiration time, the list grows ... and grows, and grows until etherape is paralyzed.
A less powerful pc (say, a 400MHz PII ;-) ) coupled with many short-lived connections (like p2p) exacerbates this phenomenon.
To avoid this problem, you must adapt the link/node/statistics timeouts to your environment.
Note that I'm not ruling out problems on Etherape itself, but IMO your symptoms suggest a different parametrization.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just built 0.9.6 on my FC5 box with no problems. Stability is much better since 0.9.4 and I am enjoying the software greatly.
My only real problem is that over time the performance gets very chunky and I have to kill the process and bring it back. I have the node timeout set to 5000ms and the refresh rate to 50ms (does not go any lower). It starts ouy great but after about 15 minutes the screen only refreshes itself every 1-2 seconds.
Anyone know any tricks here? Is it a memory issue? My laptop only has 384mb of ram but it should be sufficient for something like this since etherape is the only thing this laptop does.
50 ms is very low, too low, unless you have a very fast pc.
For example, on my ancient 128MB Pentium II, I have 800ms.
Personally I see refresh rates under 500ms useful only for "eye candy", since what really matters is the averaging period.
Do you think it is my processor speed then that is at issue? Why does it seem to run so well and slowly degrade?
Eye candy is a factor I suppose. My boss wants me to set up multiple instances of etherape on some flatscreens so he can get that real "on the bridge" star trek feel. That is fair enough. I am not complaining. Etherape has helped me solves some bottlenecks already (and it does look cool!).
I will tinker with the refresh. Mostly I am just trying to understand *why* I get a change in performance over time and what will ultimately solve the problem (memory, processor, etc).
Thanks!
Every node, link and protocol, has a list of packets seen (not the complete packet, only addresses, names and payload size).
When the traffic timeout expires, the packet is removed from the list of the relevant node/link.
When the "protocol info" timeout expires the packet is removed from the node/link protocol list (the one you get by double-clicking on a node/link).
Diagram timeout control node/link display only.
At diagram refresh time etherape does many display related time-consuming tasks, so lowering "diagram refresh" will use more cpu (much more if you have many nodes).
If you want to limit those lists and speed up etherape you need to lower the traffic and protocol info timeouts (the averaging time is a lower bound here, so eventually you will lower this also).
My advice is to lower diagram refresh time only after tuning other timeouts.
Even then, half a second (500ms) should be really enough to "keep an eye" on traffic behaviour.
As I said, I use 800 ms and find this setting rather effective.
If your pc and/or videocard is still slow, you could disable node anti-aliasing.
You could also use the capture filter to restrict the traffic processed by etherape, but then you will risk missing some hotspots.
Note that internally etherape could be much more efficent, esp. handling captured packets. For example, it decodes names on the fly, instead of waiting for display time.
Name resolution is asynch, but still etherape does unnedeed resolutions.
Changing this behaviour is complex and related to a client/server evolution, though, so unlikely to happen soon.
BTW, I like to hear how people use etherape, this feedback is useful to better shape future releases.
OK tinkering with timeouts seems to be having the desired affect. By timing out the nodes more quickly it keeps better performance.
I suppose my major problem now is that things are moving around on my screen very fast now! This because the nodes are timing out more quickly. This is not as complaint at all - but maybe a feature request:
I think it would be very cool of the nodes slid around the interface rather than jumping around in order to maintain the best position. Now I don't know squat about programming but it sounds like this would not be an easy thing to do, but in many ways it would increase the value of etherape greatly. I find my eyes having to trace around to find nodes when activity gets fairly hectic. When I filter things down it actually increases the jumping affect because the distance between fewer nodes in the interface is greater.
It's almost impossible to double click on things at that speed when they jump, so I end up having to get very good at pausing the diagram.
Just a thought!
To slow down node movement you can increase the diagram refresh time ;-)
You can also try the "stationary" command line option (-s), wich should disable node movement.
FYI - I use Etherape to watch my windows PC making Torrent Connections ........ 100's literally, but as stated after a few min. the interface quites responding .......
Dell Latitude PII 400, 256Mb Ram, - Auditor Install probably a yr old build ...... from a live cd
really nice to watch all the connections .......
Etherape essentially maintains a list of all connections seen (it's more complicated than this, but is still an useful simplification). Even after a connection is no longer visible, is still on the list for some time, to maintain the traffic statistics.
If you create new connections faster than the list expiration time, the list grows ... and grows, and grows until etherape is paralyzed.
A less powerful pc (say, a 400MHz PII ;-) ) coupled with many short-lived connections (like p2p) exacerbates this phenomenon.
To avoid this problem, you must adapt the link/node/statistics timeouts to your environment.
Note that I'm not ruling out problems on Etherape itself, but IMO your symptoms suggest a different parametrization.