BIT METER OS 0.7.6 (stable) & 0.8.0 (experimental)

[mikeb]

me again

seems 0.7.6 is more picky about having the /var/log/bitmeter folder in place even if not used..
Also pkill does not appear to be in all puppies...just noticed that one.

..coffee needed...

mike

[Geoffrey]

me again

seems 0.7.6 is more picky about having the /var/log/bitmeter folder in place even if not used..
Also pkill does not appear to be in all puppies...just noticed that one.

..coffee needed...

mike

More drama, it should work changing this line

Code: Select all

#pkill -f $PROC
kill `ps aux | grep $PROC | grep -v grep | awk '{print $2}'`

[mikeb]

Sorry I have a habit of finding stuff...whether I want to or not....thats a general affliction and not just software.

I went for a sloppy killall $PROC .... pkill and pgrep are useful tools but puppy tends to get a bit minimalistic at times. They have been added to busybox it seems over time...at least here.

mike

[Mike Walsh]

@Geoffrey:-

Morning, Geoff. Been busy for a few days, and haven't been paying too much attention to this thread of mine.

Now then; query. Would you say your .pets are ready for publication? BitMeterOS 0.8.0 with the linked common bitmeter.db file has been playing happily with my 3 Pups for the last week or so. I've got the OP updated as far as the current state of play.

Are they ready for the big time, or can you think of any more mods that may need doing?

And this is what I would like an answer to; do you want a download link on the 'CodeBox' website.....or would you prefer to leave them where they are, and I leave the links'n'stuff as they are? I just want to know how you'd like to play it, and I'll set up the rest...OK?


Mike.

[Geoffrey]

Are they ready for the big time, or can you think of any more mods that may need doing?

I should change the kill command as mikeb mentioned, so that it works in older pups, though I still think it may have other problem with the old pup versions

do you want a download link on the 'CodeBox' website.....or would you prefer to leave them where they are, and I leave the links'n'stuff as they are? I just want to know how you'd like to play it, and I'll set up the rest of it...OK?

I think as they are, we have more control over the content which makes it easier to change, I'll mostly make a custom version for Carolina and Vanguard for the repo in any case, still have to do the 64bit versions.

I'm working on some of my other projects at the moment, so I'll get to them when I can.

[mikeb]

I should change the kill command as mikeb mentioned, so that it works in older pups, though I still think it may have other problem with the old pup versions

apart from that annoying /var/log/bitmeter folder anything else that comes to mind...I can test no problem.

mike

[Mike Walsh]

@Geoffrey:-

No worries. I guessed that's what you'd say; as you say, it does give us more control over what's done with them.....and if any other modifications are required, we can do them, as & when.

I'll leave the OP as is. And don't worry about doing the rest ; there's no hurry. We've proved the basic idea works fine. If older Pups need any additional work, it can be sorted out if it's needed.

I'll leave it with you. Cheers for all the effort you've put in so far; it's much appreciated.


Mike.

[gcmartin]

Hi @Mike Walsh.

Might you consider restructuring you OP a little. Readers are forced to have to read all the way to the bottom to know the Puppy PET locations they need to gather, test and evaluate Bit Meter. If you want any help, PM me.

[Mike Walsh]

Have just applied Geoffrey's BitMeterOS 0.8.0 .pet to a new install of Precise 5.7.1, sym-linked the remote database, edited xbitmeter to suit, and have added the Common Data partition (where the remote database resides) to the auto-start .pet for rcrsn51's Samba-TNG.

I'm pleased to be able to report that everything appears to be working flawlessly.


Regards,

Mike.

[Mike Walsh]

Hi @Mike Walsh.

Might you consider restructuring you OP a little. Readers are forced to have to read all the way to the bottom to know the Puppy PET locations they need to gather, test and evaluate Bit Meter. If you want any help, PM me.

Good idea. All sorted!


Regards,

Mike.

[gcmartin]

Mike. Nice.

The following was a thought suggested earlier and you've shown its use.

Have just applied Geoffrey's BitMeterOS 0.8.0 .pet ... sym-linked the remote database, edited xbitmeter to suit, and have added the Common Data partition (where the remote database resides)

Questions

• Did you have the db, which you saved locally, and shared with your LAN neighbors thru the SAMBA server?
• OR, did you place the db remotely and use the SAMBA client to access it?
• OR, are you accessing it from all PCs via the browser's URL pointing to the LAN PC with the resident db?

Want to insure I am clear on what you provide in this setup.

Thanks, everyone.

[Mike Walsh]

Hi, gcm.

Yep, you're right; that IS a wee bit confusing. .! I'll try to elucidate further.

The set-up I'm using for all my Pups utilises a separate database, which lives in a small partition that I set up just for that purpose; however, these are all on the same hard drive. (See attachment; small partition sda6, labelled 'Common Data'). OK, 5 GB is huge for what it is, but I've got plenty of disk space to play with; the 25 GB I've set for each Pup's partition is over the top, as well...

