Net Monitor

[whise]

displays net traffic
by Helder Fraga aka Whise


http://hendrik.kaju.pri.ee/screenlets/files/img/CapturaEcra-1_0.png

Instalation
Put it in your /usr/local/share/screenlets and run it from there
Download link:

Fixed memory leak

http://www.mediafire.com/?89jommvbgwt

[cbudden]

I have installed your screenlet, but it does not report any speeds, just 0 kb for up and down. My internet interface is wireless on eth1.

Chris

[plun]

Thanks...:)

Just works on a wired connection...

We need a new Widget layer.... Group No1 and 2...:p

[whise]

well i made it to work only on eth0 , can you type in the terminal cat /proc/net/dev and post the output here please , them ill make it work allways

[eneru]

Inter-| Receive | Transmit
face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed
lo: 24652 424 0 0 0 0 0 0 24652 424 0 0 0 0 0 0
eth0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
eth1:811938800 459646 108 108 0 0 0 0 2522316784 663350 0 0 0 0 2 0
irda0: 0 0 0 0 0 0 0 0 1416704 93556 0 0 0 0 0 0
here is mine :)

It would be good to either be able to set the interface as an argument of the screenlet, or have the possibility to right click the screenlet and change the interface (with a list of all interfaces available by example)

[whise]

ill make the device selectable , ill post it later today , with a new skin to

[whise]

updated.................

[cbudden]

Thanks for the quick update, here is a version packaged using screenlets-packager in 0.1.0
http://www.mediafire.com/?5w8m0tytdr4

[whise]

thanks , works ok now? ive not managed to update to 10 via repository , i think the site is beeing cluttered ...

[Krakatos]

I really like this applet, so first things first thanks a lot for developing it.
That said, I registered specifically to report a massive memory leak in this applet.

Running Ubuntu Feisty fawn with compiz fusion 0.52, screentlets 0.10 and the applet downloaded yesterday from the post #8 of this topic.

Everything works fine, but as time passes the python process of the applet grows larger and larger. For example now, from the System monitor, I did a memory map of the process. And the [heap] is 57.6 MB RAM
/usr/lib/libgtk-x11-2.0.so.0.1000.11 is 3.3 MB
everything else is under 1 MB.

yesterday, before I restarted, the heap of the process was around 230 MB.

I'm sorry to say that this is honestly a huge memory leak, and should be fixed asap.

Hope this was of some help.

[RYX]

Hi Krakatos!

Thanks for noting that problem. Can you try if this is the same for other screenlets as well?

I know there is also a leak when you switch themes, but it only gets a problem if you switch themes while you have a scale of 500% or more ...

[whise]

ive noticed that this only appends in screenlets with fast update time , like < 60 seconds

[RYX]

Maybe having one process for each screenlet type is the wrong approach. I think it would be better if they all fork off the daemon process instead. Would heavily reduce memory usage and increase startup times because forked processes use shared memory and the daemon would pre-import the screenlets module ...

I will do some testing before ...

:)

[whise]

but if you make it one process , wont a faulty screenlet crash or freeze all the screenlets ?

[RYX]

I _think_ if the screenlets would fork off the daemon process they become separate processes. They shouldn't affect each other after that (not really sure about that, still need to try it).

If it works, it could be added as an alternative startup method, the screenlets would still be able to run as stand-alone.

[eneru]

even if the processes are sons of the daemon one, it won't solve this problem, or will it ? I mean, the problem is not about their initial or standard memory usage but this usage after some time, and I doubt changing the threads' parents will solve it. I have never touched python (though i intend to someday ^^), but I thought it managed the memory by itself, right ? It's weird there is such a problem then, unless you keep allocating new objects without destroying ancient ones when doing some updates or something ? :s

[RYX]

Yes, that's kinda true ... The high memory usage due to having separate apps is another problem, different from this. I agree that there must be some missing deallocation. It could be the PangoContext. It is created on each draw, even though it could (and should) be created only once, in the constructor. This mistake of mine somehow got duplicated a lot before I found out that there is a better way. The NotesScreenlet shows the better approach, in case someone is interested ...

I noticed the same behavior with the CPUMeter, it increases its memory usage without any interaction, while the Clock seems to be staying at 17mb without any difference after an hour or two.

