Open justfalter opened 11 years ago
Any place we can get a performance gain without sacrificing functionality is an absolute win.
In reading your explanation, my question is would this impact a scenario where the user has set it to automatically ARP poison new hosts that appear on the wire. I believe this is a plugin or switch, but not 100% sure about how it determines new hosts added, etc.
I do like the idea of enable/disable on the fly. Honestly, I have already done my recon, etc and have a clear set of hosts I want to target before I even start poisoning.
On Sun, Apr 28, 2013 at 10:49 PM, Mike Ryan notifications@github.comwrote:
While profiling ettercap with valgrind, I noticed that ec_conntrack and ec_profile constitute a significant portion of Ettercap's process time. By manually disabling the both of these, I was able to reduce the number of function calls in my tests from ~42 million down to ~15 million. I don't know the exact impact w.r.t performance, but I can see how eliminating 65% of the function calls might be beneficial.
AFAICT, the two are probably most useful in those cases when you are performing recon, and need to know what hosts and connections are flying by on the network. However, if you have already moved beyond recon and simply want to manipulate traffic, there's no need to incur the performance impact of ec_conntrack and ec_profile.
I propose adding the ability to enable/disable conntrack and profiling from the CLI. Further, I don't see why we shouldn't be able to enable/disable it dynamically once the process is running.
thoughts?
— Reply to this email directly or view it on GitHubhttps://github.com/Ettercap/ettercap/issues/213 .
Hrm, I believe that is doable. We just have to make sure that the GUIs don't pull any profile data, I know some dissectors (like DNS) also add data to the hosts list profiles.
FWIW, here are some stats:
Before:
Bottom Half packet rate : worst: 50150 adv: 176913 p/s
Top Half packet rate : worst: 200803 adv: 854569 p/s
Bottom Half thruoutput : worst: 12603833 adv: 123106767 b/s
Top Half thruoutput : worst: 2350000 adv: 545060043 b/s
After:
Bottom Half packet rate : worst: 112866 adv: 205604 p/s
Top Half packet rate : worst: 1136363 adv: 3130154 p/s
Bottom Half thruoutput : worst: 17053061 adv: 143071672 b/s
Top Half thruoutput : worst: 19583332 adv: 1996469398 b/s
Ratio of (After / Before):
Bottom Half packet rate : worst: 2.25x adv: 1.16x p/s
Top Half packet rate : worst: 5.65x adv: 3.66x p/s
Bottom Half thruoutput : worst: 1.35x adv: 1.16x b/s
Top Half thruoutput : worst: 8.33x adv: 3.66x b/s
so @justfalter do you have any pull for this?
While profiling ettercap with valgrind, I noticed that ec_conntrack and ec_profile constitute a significant portion of Ettercap's process time. By manually disabling the both of these, I was able to reduce the number of function calls in my tests from ~42 million down to ~15 million. I don't know the exact impact w.r.t performance, but I can see how eliminating 65% of the function calls might be beneficial.
AFAICT, the two are probably most useful in those cases when you are performing recon, and need to know what hosts and connections are flying by on the network. However, if you have already moved beyond recon and simply want to manipulate traffic, there's no need to incur the performance impact of ec_conntrack and ec_profile.
I propose adding the ability to enable/disable conntrack and profiling from the CLI. Further, I don't see why we shouldn't be able to enable/disable it dynamically once the process is running.
thoughts?