The original trial, in Tahrpup, took 'bitmeter.db.new' from /var/lib/bitmeter, copied it over to sda6, and then renamed it to 'bitmeter.db', yes? The original 'bitmeter.db' in/var/lib/bitmeter was then deleted, and the version in sda6 that had just been re-named, was then sym-linked back to /var/lib/bitmeter to take its place.

With each subsequent Pup, after installing 'BitmeterOS 0.8.0' I then simply deleted its 'bitmeter.db' from /var/lib/bitmeter , and sym-linked to sda6's 'bitmeter.db' instead.....still with me? This is all standard for the trials we carried out.

--------------------------------------------------------------------------------------

Where Samba comes into it, well..... I've been using rcrsn51's Samba-TNG .pet for quite a while now.

http://www.murga-linux.com/puppy/viewtopic.php?t=60204

As part of its functionality, he's also provided an 'auto-start' .pet, that, in addition to starting Samba itself, will also mount any remote drives that you may wish to use as shares, ok? I'm pretty certain you understand all this stuff about Samba, since you've done a thread on it yourself.

To use the remote database for all BitMeterOS installs, sda6 needs to be auto-mounted at boot.....because otherwise, Geoffrey's xbitmeter script won't function. Having already got the automount functionality provided as part of Samba-TNG, rather than mess around with /etc/fstab, I've simply added a line to the autostart .pet to automount sda6 along with everything else that I use in Samba.....but it's not set-up as a 'share' in 'smb.conf'.

In the best traditions of Puppy, and adapting my own circumstances to fit the task at hand, I've simply made use of something that already existed.....thus keeping everything as simple as possible. And it works very well indeed.

Hope that clarifies things a bit further. I'm still trying to figure out how to use Samba to link the BitMeterOS install on the old Dell 1100 laptop into the separate, 'common' database on the big Compaq.....because we're now talking about two physically separate machines, although still using a common LAN.....and therefore using the same, monthly broadband allowance via the one router.

Got any ideas on that one? Any tips would be appreciated. Geoffrey's already proved, after I suggested it way back in the thread, that delays help with the xbitmeter script, since, as we all know, network connection, even on eth0, is not instantaneous. And Geoffrey simply adapted something that mavrothal had already developed... We all help each other out, don't we? What goes around, comes around again.....

What do you reckon?


Regards,

Mike.

[gcmartin]

Just an idea,but, haven't tried it.

Wondering if this will work

1. 1st
2. I have a PC on, say, 192.168.1.2
3. I install BM and create the BM db on this PC (WITH PROPER PATHing)
4. I open my browser to URL "localhost:2605" to see dataflows
5. Using SAMBA, I share the local BM db folder for LAN users
   Next
6. I have a Compaq PC on the LAN at, say, 192.168.1.3
7. I mount the SAMBA path to the BM db folder, from above
8. I install BM to this PC and change its db path to the db in the mounted folder
9. Now, open my browser to URL "localhost:2605" to see dataflows
   (I should see the exact same information if I URL to "192.168.1.2:2605")
   
   Assumption: Neither PCs is running as a LAN router. All PC's internet access is via you LAN's router.

To the developers, I ask:

• This is presenting the view that there is ONLY 1 BM db for all PCs
• Would this usage, with the PCs mentioned, provide a combined, central, accurate view of our data usage?
• Or, at this time are we, the users, required to manually combine each PC's db separately for combined, accurate dataflows?

Thoughts

[Mike Walsh]

@gcm:-

Yeah. That's something along the lines of what I've been considering myself; it may work, it may not.

I shall give this a go early next week,and see how things pan out. Busy this weekend; family stuff.....I'm sure you know how that goes! I'll let you know how it works out. Thanks for confirming what I'd been thinking of doing.

Cheers for that.


Regards,

Mike.

[amigo]

To be able to measure and control the traffic from one computer, then it would need to be the gateway for the others so that all traffic got routed through it.

[gcmartin]

To be able to measure and control the traffic from one computer, then it would need to be the gateway for the others so that all traffic got routed through it.

Not necessarily. If all parties contributed to the common db, then it should be a reasonably close report.

I do agree, though, that this function is best suited for the gateway. But, most home users do NOT have the ability to modify their gateway.

And, @Amigo, I think, is exhibiting concerns for things other than PCs, and those without BM, which also use the Gateway to get out through the ISP's data on-ramp. Centralizing the function in a Gateway is entirely reasonable if we could insert this kind of logic into the central Gateway device(s).

@Rcrsn51 does have a codebase for using an old motherboard to be an Internet Gateway, where this utility function could be centralized. Its availability is restricted: As he has chosen to NOT make it publicly available. When a Gateway subsystem does become generally available, unrestricted, using the traditional PUPPY channels, I believe this community will respond with PUP distro(s) which could replace vendor/ISP/Telco Gateway devices. This is just one more of the kind of Home services that PUPs can do in the Home LAN/WAN for members benefit.