[eneru]

maybe it is in the library or one of the functions used to interact with the system then ? as this screenlet along with CPUmeter must use it a lot, while the clock shouldn't (a priori)

[RYX]

I just had a look at the code and saw that you used time.sleep(1) within the update function. That's not good and the screenlets should never use the sleep function (without a thread), it makes the UI hang. It would be better to use a second timeout that gets called each 500ms and calculates the traffic ...

I am also working on a Sensor-class which will give us much more flexibility for writing cool new Sensor-subclasses which can be reused by all screenlets. That should solve the sleep-issue.

:)

[whise]

yeah i should probably try a different approach on that , a sensor class would be good because tried to use the senser that is used in the original cpu meter and it kinda doesnt work properly, ill try to change it soon

[RYX]

I have the Sensor-class finished, here it is ... If you like you can add one for Net/Ram/... :D

NOTE: Looks like all '[' are messed up inside the highlighted code. You will have to replace them manually (or using find/replace in your editor).

# The screenlets.sensors module contains helper-functions to aid in
# creating CPU/RAM/*-meters
# (c) RYX (Rico Pfaus) 2007

import sys
import re
import gobject

# CLASSES

class Sensor (gobject.GObject):
"""A base class for deriving new Sensor-types from."""

# define custom signals
__gsignals__ = dict( \
sensor_updated = (gobject.SIGNAL_RUN_FIRST, gobject.TYPE_NONE, ()),
sensor_stopped = (gobject.SIGNAL_RUN_FIRST, gobject.TYPE_NONE, ()) )

def __init__ (self, interval=1000):
"""Create a new sensor which updates after the given interval."""
gobject.GObject.__init__(self)
self._timeout_id = None
self._interval = interval
# start sensor timeout
self.set_interval(interval)

# + public functions

def get_interval (self):
"""Get the update-interval time for this Sensor."""
return self._interval

def set_interval (self, ms):
"""Set the update-interval time for this Sensor and start it."""
if self._timeout_id:
gobject.source_remove(self._timeout_id)
if ms and ms > 10:
self._interval = ms
self._timeout_id = gobject.timeout_add(ms, self.__timeout)
return True
return False

def stop (self):
"""Immediately stop this sensor and emit the "sensor_stopped"-signal."""
self.set_interval(0)
self.emit('sensor_stopped')

# + handlers to be overridden in subclasses

def on_update (self):
"""Override this handler in subclasses to implement your calculations
and update the Sensor's attributes. Must return True to emit a signal
which can then be handled within the screenlets, returning False
causes the Sensor to be stoped.."""
return True

# + internals

def __timeout (self):
"""The timeout function. Does nothing but calling the on_update
handler and emitting a signal if the handler returned True."""
# call sensor's on_update-handler
if self.on_update():
self.emit('sensor_updated')
return True
# on_update returned False? Stop
self.stop()
return False


class CPUSensor (Sensor):
"""A very simple CPU-sensor."""

def __init__ (self, interval=1000):
"""Create a new CPUSensor which emits an 'sensor_updated'-signal after a
given interval (default is 1000ms)."""
Sensor.__init__(self, interval)
self._load = 0

# + public functions

def get_load (self):
"""Return the current CPU-load."""
return self._load

# + internals

def on_update (self, old_cuse=[0]):
"""Called on each interval. Calculates the CPU-load and updates the
internal load-value."""
try:
f = open("/proc/stat", "r")
tmp = f.readlines(200)
f.close()
except:
print "CPUSensor: Failed to open /proc/stat. Sensor stopped."
self.stop()
for line in tmp:
if line[0:4] == "cpu ":
reg = re.compile('[0-9]+')
load_values = reg.findall(line)
# extract values from /proc/stat
cuse = int(load_values[0])
csys = int(load_values[2])
load = cuse + csys - old_cuse[0]
if load < 0 : load=0
if load > 100 : load=100
self._load = load
old_cuse[0] = cuse + csys
# return True to emit the "update_event"-signal
return True
return False


# TEST:
if __name__ == '__main__':

# callback which gets notified about updates of sensor's value
def handle_sensor_updated (cpusensor):
print '%i%%' % cpusensor.get_load()

# create sensor and connect callback to it
cpu = CPUSensor()
cpu.connect('sensor_updated', handle_sensor_updated)

