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

[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.

[Mike Walsh]

G'day, David.

I've been having a think about this. Certainly your idea is viable (and as you say, would require quite a bit of discipline on my part!); the more so after last night, since upon re-reading rcrsn51's Samba-TNG thread, I've now realised why the Dell could only read from the Compaq, and not write to it...

Needed some different commands in 'smb.conf'. Changed:-

Code: Select all

[Pupshare]
path = /root
writable = yes

To:-

Code: Select all

[Pupshare]
path = /root
guest ok = yes
writable = yes
force user = root

.....and I can now read/write in both directions. So, yes; for the few occasions on which I use the Dell, yours is actually quite a practical suggestion.

@amigo:- You could well be correct about the 'file lock'; I certainly won't dispute that, since I'm still fairly new to Linux...

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

I've been thinking that the main reason, probably, that the P4 is running flat-out is in all likelihood due to the frequency of the 'Refresh Intervals' (set via the BitMeter 'Preferences' tab). From a 'virgin' install of Bitmeter, they read as follows:-

Monitor updates every 1 second.
History updates every 10 seconds.
Summary updates every 10 seconds.
Alerts updates every 10 seconds.

I think that the Monitor tab refresh interval is the culprit. Once every second..! I don't actually use the 'Monitor' tab at all.....nor the 'History' tab. The two that I'm interested in are the 'Summary' and 'Alert' tabs. I don't for a moment believe that it's the Samba connection itself, since when I'm on the Dell, the Compaq's 'Pupshare' is one of the first things I open; it stays open for the duration of the session, and CPU usage is almost always what you'd expect it to be; perfectly average.

So; later on today, I'm going to repeat last night's experiment, and make some adjustments to the refresh intervals. Of course, my reasoning could be fallacious.....but I've a feeling that's somewhere near the root of the problem.

Will let y'all know what happens. Watch this space.....


Regards,

Mike.

[Mike Walsh]

I'm inclined to think amigo is right about the file-locking.

By the very nature of the way we have this set-up, whichever Puppy I happen to be running, BitMeter is set to start automatically, and to use the sym-linked remote main BitMeter database as it does so.

This means, of course, that whenever I attempt to use the Dell at the same time, I have at least two BM-OS installs attempting to write to the main database simultaneously. If amigo is correct (and I'm inclined to think that he/she is ), then the 'file-lock' will prevent the secondary 'write' from occurring.

Having repeated the experiment with the monitor refresh interval increased to '10', the same as the others, the CPU usage is now far more reasonable. Observing pWidgets' CPU graph (which I use), instead of solid 100% usage, I now merely get a nice little 'spike' every 10 seconds or so.....which is what I would expect. (See attachment).

BUT; the database is very obviously not being updated. So...

This leaves two possibilities. Either David's suggestion.....to use a copy of the main 'bitmeter.db' file for the duration of each session on the Dell, and then to write it back at the end of the session; or, which I'm inclined to think would also work, to switch off the bmcapture daemon manually on the Compaq when I want to use the Dell, so that only the Dell is, at that point, writing to the database.

Both of these mean manual intervention. Be nice if I could automate the process, but as I know absolutely nothing about scripting, this means relying on someone else to do this for me.....which is, I feel, asking a bit much!

Even David's suggestion would, if amigo is correct, mean briefly switching off the bmcapture daemon while the database was being updated.

What to do...and how to do it? Hmmm.....

*thinks*

EDIT; I'm going to pose a question now. Is it possible, via Samba, to remotely open a terminal in 'Pupshare', using Rox (right-click in the Rox-filer window, and 'Terminal here')? If so, then I could switch off the Compaq's BitMeter daemons from the Dell.....so at least I could do things all from one end. Is that possible? Is my intention clear, what I want to do?


Regards,

Mike.

[Mike Walsh]

These various BitMeter .pets are now mirrored at filehosting.org.....you can never have too much backup! Links are as follows:-

The original two:-

0.8.0 for 32-bit:- http://www.filehosting.org/file/details ... 0-i386.pet

0.8.0 for 64-bit:- http://www.filehosting.org/file/details ... -amd64.pet

The latest versions, for those of us who want to run BitMeter on multiple Puppies & get a monthly aggregate total. This one will ask you where, & how you want to set up a common shared database:-

0.7.6 for 32-bit (w/database installer):- http://www.filehosting.org/file/details ... t-pups.pet

0.8.0 for 32-bit (w/database installer):- http://www.filehosting.org/file/details ... t-pups.pet

And the original four .debs, from Rob Dawson's CodeBox website. I've included these, because some people have found that the .deb works for them, rather than the .pet:-

0.7.6 for 32-bit:- http://www.filehosting.org/file/details ... 6-i386.deb

0.7.6 for 64-bit:- http://www.filehosting.org/file/details ... -amd64.deb

0.8.0 for 32-bit:- http://www.filehosting.org/file/details ... 0-i386.deb

0.8.0 for 64-bit:- [url]http://www.filehosting.org/file/details ... 64.deb[url]


Regards,

Mike.

[amigo]

As an alternative, you might run an instance of BM on each machine and then use a script to read each database file and consolidate the results.