For this thread, though, BM does offers reports which can be useful, taken into context.

[Mike Walsh]

@gcm:-

Now then.....

Managed to find time this evening to try this out. All my Pups on the 'big' Compaq are running 0.8.0 as a matter of course. I've had 0.8.0 running on the Dell laptop for the last few weeks. Since I use the Dell as a Samba client to access files through Samba-TNG from the Compaq & various drives which I have attached to it, the LAN data reporting comes in very handy.

I did the following:-

1) Set up the Common Data partition as a Samba share.
2) Opened /var/lib/bitmeter; deleted 'bitmeter.db'; sym-linked the main 'bitmeter.db' file from the Common Data 'share' across to /var/lib/bitmeter to take its place.
3) Edited 'xbitmeter' as necessary.
4) Did a terminal restart of '/etc/init.d/bitmeter' & '/etc/init.d/bitmeterweb' to get the daemons up-and-running again.
5) Went into Chromium (which is my main browser these days ), and opened the web interface. And.....

Well; it sorta works. The app opens, as it should. There is a readout...of sorts. But to put it in a nutshell, the P4 in the Dell isn't man enough to keep up with the demands of remote monitoring/writing. It runs pretty near flat-out, more-or-less continuously (in the process generating a constant error message along the lines of 'The server is taking a long time to respond. This can be due to high CPU load, or slow data transfer across the network' (or something similiar))...

Essentially, it's so busy coping with BitMeter's demands, that it leaves next to no juice to run the OS/apps. It's so sluggish, it's unusable. Kinda reminds me of a few years ago, when she was running XP, and it was time for the SP3 update ( and this was before I'd uprated the old Celeron to the P4)... From recollection, I think it took nearly all night to download and install; that was slow..!

So; since I don't use her that much, I've just set the alerts to a combined 20 GB total for the month; 3 GB on the Dell, and 17 GB for the rest of the litter on the Compaq. Should work out about right.

Good idea in theory; but it needs more horsepower than I've got. A modern dual- or quad-core CPU (with SSE3's; my earlier generation P4 only has SSE2's), and some additional RAM, would, I feel, make a world of difference. Unfortunately, neither of those is a viable proposition with the Dell, since she's maxed out in both of those departments!

I'm not complaining, mind. 'Puppy' resurrected the old girl from almost certain extinction; I think I can live without using BM-OS the way I hoped to.....


Regards,

Mike.

[davids45]

G'day Mike,

If I understand your experience with the elderly laptop using Bitmeter through the network server (Samba), that it is the frequent writing to the network that slows things down, what about taking the latest up-to-date copy of the .db file from your data drive and using that copy somewhere on the laptop when starting Bitmeter on the laptop.

Just before closing down the elderly laptop, copy the now bigger .db file back to your network data partition in place of the original. The new file would then become that for the next use.

May work for a single-network-user at-any-one-time situation, but not when two computers are on the internet together. And require a disciplined user.

Can the history of two or more Bitmeter records be merged 'off-line' as a means to aggregate a multi-computer situation?

Probable answer: yes - use the bmsync program? Will try with some of the networked desktops; if that works, could then try with the Windows7 laptop that wifis to the home network.

David S.

[gcmartin]

Request

If I understand correctly, you already have a Compaq desktop with BM's db shared out from that desktop. Which means that any of your LAN's PCs, including your Dell laptop is able to access that share thru a mere "mount command"; for example

Code: Select all

# mount -t cifs //CompaqDesktopIPaddress/SharedBMfolder /mnt/4localBMacc 

So, I offer this idea, all to be done on your Dell laptop where you experienced out of control CPU utilization:

1. Boot your laptop pristine (ie. pfix=ram)
2. After FirstRUN, issue the above mount with your local namings
3. Do NOT run ANY NETWORK UTILITIES for any other kind of network sharing! (the above command is all that is needed)
4. Install BM
5. Set BM db path appropriate to where you mounted the above
6. Open your browser to URL "localhost:2605" to see dataflows

Do ONLY the above.

Please share your TOP/HTOP utilization.
P.S. Although, I'm sure you wont need a mount example, I offer for your DELL Laptop's connection to your Compaq's db:

Code: Select all

# mkdir /mnt/Access2BM-DB
# mount -t cifs //192.168.1.2/BM-DB  /mnt/Access2BM-DB

You know the rest for symbolic db on the Laptop to the physical file

[amigo]

Accessing the file from multiple comps is not going to work as file locks will prevent it from being accessed when it is already being accessed.
GC, you always talk about how Puppy should fit in -of all the possibilities for control etc. Nearly always, what you are describing is simply that puppy should be the gateway (or router) for other devices. There is nothing new or revolutionary about it. Your router is running a small linux and you could certainly flash a new system onto the router, or simply insert your puppy where your router was.