# start mainloop
mainloop = gobject.MainLoop()
mainloop.run()


This is one of those rare cases where OOP becomes very helpful and not only costs more time ... :)

[whise]

yeah i just found a easy way to do it without the sleep , gone update it soon

[Krakatos]

Sorry, I was away for one day.
I have 3 screenlets up: weather, netmonitor and finally system status.

I noticed that the ram used increases a little for each of them, but netmotnitor is definitely the one who goes overboard. Followed by system monitor. Weather seems the less greedy one. This night I woke up at 2, and netmonitor was like 300 MB ram. This morning, screenlets had crashed. In the config panel, the screenlets were still checked, had to disable/enable them again to see them. So there is a problem, though I am not sure at this point if it's even something a little related to the main program. And no, I left the standard skins everywhere.

I must admit that I know nothing of Python, but I did a memory map again and it's definitely the heap. I have no idea if it's possible to use a function of python to reduce the heap size. Maybe some sort of re-initialize?. Just spouting nonsense probably :)

If I can help in any way, I'm willing to. Just let me know what I'm supposed to do :)

[whise]

yeah , i know , im trying to fix it , i just dont know why it appends

[RYX]

I must admit that I know nothing of Python, but I did a memory map again and it's definitely the heap. I have no idea if it's possible to use a function of python to reduce the heap size. Maybe some sort of re-initialize?.
Usually, the python garbage-collector should automatically clean up all unused (dereferenced) variables after a while - at least all standard python types. A case where these issues could likely happen is the use of external libraries that allocate stuff on the heap and require to manually free that data later.

The horrible state of documentation for several libraries is always a problem if you try to find out the correct way of dereferencing/cleaning e.g. the RSVGHandles ...

But still I don't know why the Clock stays "cool" while the CPUMeter doubles its memory usage each couple of hours ... The clock uses the same font/svg/cairo rendering as the CPUMeter.

Maybe all updating screenlets (Clock, *Meters, ..) should use the Clock's double-buffering technique. I think this must have something to do with drawing contexts or images that are not properly cleared when they should, the Clock apparently handles that better ...

[Krakatos]

Usually, the python garbage-collector should automatically clean up all unused (dereferenced) variables after a while - at least all standard python types.

It works like java then, or at least it SHOULD work like java, since there is obviously a problem here....


The horrible state of documentation for several libraries is always a problem if you try to find out the correct way of dereferencing/cleaning e.g. the RSVGHandles ...

Maybe all updating screenlets (Clock, *Meters, ..) should use the Clock's double-buffering technique. I think this must have something to do with drawing contexts or images that are not properly cleared when they should, the Clock apparently handles that better ...

Well, shaping the other screenlets like one you know to work (like the Clock) might be a good idea. At any rate, unfortunately java is the only programming language I know well enough to actually use. I know nothing about python, and so I'm not sure I can be of help.

But if by chance you guys have something in mind which I may help you with, be it testing or such, let me know, I'll be glad to since I really like this widget-framework project.

[whise]

But still I don't know why the Clock stays "cool" while the CPUMeter doubles...

exactly

i think i found out why , but let me do some testing first

[whise]

here is why , this is my output , i made the _setattr_ setting atributes print and the on_draw print drawing

setting atributes
drawing
setting atributes
drawing
setting atributes
drawing
setting atributes
drawing
setting atributes
drawing
setting atributes
drawing
setting atributes
drawing
setting atributes
drawing
setting atributes
drawing
setting atributes
drawing
setting atributes
drawing
setting atributes
drawing
setting atributes
drawing
setting atributes
drawing
setting atributes
drawing
setting atributes
drawing
setting atributes
drawing
setting atributes

it goes on like this forever , the _setattr_ make on_draw work and the on draw makes _setattr_ its a cicle, im working on how to stop it

[whise]

ok i fixed it , no more memory leak , allways remenber from my mystake , dont set atributes like self.variable = something in the on_draw

[Krakatos]

Great, can't wait for it to be available for download. Thanks :)

[whise]

ill update it soon

[whise]

fixed memory leak

[plun]

Also a new version... :)

http://www.gnome-look.org/content/show.php/Net+Monitor+Screenlet?content=64719